The Review Bottleneck: AI Writes More Code, and We Approve the Worse Stuff

The story everyone tells about AI coding is a story about generation: the agent writes the code faster, so you ship faster. It’s half true, and the missing half is where all the trouble lives. Code has to be reviewed before it ships — and review is done by humans, at human speed, with human attention. Generation got 2–5x cheaper. Review did not. So the bottleneck didn’t disappear; it moved downstream and got worse. And the most uncomfortable finding of 2026 is that at the exact moment review matters most, it’s quietly failing — because we approve AI-written code more readily even though it’s worse.

The bottleneck moved downstream

Start with the volume, because the scale is genuinely new. GitHub reports that Copilot code review has processed over 60 million reviews, growing 10x in less than a year, and that more than one in five code reviews on GitHub now involve an agent. Agent-authored pull requests aren’t a curiosity anymore; they’re a meaningful fraction of everything flowing through review.

When generation accelerates and review doesn’t, the queue backs up — and the data says it does, hard. Faros AI’s 2026 engineering study, which it reported across roughly 22,000 developers, found that as AI adoption rose, PR review time increased 91% and PR size grew 154%, even as task completion and merge volume climbed — with no matching improvement in delivery metrics. (These are Faros’s reported figures rather than ones we could confirm against the primary dataset, but the direction is unambiguous and consistent across the industry.) More code, bigger PRs, longer reviews, flat outcomes. The acceleration is real; it just piles up against the one part of the pipeline that runs at human speed.

That’s the mechanical problem: a system built for human-paced output is being flooded with machine-paced output. Code review was always the implicit governor on how fast a team could safely move; now generation has slipped that governor, and the queue is where the cost shows up. But there’s a second problem underneath the queue that’s worse, because it’s invisible — it doesn’t show up as a delay you can measure, but as a quality leak you can’t.

The part that should worry you: we like the worse code

A peer-reviewed 2026 study — More Code, Less Reuse (arXiv 2601.21276), presented at the MSR mining-software-repositories conference — went past pass rates to look at what AI pull requests actually do to a codebase, and how reviewers react to them. The objective finding is what you’d fear: “LLM Agents frequently disregard code reuse opportunities, resulting in higher levels of redundancy compared to human developers.” Agents bolt on new code rather than reusing what exists, so each change carries more duplication and more long-term maintenance burden than the equivalent human change.

Here’s the twist that makes it dangerous. The study’s sentiment analysis found that “reviewers tend to express more neutral or positive emotions towards AI-generated contributions than human ones.” Read those two findings together: the AI code is objectively more redundant and debt-laden, and reviewers feel better about approving it. The authors name the mechanism precisely — “the surface-level plausibility of AI code masks redundancy, leading to the silent accumulation of technical debt in real-world development environments.”

That is the review gate failing in the worst possible way: not by being slow, but by being fooled. The slop doesn’t get caught, because it doesn’t look like slop.

Why plausibility beats correctness at the gate

It’s worth being precise about why a careful reviewer approves worse code with a clearer conscience, because the failure is structural, not a matter of lazy engineers. AI-generated code is fluent. It’s well-formatted, idiomatically named, confidently commented, and syntactically clean. Every surface signal a human reviewer has learned to read as “this author knew what they were doing” is present — and none of those signals track the things that actually matter here: whether the change reused what it should have, whether it added a fourth way to do something the codebase already does three times, whether it quietly widened the maintenance surface.

So the reviewer’s scrutiny goes down exactly when it should go up. A scrappy, awkward-looking human PR invites questions; a polished AI PR invites a thumbs-up.

Picture the concrete case. An agent is asked to add a date-formatting helper. The codebase already has two, buried in a utils module the agent never looked at. The agent writes a third — clean, well-named, with a tidy docstring and a passing test. The diff is a pleasure to read. The reviewer, seeing nothing wrong in the diff, approves it in thirty seconds. Nothing was wrong in the diff. The wrongness was in what the diff didn’t know: that the function shouldn’t exist. Multiply that by every PR, across a team merging 98% more pull requests than before, and you get the silent debt accumulation the study describes — not through any single bad decision, but through thousands of locally-plausible ones that no diff-level review was ever going to catch. This is the same root failure we’ve written about from two other angles. It’s why agents get worse the longer they run — the redundancy compounds turn over turn — and it’s the concrete proof of why a bad loop ships bad code faster: speed up generation, leave the verification gate to human intuition, and you don’t just ship faster, you ship worse faster, with everyone feeling fine about it.

Fixing the gate

If the problem is that plausibility fools human judgment, the fix is to stop relying on human judgment for the things it’s bad at, and reserve it for the things it’s good at. Concretely, the review gate has to become robust to surface polish:

• Automate the structural checks. Duplication detection, complexity metrics, dependency and dead-code analysis, real test-coverage deltas — the redundancy that fools a human reviewer is exactly what a tool catches deterministically. These should run before a human ever sees the PR, so the human isn’t the first line of defense against slop.
• Force small, scoped PRs. A 154%-larger PR is unreviewable in the same depth; the larger the diff, the more plausibility substitutes for scrutiny. Scoping work small — the same discipline that keeps a long-running harness from rotting — keeps each change actually reviewable.
• Review against the existing code, not just the diff. The reuse failures are invisible in an isolated diff and obvious in context. The reviewer’s job for AI PRs is less “is this code correct?” and more “should this code exist, or does it duplicate what we have?”
• Make the generating agent prove reuse. Push the check upstream: require the agent to search for and cite existing implementations before writing new ones, and to justify any new helper against what already exists. The cheapest slop to catch is the slop never written — a generation loop that’s told to reuse first produces far less for the gate to reject.

The unifying idea: the verification gate can’t be a vibe. When generation is machine-paced and machine-plausible, the gate has to be engineered with the same seriousness as the generation — automated where possible, scoped to stay human-reviewable where not, and explicitly skeptical of polish.

Why this favors Southeast Asia

Here’s the part that matters for this region, and it’s the sharpest version of an argument we keep making. The teams that win the agentic era won’t be the ones that generate the most code — generation is a commodity now, available to everyone at the same price. They’ll be the ones with the best verification discipline: the judgment to distrust a plausible diff, the rigor to gate on structure instead of sentiment, the restraint to keep PRs small. None of that requires a GPU, a frontier model, or capital. It requires engineering culture — and culture is something a focused team in Phnom Penh or Da Nang can build deliberately, faster than a sprawling org drowning in auto-approved AI PRs can fix.

This is the loop-engineering discipline at the point where it pays off most directly. A small team that treats review as a real, engineered gate — and refuses to let plausibility stand in for correctness — produces a cleaner, more maintainable codebase than a better-funded competitor shipping 2–5x the volume of approved slop. In a world where everyone can generate, the durable advantage is knowing what not to merge. That’s the most underrated skill in the agentic stack, and it’s the cheapest one to build.