Why Is Code Review the Bottleneck in Agentic Coding?

Quick answer
Review is the bottleneck because generation got cheap and verification did not.
An agent can produce a large diff in minutes; the same diff still takes a human the same time to understand, test, and approve.
Review cost grows faster than diff size: more files means more context to hold, more interactions to check, and more ways to be plausibly wrong.
Unreviewed generated code is a liability, not throughput, because it will be maintained by someone who did not write it.
Teams that scale agentic coding make review cheaper: smaller changes, review packets, risk routing, and automated checks before a human looks.

Why does review become the constraint?

Every agent-assisted workflow has three stages: specify, generate, verify. Generation is now the fastest and cheapest stage, so the queue forms at verification. A developer who could previously review two changes a day now receives ten, and the review step has not accelerated at the same rate.

The reason is that review is not reading. It is reconstructing intent, checking edge cases, and deciding whether the change is safe in a system the reviewer may only partly know. None of that is proportional to typing speed.

Why is a large AI diff harder to review than a large human diff?

A human diff carries the author’s mental model: the commit message explains the approach, the code follows the conventions the reviewer already knows, and the odd parts are usually the parts the author struggled with. An agent diff has no such signal. It is fluent everywhere, including where it is wrong.

That fluency is the problem. Generated code reads as if someone thought about it, so a reviewer skims and approves. The defects that survive are the ones that look normal: a missing authorization check, a retry that is not idempotent, a migration that locks a table.

What makes review cheaper without making it weaker?

Smaller changes first. A pull request that touches one concern in a few files can be reviewed properly; a branch that accumulated a week of agent work cannot. Cap the size before the work starts, not after.

Then move the mechanical checks earlier. Tests, type checks, linters, secret scanning, and a dependency diff should run before a human reads the code. A reviewer who is not looking for formatting or a failing test spends attention on design.

What should a team measure?

Review latency, not output volume. Median time from ready-for-review to first comment tells you whether the queue is the constraint. Review depth is harder to measure, but the ratio of comments to changed lines and the number of defects found after merge are usable proxies.

A team that adds agents without tracking review latency will report higher throughput while accumulating unreviewed changes. The number that matters is deployed, reviewed changes, not generated lines.

Where this bites vibecoders
The failure pattern is a branch with three days of agent work, a summary written by the agent, and a reviewer who approves because reading it properly would take an afternoon. Split the work before that branch exists; it is much cheaper than reviewing it.

Where AI coding assistants get this wrong

Measuring lines generated instead of changes reviewed and deployed.
Letting an agent write the pull request description the reviewer relies on.
Reviewing a large branch in one pass and calling it done.
Skipping tests because the code looks conventional.
Adding agents to a team whose review queue is already full.
Treating a green pipeline as a substitute for reading the change.

Checklist

Track median review latency.
Cap pull request size before work starts.
Run automated checks before human review.
Require the author to explain intent, not the agent.
Split large changes by concern.
Measure defects found after merge.

FAQ

Does AI code review solve the bottleneck?

It helps with the mechanical layer and can catch classes of defects, but it does not take responsibility. An AI reviewer also produces plausible output, so its findings need triage. It reduces the reading, not the judgement.

Is the bottleneck temporary?

Some of it is tooling: review interfaces built for human-sized diffs are adapting to agent-sized ones. The part that does not go away is that someone must decide whether a change is correct for this system, and that decision needs context an agent does not have.

How large should an AI pull request be?

Small enough that a reviewer can hold the whole change in mind: typically one concern and a handful of files. Many teams set a soft cap on changed lines and split anything larger, because review quality falls faster than review speed with size.

What if the team has no reviewers?

Then agent output should be throttled to what one person can verify. A solo builder reviewing their own agent’s work should still use a written checklist and tests, because self-review of fluent generated code is the weakest form of review there is.