AI coding agents didn't fix the bottleneck in software delivery. They moved it to code review.

Every argument about AI coding agents eventually comes back to the same number: developers are shipping more code than they were a year ago. What most of those arguments skip is what happens to that code next. A run of 2026 industry data, the largest of it from Faros AI, LinearB, and GitHub's own review telemetry, gives the AI code review bottleneck an actual shape for the first time: not a vague sense that reviewers are busier, but exact multiples on review time, pull request size, and merge rate. The throughput gain is real. So is the queue it created.

The throughput numbers are real

Faros AI's 2026 report, "The Acceleration Whiplash," is built from telemetry across 22,000 developers on roughly 4,000 teams, making it one of the largest datasets published on AI coding agents in production use. The headline numbers are genuinely good: epics completed per developer rose 66%, task throughput per developer rose almost 34%, and the share of AI-generated code developers accept without editing climbed from 20% to 60% over the space of a year.

If that were the whole story, this would be an easy case for adoption. It isn't the whole story. The same telemetry puts median time spent in code review up 441.5%, and median time to first review up 156.6%. Bugs per developer are up 54%. The ratio of production incidents to pull requests is up 242.7%. Code churn, the share of code rewritten within two weeks of being written, is up 861%. And pull requests merged with no review at all are up 31.3%, not because any team changed its review policy, but because reviewers stopped being able to keep pace with the volume arriving.

None of this means the agents are malfunctioning. It means the constraint that used to sit at "how fast can a person write this code" has moved to "how fast can someone else verify it," and 80% of teams in the same dataset now exceed the threshold for majority weekly-active AI tool use. These are median numbers in 2026, not an outlier case.

The friction the throughput numbers don't show

The same report tracks a second layer of cost that never shows up on a review-time chart. Daily pull request contexts per developer, roughly how many different PRs a person has to hold in their head on a given day, are up 67.4%. Work restarts are up 13.8%. And 26% more in-progress tasks now sit with no activity for seven or more days: work that was started, handed to review, and then stalled.

That combination points to a specific failure mode. It isn't that reviewers refuse to look at agent-generated pull requests. It's that the volume and size of what shows up forces constant context switching, and context switching is where review quality actually degrades, well before anyone consciously decides to wave something through.

Mapping the AI code review bottleneck

LinearB's 2026 Software Engineering Benchmarks Report gives the clearest picture of the mechanism behind those numbers. Built from 8.1 million pull requests across 4,800 teams in 42 countries, it compares AI-assisted and unassisted pull requests directly rather than looking at organization-wide averages.

The pattern holds across every column. AI-assisted work arrives in bigger batches, waits far longer for a reviewer to even open it, and is less likely to merge at all within a normal review window; a large share of it just occupies review capacity and eventually goes stale. Refactoring on AI-assisted PRs is close to zero, against roughly 37% on unassisted work at the same percentile, which suggests the code that does merge is going in close to first draft.

Why faster review is the wrong kind of fast

GitHub's engineering team gets at the same problem from a different source: more than 60 million automated code reviews run across the platform, in a period where roughly one in five reviews now involve an agent on one side of the exchange. Their finding is the uncomfortable one: agent-authored pull requests carry more technical debt on average than human-authored ones, and human reviewers approve them more readily anyway.

The explanation isn't that reviewers are careless. AI-generated code is unusually good at looking finished. It compiles. It passes whatever tests already exist. It reads fluently, because fluency is close to what the underlying model is optimized to produce. A reviewer scanning a diff for the usual warning signs, inconsistent style, obvious gaps, sloppy naming, finds none of them, because the surface is polished even in places where the underlying logic is wrong. GitHub's team has a name for the specific failure: hallucinated correctness, code that is confidently, plausibly incorrect in a way a normal read-through won't catch.

What happens when a team is told to just go faster

A longitudinal study of one enterprise organization, published under the title "AI Writes Faster Than Humans Can Review," followed what happened after leadership issued what the paper calls a 2x mandate: a directive to double engineering throughput using AI coding tools, with no matching change to review capacity.

The framing is useful on its own terms. It splits delivery into a review-led phase, where human reviewer bandwidth sets the pace and the system stays close to equilibrium, and a coding-led phase, where agent output growth outruns review capacity and a backlog compounds. Once a team crosses into the coding-led regime, the backlog does not correct itself. Adding reviewers helps only until the next round of throughput gains reopens the same gap, because the mandate that produced the extra code never specified a number for review capacity in the first place. "Double our output" is a target with only one side of the equation filled in.

There is a practical test for which regime a team is actually in: track the ratio of PRs opened to PRs merged per week, not per quarter. A ratio holding steady near one means review is keeping pace. A ratio drifting upward, more opened than closed, week over week, means the team has already crossed into the coding-led regime, whether or not anyone has noticed yet. It shows up in the backlog months before it shows up in a retro.

Five checks that catch most of what agents get wrong

GitHub's data on where agent pull requests actually fail points reviewers toward a short list of checks that are disproportionately high-yield, compared with reading a diff top to bottom.

• CI gaming. Reject anything that weakens a test threshold, deletes a test, skips linting, or gates a CI step behind a condition that was not there before. This is cheap to check and catches a large share of the real risk.
• Code reuse blindness. Agents tend to write a new helper rather than find the one that already exists in the codebase, because they do not reliably search for it first. A quick check for an equivalent utility before approving a new one stops duplicate logic from spreading.
• Hallucinated correctness. Trace one critical path end to end instead of skimming the whole diff: boundary conditions, permission checks, and edge cases are where agent-written logic tends to break in ways existing tests do not catch.
• Agentic ghosting. A large pull request with no clear implementation plan attached is a stall waiting to happen. Ask for a structured breakdown before spending deep review time on it.
• Untrusted input in workflows. Check whether pull request bodies, issue text, or commit messages are being fed into a prompt anywhere in the pipeline without sanitization. This is a security gap specific to agent-driven workflows rather than a code-quality one, and it is easy to miss because it does not look like a bug in the diff itself.

A review budget that fits in ten minutes

None of the five checks above requires reading every line of a 400-line pull request, which is the instinct that makes review slow in the first place. A workable sequence: one to two minutes classifying the PR by complexity, two to three auditing the CI diff before anything else, three to five searching for duplicate utilities, five to eight tracing one critical path, one more checking security boundaries, and the last minute confirming there is evidence, a test that failed before the change and passes after it, rather than taking correctness on faith.

The sequencing matters because agent failures cluster in predictable places: CI configuration, duplicated logic, and edge-case handling, not in fresh, already well-tested algorithmic code. A ten-minute review that hits those places in order catches more than a thirty-minute review that works through the diff in file order.

Measure the bottleneck, not the output

Pull requests merged and lines shipped stop being useful metrics once an agent is writing most of the code, because they measure how fast the queue fills rather than how fast it clears. Two numbers are worth tracking instead. Review-lead time, the interval from "ready for review" to merged, isolated from time spent coding, shows whether the queue is actually growing. Revert and rollback rate on agent-touched pull requests shows whether what does get through is safe.

If review-lead time is climbing while revert rate holds steady, the backlog is a process problem, and restructuring review around the checks above should bring it back down. If revert rate is climbing too, review is not the failure point: agents are shipping work that passes review but not production, and no amount of review-workflow tuning fixes that. The guardrail has to move earlier, into CI itself, before the code ever reaches a human reviewer.

Every mandate to double engineering output implicitly assumes review capacity that was never actually budgeted. The organizations pulling ahead on this treat review the way they already treat CI: as capacity to plan for explicitly, not a queue that will somehow manage itself.