> Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.
Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Talk with an LLM, ask them to rate both code and estimate dev experience based on that code, and you will see what they value: Code that passes all the tests is a 10/10, while a codebase designed with opaque data types, Parse-Don't-Validate for all data, isolated interfaces, a built-for-replacement-not-for-extension philosphy will get a 6/10 because an out of bounds error was found.
IOW, they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way - we very highly value code that is easy to maintain, even if they do have a few errors picked up by the linter.
I have found that claude (opus 4.8 and 5) can do a very good job of implementing good architecture and system design if I can just steer it right. left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code, claude will go do it the right way, and can even have a pretty sensible discussion about the tradeoffs involved. so it does know about good code architecture and patterns, it just doesn't have the taste and initiative to use them without being told.
> left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code,
But that requires actually reading the output, which I am pretty certain only a rounding error of programmers are doing at this point.
> Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).
Blame the benchmarks game. They're optimizing for that and that's what those things are measuring.