Why has code review become the bottleneck for AI-generated code?

AI agents compressed the time it takes to write code while leaving review largely untouched, because review is bounded by human attention rather than compute. Once writing stops being the slow step, total delivery throughput is set by whatever is now slowest, and for many teams that is review. The DORA 2025 report frames this well: AI acts as an amplifier, magnifying an organization's existing strengths and weaknesses.

How much longer do AI agent pull requests wait to be reviewed?

LinearB's 2026 Software Engineering Benchmarks Report, based on 8.1 million pull requests from more than 4,800 organizations, found that agentic AI pull requests have a pickup time 5.3 times longer than unassisted ones, and that AI-generated pull requests are accepted at 32.7 percent against 84.4 percent for manual ones. Separately, the peer-reviewed AgenticFlict dataset found merge conflicts in 27.67 percent of the agentic pull requests it was able to merge-simulate.

Can AI review AI-generated code effectively?

It helps with summarizing intent and catching obvious defects, but it carries three specific failure modes. A reviewer from the same model family as the author shares its blind spots. High comment volume creates triage work rather than removing it. And when a bot has already commented and approved, human scrutiny tends to lighten even though the bot accepted no accountability. Treat it as a tool for preparing a human reviewer, not replacing one.

The AI Code Review Bottleneck

Agents generate pull requests faster than humans can review them. How review capacity became the delivery ceiling, and what teams are actually doing about it

The Constraint Moved

Generation got cheap. Verification did not.

Amdahl's Law, Applied to Delivery

Amdahl's law says the speedup available from optimizing one part of a system is capped by the part you did not optimize. Software delivery is a pipeline: specify, write, review, merge, deploy. AI agents have compressed the "write" stage by a large factor and left "review" almost untouched, because review is bounded by human attention rather than compute. Once writing stops being the slow step, total throughput is set by whatever is now slowest. For a large number of teams, that is review.

This is not a claim that AI makes teams slower. It is a claim about where the queue forms. A developer supervising three agents can open three pull requests in the time it used to take to open one; the reviewers on the other side did not triple. The resulting cost is easy to miss because it does not appear as idle engineers - it appears as rework. Every hour a pull request waits is an hour the underlying code can drift out from under it, and the person reconciling that drift is usually not the agent that wrote it.

The framing that holds up best comes from the DORA State of AI-assisted Software Development (Google Cloud / DORA, September 2025). Its words: "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses." That is the single most useful sentence available on this topic. If your review process was healthy, agents make a healthy process busier. If review was already a bottleneck, agents turn a bottleneck into a crisis. The technology does not decide which of those you get; your existing process does. The same report puts AI use at 90 percent of respondents, with 30 percent reporting little or no trust in AI-generated code - a gap that lands squarely on reviewers.

Supply Went Up

One supervising developer can now keep several agents working in parallel across separate branches. The unit of output stopped being "what one person can type" and became "what one person can launch".

Capacity Did Not

Careful review is a serial, attention-bound activity. It does not parallelize inside one head, and it competes directly with the reviewer's own delivery commitments.

So a Queue Forms

Queues convert throughput problems into latency problems, then into merge conflicts, then into abandoned work. The cost shows up downstream of where it was created.

What the Evidence Actually Shows

Read honestly, the research supports a narrower claim than either side of this argument usually makes

Inbound Volume Is Rising

GitHub Octoverse 2025, October 2025. Platform telemetry, vendor-published.

GitHub reports 43.2 million merged pull requests per month on average, up 23 percent year on year, totaling 518.7 million merged pull requests over the reporting period. Created pull requests rose 20.4 percent, to 47.5 million from 39.5 million.

A figure we deliberately do not use: a widely-shared claim that merged pull requests grew from 25 million per month in January 2023 to 90 million per month in March 2026 traces back to a single vendor blog citing unpublished data with no dataset or link, and it cannot be reconciled with GitHub's own published trend above. We cite the published number instead.

Octoverse 2025

Agent Pull Requests Wait Longer and Land Less

LinearB, 2026 Software Engineering Benchmarks Report. 8.1 million pull requests across 4,800 organizations in 42 countries.

Agentic AI pull requests have a pickup time 5.3x longer than unassisted ones
AI-assisted pull requests run 2.6x larger (408 vs 157 lines at the 75th percentile)
AI-generated pull requests are accepted at 32.7 percent vs 84.4 percent for manual

Read the categories carefully. LinearB reports "agentic", "AI-assisted" and "AI-generated" as distinct groups, and they are routinely conflated in secondhand write-ups. The 2.6x size figure is AI-assisted, not agentic - agentic pull requests average roughly 290 lines. Disclosure: LinearB sells engineering-analytics tooling.

Benchmarks report

Merge Conflicts Are Measurable at Scale

Ogenrwot and Businge, "AgenticFlict", AIware '26 (ACM), 2026. Peer reviewed, with a public dataset.

A dataset of more than 142,000 agentic pull requests drawn from over 59,000 repositories. Of the roughly 107,000 that could be merge-simulated, 27.67 percent produced merge conflicts, across more than 336,000 conflict regions.

This is the strongest single citation on this page: peer-reviewed, with the dataset published rather than described. Note the denominator - 27.67 percent is of the merge-simulated subset, not of all 142,000 collected pull requests.

Read the paper

One Enterprise, Measured Over Two Years

He, Agarwal, Denisov-Blanch, Azaletskiy, Koyejo and Vasilescu, July 2026. Preprint - not yet peer reviewed.

A longitudinal study of 802 developers and 196,212 pull requests across a company-wide mandate to double output. Per-capita throughput eventually doubled, reaching 2.09x the pre-mandate baseline. Per-reviewer load roughly doubled with it, and automated review overtook human review.

Do not over-read it. This is a single-company case study, its authors explicitly disclaim causality, and its quality proxies - merge and revert rates - held steady. It documents review load doubling and automation absorbing the difference. It does not show that quality broke.

Read the preprint

Maintainability Is Trending the Wrong Way

GitClear, 2026. 623 million analyzed changes, 2023 to 2026. All figures are measured against a 2023 baseline, with 2026 as year to date.

Code block duplication up 81 percent against a 2023 baseline, from 40.3 to 73.0 duplicated blocks per million changed lines
Moved code, its proxy for refactoring, fell from 21 percent of changed lines in 2022 to 3.8 percent
Error-masking constructs up 47 percent

Why it matters for review: duplicated and un-refactored code is exactly the kind of change that is cheap to approve and expensive to live with. It passes tests. It looks fine in a diff. It is the failure mode review is worst at catching.

Disclosure: GitClear sells code quality analytics and has a commercial interest in this finding. The dataset size and the consistency of direction across independent signals are why it is worth citing anyway.

Read the research

The Productivity Picture Is Genuinely Unsettled

METR, July 2025, with a significant author update in February 2026.

The original randomized controlled trial put 16 experienced open source developers through 246 tasks on mature repositories they knew well. Developers were measured 19 percent slower with AI, while believing afterwards they had been 20 percent faster and forecasting beforehand they would be 24 percent faster. The tooling was Cursor Pro with Claude 3.5 and 3.7 Sonnet, between February and June 2025, which is the main limit on applying it to current agents.

Cite both halves or neither. In February 2026 METR published an update stating it now believes developers are more sped up by AI than its early-2025 estimates suggested, and that it is changing the experiment design - including considering a move from task-level to developer-level randomization. The primary stated reason is selection bias: 30 to 50 percent of developers said they were choosing not to submit tasks they did not want to do without AI. A second reason is directly relevant to this page - developers found time-spent hard to report because they would work an unrelated task while waiting for an agent. The uncaveated "AI makes developers 19 percent slower" headline is contradicted by the study's own authors.

Original study February 2026 update

What we are not claiming

There is no credible, generalizable measurement of "how much slower review is than generation" across the industry, and any specific multiplier quoted for that should be treated with suspicion. Note also what the evidence above does not say: merge and revert rates held steady in the enterprise study, and none of these sources demonstrates that agent output is causing production defects at scale. What the evidence supports is narrower and still actionable - the volume of change arriving at review has risen, agent-authored changes wait longer and land less often, merge conflicts are common enough to be a scheduling concern, maintainability indicators have worsened on a large dataset, and the individual productivity effect is contested enough that the study most often cited against AI has been partly walked back by its own authors.

If you want to know whether review is your constraint, the answer is in your own delivery data, not in a headline. Measure pickup time, review latency, and pull request size before and after agent adoption. See DevEx metrics for how to instrument that, and agent observability for attributing the inbound volume to specific agents and teams.

Merge Queue Mechanics Under Agent Load

What changes when many branches start from the same commit

Agent workloads have a structural property that human workloads mostly do not: many branches are cut from the same base commit at nearly the same moment, and each one is worked on without awareness of the others. That is a recipe for semantic conflicts - changes that merge cleanly at the text level but are wrong together. A merge queue helps because it tests the actual post-merge state rather than each branch in isolation, but under high agent volume the queue itself becomes a scheduling problem.

The scale of the textual half of this is now measured rather than assumed. The AgenticFlict dataset (Ogenrwot and Businge, AIware '26, peer reviewed) found conflicts in 27.67 percent of the roughly 107,000 agentic pull requests it was able to merge-simulate. Better than one in four is a rate you design around, not one you handle case by case.

Batching

Testing pull requests in batches rather than one at a time cuts CI cost dramatically, but a single failure invalidates the whole batch and forces a bisect. Larger batches are cheaper when things pass and much more expensive when they do not. Tune batch size to your actual failure rate, not to your hoped-for one.

Stacked Pull Requests

Splitting one large change into a stack of dependent, individually reviewable pull requests keeps each diff small enough to genuinely review. The cost is tooling and rebase discipline; the benefit is that review can start on the bottom of the stack while the top is still being written.

Diff Size Limits

Enforcing a maximum changed-line count on agent branches is blunt and effective. It pushes work back toward decomposition, which is where an agent can actually help. Set the limit as a CI check with a documented override rather than a social convention.

Rebase Freshness

Require branches to be within a bounded distance of main before entering the queue. Stale agent branches are the main source of conflicts, and rebasing is one of the tasks an agent can usually be trusted to attempt unsupervised.

Example: a merge queue configured for agent branch volume

# Merge queue policy tuned for high inbound agent PR volume
merge_queue:
  # Test the real post-merge state, in batches, to bound CI spend
  batch_size: 5
  batch_failure_strategy: bisect

  # Reject branches that are too far behind to be meaningfully tested
  max_commits_behind_base: 50

  # Small diffs are the whole game - enforce, do not suggest
  checks:
    - name: diff-size-guard
      max_changed_lines: 400
      override_label: reviewed-oversized

    - name: required-human-approval
      min_approvals: 1
      # An agent-authored PR cannot be approved by its own supervising account
      dismiss_self_approval: true

  # Agent branches are identifiable, so they can be routed differently
  branch_patterns:
    agent: "agent/*"
    human: "*"

  # Serialize anything touching migrations or shared schema
  exclusive_paths:
    - "db/migrations/**"
    - "proto/**"

This is an illustrative policy sketch, not a vendor-specific configuration file. The concepts - batching with bisect, staleness bounds, enforced diff limits, and exclusive paths for globally-shared files - map onto GitHub merge queue, Mergify, and Graphite with different key names.

Widening the Constraint

Four approaches, with the trade-off each one actually carries

Make the diffs smaller

The highest-leverage change available, because review effort scales worse than linearly with diff size. Instruct agents to decompose before implementing, and enforce it in CI.

Trade-off: more pull requests, each with fixed overhead. You are trading review depth per change against review count.

Move checks left, off the reviewer

Anything a machine can decide should never reach a human: formatting, lint, type checks, dependency policy, test coverage deltas, security scanning. Reviewer attention is the scarce resource and should be spent only on intent and design. See shift-left AI.

Trade-off: CI cost and pipeline latency rise, and over-strict gates train people to reach for the override.

AI-assisted review

An LLM reviewing a diff is genuinely useful for summarizing intent, flagging obvious defects, and answering "what does this change do" so the human starts from context rather than cold.

Trade-off: see the failure modes below. This is the tactic most likely to create the illusion of review rather than review.

Treat review as scheduled capacity

Rotate a named reviewer-of-the-day with protected time and no delivery commitments that day. Review stops being the thing everyone does badly between meetings.

Trade-off: you are explicitly buying review capacity with feature capacity. That is the honest form of the decision.

Failure Modes of AI-Assisted Review

Using a model to review model output solves a throughput problem and creates a correlation problem

Correlated Blind Spots

A reviewer drawn from the same model family as the author shares its priors. The misunderstanding that produced the bug is reasonably likely to be the misunderstanding that fails to catch it. Independent tests are worth more here than a second opinion from a similar model.

Comment Volume as Noise

Automated reviewers are enthusiastic. A pull request carrying forty low-value comments is harder to review than one carrying none, because a human now has to triage the triage. Tune for precision and accept lower recall.

Responsibility Diffusion

When a bot has already commented and approved, the human approval that follows tends to get lighter. The bot did not accept accountability for the change, but its presence quietly reduces the felt need for scrutiny.

The uncomfortable question

Does a human meaningfully review a 2,000-line generated diff? Honestly, usually not. What happens is a scan for recognizable patterns, a look at the parts the reviewer already understands, and an approval. That was already true before agents; agents simply made it common.

The productive response is not to demand more heroic review. It is to stop producing 2,000-line diffs, and to be explicit about which changes get real scrutiny and which are covered by tests, types, and blast-radius limits instead. A team that says "we do not deeply review generated test fixtures, and here is the containment that makes that acceptable" is in better shape than one that pretends every diff gets equal attention. Pair that with governance that records the decision.

Reviewer Sustainability

The constraint is people, so it degrades like people do

Review load concentrates. In most codebases a small number of engineers hold the context needed to approve changes in the highest-risk areas, and those are precisely the people whose time is most contested. Raise inbound volume without changing that distribution and the outcome is predictable: senior reviewers become a single point of failure, their own delivery stalls, and review quality falls exactly where it matters most.

Measure the Distribution

Track reviews per reviewer, not just review latency. A healthy median with a brutal tail is the normal shape, and the tail is the risk.

Spread Ownership

Broadening code ownership is slow, unglamorous, and the only durable fix. Ownership files that route to a team rather than a person are the mechanical half of it.

Cap Work in Progress

Limiting concurrent open agent pull requests per developer is the least popular and most effective intervention. It forces the queue to clear before more is added.