AI code review is the bottleneck now: handling a flood of agent-written PRs

AI-generated pull requests are cheap to produce and expensive to review, and that imbalance has moved the bottleneck in software delivery from writing code to reading it. Agent-written PRs are larger, wait longer for a reviewer and get merged less often than PRs written by hand. Adding more agents makes the queue longer, not shorter.

This article looks at what the data shows, why review became the constraint, and what to change: PR size budgets, stacked pull requests, AI code review as a first pass, agents that answer their own review comments, and a clear rule about who is accountable. It ends with a policy template a team can adopt.

What does the data say about AI-generated pull requests?

Two large datasets agree: AI-assisted pull requests are bigger, and more of them sit unreviewed or never merge. Individual output goes up; delivery at team level doesn't follow.

LinearB's analysis of 8.1 million pull requests (May 2026) across 4,800 teams in 42 countries is the most detailed. Faros AI's AI Productivity Paradox report (July 2025), based on more than 10,000 developers in 1,255 teams, found the same shape a year earlier.

Read these as signals, not laws. Both are vendor studies of their own customers, and "AI-assisted" is classified differently in each. But one detail stands out in the LinearB numbers: once a reviewer actually starts on an AI-generated PR, the review is not slower. The wait before anyone picks it up is what explodes. Reviewers avoid large, unfamiliar diffs.

Why code review became the bottleneck

Review is the bottleneck because generating a diff now costs minutes, while understanding one still costs a human the same attention it always did. Every line an agent writes is a line someone has to read, and reading time grows with size and unfamiliarity.

Google's engineering practices put the target for a change at a size where "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large", and give the reason in one sentence: "It's easier for a reviewer to find five minutes several times to review small CLs than to set aside a 30 minute block to review one large CL." An agent that produces a 600-line PR in ten minutes has just scheduled a 30-minute block in someone else's day.

PR size budgets and stacked pull requests

The most effective fix is to make agents produce smaller pull requests, and to stack them when a change is too big for one. Size is the one variable you fully control, because the agent will split work exactly as finely as you tell it to.

A size budget is a line in the agent's rules plus a CI check: for example, fail or label any PR above a few hundred changed lines, excluding lockfiles and generated code. Google's guidance lists the splitting strategies that work: stack dependent changes, split by files that need different reviewers, split horizontally by layer or vertically by feature, and keep refactorings "in a separate CL from feature changes or bug fixes".

Stacked pull requests make that practical. GitHub put stacked PRs into public preview on 30 July 2026: "an ordered series of pull requests that each represent focused layers of your change", where each PR targets the one below it. Reviewers see a stack map and review one layer's diff at a time. Merging the top ready PR lands it and every unmerged layer below it in one operation; merging a lower layer leaves the upper ones open and rebases them automatically. The CLI comes as an extension, and GitHub mentions a gh-stack skill for coding agents:

gh extension install github/gh-stack

For agents, stacks change the instruction from "implement the feature" to "implement the feature as a stack: schema first, then the service, then the UI, one PR each, each green on its own". That is easier to review and easier to revert.

AI review as the first pass, humans for intent

Let an AI reviewer and the computational checks take the first pass, so that the human reviewer only spends attention on intent, design and risk. Don't let the AI pass replace the human one.

The tooling supports both uses, so the decision is yours. GitHub's Copilot code review docs say reviews can be triggered automatically through rulesets, that by default Copilot's approval assessment doesn't count toward required approvals, and that when "Copilot approvals" are enabled it "can submit an approving review that satisfies your repository's required-approval rule". The same page warns: "Copilot is not guaranteed to spot all problems or issues in a pull request." My recommendation is to leave AI approvals off for anything that ships to production.

The first pass works best when it's layered: deterministic sensors first (tests, types, linters, mutation testing on the diff, as described in harness engineering), then an AI review for semantic issues, then the human. By the time a person opens the PR, the questions left should be "is this the right change?" and "what could this break?", not "did you run the tests?".

Closing the loop: agents that answer review comments

When a human does comment, the agent that wrote the PR should do the follow-up work: fix each comment, prove the fix, and reply on the thread. The reviewer's second pass then takes minutes.

My review-loop skill works like this. It collects every review comment on the PR through the GitHub API, fixes them, and marks each thread as fixed, partial, unresolved or not applicable. It re-runs the tests and static analysis, and repeats. After three rounds without progress it stops and hands over to me, because a fourth attempt at the same comment rarely goes better. At the end it replies to every thread, citing the commit that addressed it, so the reviewer can check each answer against a specific diff. The skill is described in more detail in my coding agent skills workflow, and the stop logic is a general pattern covered in the agent loop, explained.

If the AI first pass produces many findings, triage them before the agent starts fixing. A typed classifier that labels each finding as fix now, backlog or needs a human is cheaper and more consistent than asking a general model to "decide what matters"; that approach is described in typed decisions for routing and triage.

Trade-offs: what these rules cost

Every rule here buys review speed with something else, and some teams shouldn't adopt all of them. Know the price before you write the policy.

• Size budgets add overhead. More PRs means more CI runs and more context switching. For a one-off migration generated by a codemod, one large PR with a clear description is easier to review than twenty small ones.
• Stacks need tooling discipline. A stack that nobody rebases decays quickly. GitHub's stacked PRs are a public preview as of September 2026, so check what your merge queue supports before relying on them.
• AI review adds noise. A reviewer bot that posts many low-value comments teaches people to ignore it. Tune its instructions until most comments lead to a change, or turn it off.
• Human review doesn't scale linearly. If agents triple output, reviewers don't triple. At some point the right answer is fewer PRs: generate less, and spend agent time on tests and cleanup instead of new features.

A team policy for agent-written pull requests

A written policy removes the guesswork for both reviewers and agents. Put it in the contribution guide and in the agents' rules files, so the same rules apply whoever, or whatever, opens the PR.

1. A named human owns every PR. The person who asked the agent for the change is accountable for it, reviews it first and answers for it after merge.
2. Size budget: PRs above the agreed line count are split or stacked; refactorings go in their own PR.
3. Evidence in the description: what was run, with exact results, and what wasn't run and why.
4. Deterministic gate first: tests, types, linters and mutation testing on the diff must pass before review is requested.
5. AI review is advisory. It comments; it does not provide a required approval.
6. The agent answers its comments, citing a commit per thread, and stops after three rounds without progress.
7. Humans approve anything public or irreversible: merges to production branches, migrations, deployments.

The PR template my agents fill in has five fixed sections:

## Ticket
Link to the issue. No ticket, no PR.

## Description
What changed and why, in two or three sentences.

## Testing
Commands run and exact results. Anything not run, and why.

## How to test
Steps a reviewer can follow to see the change working.

## Deployment notes
Migrations, config, feature flags, rollback. "None" if none.

If you're working out how to fit coding agents into your team's review process, see AI engineering.

Sources

1. LinearB: What 8 million pull requests reveal about engineering productivity (May 2026)
2. Faros AI: The AI Productivity Paradox report (Jul 2025)
3. Google Engineering Practices: Small CLs
4. GitHub Changelog: Stacked pull requests are now in public preview (Jul 2026)
5. GitHub Docs: Copilot code review