Quality code is easy to make changes to. What makes terrible code terrible is that changes become harder and harder to make over time. LLMs haven’t solved this, but the marketing acts as if it has, and many engineering orgs seem to have instantly forgotten the things we’ve learned from the last few decades of building software.

Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.

> 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.

> saves much time

Reviewing and reading everything makes this feeling, yeah.

However where I can say 100% it saves time is discovery by answering these questions:

  - At what state does bug X manifests?
  - Explain how integration/feature works.
  - I want to integrate with system X: Audit what items/features are used and what model changes are needed on my side

I'm genuinely not convinced it actually saves time once a full accounting has been made. You get the initial result faster, but then you inflict a super slow and torturous review process on yourself or a teammate. Even if the review manages to bring it up to parity, over time you will keep slowing down as more and more code was never written by the humans directing the agents, so their understanding decays.

I at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.