Nobody reviews a 2,000-line AI diff

The thing nobody says out loud

No AI-generated commit beyond a very small size is ever properly reviewed, because doing so would take longer than actually writing the code.

bakugo, Hacker News

Everyone who has shipped with an agent recognises this, and almost nobody says it, because the implication is uncomfortable: a large share of what is in production was approved rather than reviewed.

The numbers around it are not ambiguous. In Stack Overflow's 2025 developer survey, 45% of developers said debugging AI-generated code takes more time than writing it themselves, and 46% said they do not fully trust the output. Both groups kept using the tools, because a two-hour feature arriving in ten minutes is worth a lot even when you are uneasy about it.

The asymmetry

Generation sped up by roughly two orders of magnitude. Comprehension of unfamiliar code sped up by zero. That gap is the entire problem, and it does not close by trying harder.

Writing code builds the model of it that reviewing requires. You do not remember a function you wrote because you memorised it — you remember it because you made the decisions inside it. An agent's diff hands you the artifact with the decisions deleted, so reviewing means reconstructing the reasoning from the output, which is the expensive direction to travel.

Reviewing harder is not the fix

Smaller diffs. Correct, and worth enforcing. It reduces load per review; it does not reduce total volume, which is what actually grew. Ten 200-line reviews cost about what one 2,000-line review costs, honestly done.

Automated review. Genuinely useful for a defined class of defect — null paths, injection, obvious concurrency mistakes. It cannot tell you the feature was built to the wrong rule, because nothing told it the rule.

Reading it properly anyway. The advice most often given and the one nobody follows twice. If proper review costs more than writing, the economics that made you reach for the agent are gone, and people do not voluntarily give those up.

Each of these makes review of the output cheaper. The output is the wrong unit.

Move the reviewable unit upstream

There is a version of this artifact that is short, and it is not the code. It is the statement of what the change is supposed to do: the requirement, the constraint on it, the acceptance criteria. Twenty lines rather than two thousand, in domain language rather than implementation language — and it is the thing you actually have an opinion about.

You do not have an opinion about whether the retry loop is a for or a while. You have a very specific opinion about whether a refund above the manager threshold can be issued automatically. One of those is reviewable in ninety seconds by the person who knows the answer, and it is not the one in the diff.

• What it catches: the wrong rule, the missed case, the constraint nobody stated, the feature built correctly against a misunderstanding — where the expensive mistakes actually are, because code that does not work fails loudly and immediately.
• What it does not catch: an off-by-one, a race, a leak, a query that falls over at 100k rows. Reviewing the spec is not a substitute for reading the diff; it is what makes a smaller, targeted diff review possible, because you already know what the code was trying to do when you open it.

Anyone selling this as "you never have to read the code again" is selling something. The claim is narrower and more useful: the part of review that requires human judgement moves to an artifact where human judgement is cheap.

What has to be true for it to work

The intent artifact has to be structured rather than prose, or the problem has moved instead of being solved — a paragraph in a doc is as unreviewable as the code once there are two hundred of them.

• One requirement per statement, so approving one is not approving five.
• Linked to what it depends on and what depends on it, so a change shows its blast radius before the agent starts.
• Stable enough that the model cannot regenerate it into something else — in our system locked requirements are filtered out of the set handed to the model, so what you approved is what is still there next week.

What we have not measured

We have not put a number on this. The honest version of the claim is that reviewing twenty lines of intent is faster than reviewing two thousand lines of implementation — true by inspection, but not a measurement, and we do not have a controlled comparison of defect-catch rates between the two.

We do publish numbers when we have them. Where agent token cost actually goes is 22 measured sessions with the script on the page, including the parts that contradicted what we expected. When this one has been run, it goes up the same way, whichever direction it comes out.

Questions this raises