AI Writes Code So Fast, Reviewers Spend Their Time Tearing It Down
The real cost of AI-generated code shows up at the next requirement change, when a reviewer has to trace three interdependent useEffects to make one edit. Teams that adopt AI without a review workflow inherit structural debt that slows every future change.
AI-generated code passes tests, has tidy variables, and every abstraction is technically justified — yet hundreds of lines carry logic no one can trace to a single requirement. Tearing down a 400-line table page to 200 lines takes forty minutes and loses no features. The waste isn't bugs; it's "unnecessary" structure AI piles on because nothing tells it where "enough" is.
The review test isn't style. Ask the author: if the requirement changes tomorrow, which line do you start from? Three nested useEffects that each handle a slice of state force the next person to hold execution order in their head. Any three or more interdependent useEffects get merged, not because they're wrong but because maintenance cost is real. Read the whole file, not the diff, because AI code reads neat in chunks but disjointed as a whole.
A habit that keeps agent-heavy code review comfortable: after generation, the structure gets rewritten by hand, preserving only what the human knows how to write. The rule: AI writes what I don't know; I don't let it touch what I know. That flips the common workflow — human defines skeleton and data flow, AI fills details — and it's slower to write but faster to review.
AI optimizes for delivering every requested feature and never learns where "enough" is; the result is code that accumulates layers with each new prompt, shifting the bottleneck from writing to pruning.
The "unnecessary" abstraction is harder to review than a bug because there's no concrete failure to cite; the only cost is future maintenance time, which isn't visible in the diff.
Having a human define the skeleton before AI fills in details reverses the common "AI writes all, human edits" pattern and cuts review time, suggesting ownership of structure is more valuable than ownership of implementation.
Bigshot, give some guidance, what about refactoring? Recently upgraded an internal npm package, too many methods and contents to replace. When the previously agreed logic was being migrated gradually, it stopped being written according to the rules. If I implement according to your method, it feels like too much content, and I can't keep up with time and speed.
First add a layer of adapter/wrapper functions, make the old logic compatible first, replace in batches by call sites; during the migration period, only seek consistency not elegance, set a deadline, after migration do unified refactoring, tests as a safety net, don't decorate while moving.
Thanks for the guidance, bigshot.