[koonsolo]

I'm in camp 3, where sometimes I don't really care how good or bad the code is. For internal tools for example, you can let the LLM crunch out code really fast, you can validate output but don't even have to look at the code. These kind of "weekend projects" can get finished in an hour or two, and so are really 10x.

For bigger production ready code, you indeed have to guard the architecture. But for the code, in some corners you can get away with sloppy code, as long as it kind of works.

What I'm saying is, code doesn't always has to be great. You will just have to judge the places where it needs to be high quality, and other places where you can get away with sloppy code.

[zero_bias]

That judgment is an essential skill of an experienced programmer, and it is required at every level of the big picture, from high level architecture decisions to the development of particular features: what should I polish and what needs to be developed fast? How exactly should I cut corners in the safest way?

So there are still only two camps