Why AI-Generated Code Is So Hard to Review

1. It looks good

AI code is neatly formatted, uses clear names and often includes comments. These are precisely the signals reviewers have used for years as a proxy for care. With a human author, clean style says something about the attention that went into the work. With AI it says nothing: the style is always clean, even when the logic is wrong.

This effect has been measured. Stanford researchers had developers complete security-sensitive tasks with and without an AI assistant. The group with AI wrote less secure code, and was at the same time more convinced their code was secure. CodeRabbit analysed 470 open-source pull requests and found 1.7 times as many issues in AI-written code as in human code, with 75% more logic and correctness errors. Errors that, at first glance, don't look like errors.

2. Pull requests are getting bigger and more numerous

AI writes more lines than a human does for the same problem. DX saw the median pull request nearly double in a single year, from 44 to 72 lines. Salesforce reported average pull requests of more than 1,000 lines across 20 files. Code review research has long shown that reviewer attention drops sharply beyond 400 lines. What happens after that isn't review anymore; it's a formality.

Now add the number of pull requests. More code, in larger chunks, landing on the same reviewers who didn't have enough time for it before the AI wave either.

3. Nobody knows the "why" anymore

Addy Osmani calls it comprehension debt: the growing gap between how much code exists in your system and how much of it any human genuinely understands. Unlike classic technical debt, this debt doesn't announce itself through friction. The code works, until someone has to change it.

This too has been measured. In a randomised experiment by Anthropic, 52 developers learned a new library, half of them with AI assistance. Both groups finished in roughly the same time, but the AI group scored 17% lower on a comprehension test about code they had submitted minutes earlier. The steepest decline was in debugging. Exactly the skill you need to find AI mistakes.

For a reviewer this means: the author is no longer a reliable source about their own change. Every question has to be answered by reading the code yourself.

4. The mistakes are of a different kind

Experienced reviewers know where human mistakes live: a forgotten null check, an off-by-one, a copy-paste that wasn't fully adapted. AI makes different mistakes, in different places:

• Plausible but wrong logic. A business rule implemented just slightly differently than intended, in code that compiles perfectly and whose tests (also written by AI) are green.
• Invented dependencies. A study presented at USENIX Security 2025 found that 19.7% of the packages suggested by code-generating models don't exist. Attackers register those names and fill them with malware, a technique known as "slopsquatting". A reviewer who doesn't check every new import won't see this.
• Silenced errors. GitClear has measured a 47% rise since 2023 in constructs that swallow errors, such as empty catch blocks. The code doesn't fail loudly; it fails quietly, in production.
• Security vulnerabilities. Veracode tested more than 100 models on 80 tasks: in 45% of cases the generated code contained a vulnerability from the OWASP Top 10. For cross-site scripting, 86% failed. Notably, newer and larger models write better working code, but not more secure code.

5. Every change is fine; the whole is not

AI optimises for the prompt, not for the system. It doesn't know a helper function already exists that does exactly this, so it writes a new one. It doesn't know your team's conventions, so it picks its own. GitClear analysed 623 million code changes and saw the share of copy-pasted code rise from 9.4% to 15.7%, while refactored code fell from 21% to 3.8%. Developers now copy five times more often than they restructure.

A per-pull-request review can't see this. Each change is defensible on its own. Only at the level of the whole codebase does it become visible that there are now three ways to do the same thing, that the architecture is slowly eroding, and that every subsequent change is more expensive because of it.

6. Reviewers give up

Put the previous five points together and the result is predictable. More pull requests, bigger, with no author who can explain them, with mistakes in unexpected places. At some point "LGTM" (Looks Good To Me) becomes a reflex. CodeRabbit saw review time for the largest pull requests plateau: reviewers aren't reading anymore, they're clicking through.

The 2025 DORA report on AI-assisted software development confirms the effect at the organisational level: AI adoption increases throughput, but has a negative relationship with software delivery stability. The likely cause, according to the researchers: code is generated faster than review and deployment processes can absorb. A study by Uplevel across nearly 800 developers found 41% more bugs in the work of the group with Copilot access.