How to fix the AI code review bottleneck

How long AI pull requests wait for review

Agent pull requests are the slowest work in the queue, and in the vendor's data most of that time passes before anyone looks at them². Once opened, they are also reviewed the slowest of the three groups the vendor tracks². The longer wait does not end in more merges, either: they merge within 30 days far less often than unassisted ones¹.

The two sources disagree on where the delay sits. A two-year study of one mid-sized company, controlling for change size, found the pickup delay comparatively small³. There the extra time sat between first human review and merge, about 20% longer for AI-authored pull requests³. Our guess, which neither source tests, is that both delays come from checking the author skipped.

At Acme, the CSV export pull request opened at night is still unopened at lunch. When a reviewer does open it, the questions start: what is this for, why is it so large, and did anyone run it?

Who owns an AI pull request

Agent work often reaches review with nobody vouching for it, so the reviewer becomes the first person to check it. One vendor names three drivers, without measuring them: unclear ownership of agent-created work, agents pointed at low-priority backlog items, and reviewers hesitating on larger changes¹. The backlog driver is a plainer explanation on its own: reviewers put off low-priority work, checked or not. We think ownership and priority travel together, since work nobody asked for today has nobody to vouch for it.

One study hand-coded rejected agent pull requests in public repositories, and its results fit an ownership gap without measuring it. The most frequent pattern was reviewers simply abandoning them, at 38%⁵. Duplicates affected 23%, where maintainers pointed to an existing pull request that already made the same change⁵. Our read is that both point to work nobody owned, though duplicates in public repositories can also come from separate contributors working in parallel.

A second study adds a caution: rejection outcomes overstate agent error, and many rejections come from workflow constraints or give no visible reason⁶. Among merged agent pull requests, 15.4% needed the reviewer to step in through feedback or direct commits⁶. The study gives no human baseline to compare that with.

Open-source projects now say this plainly. A terminal project's policy says low-effort work puts the burden of validation on the maintainer⁷. A principal engineer put the cost in attention: work the author never checked spends the reviewer's attention and gives nothing back⁸.

At Acme, the CSV export came from the backlog, so no engineer owns it. Nobody can say why it builds the whole file in memory, and a half-done branch for the same export already exists. The reviewer is doing the author's job: finding out what the change is for and whether it works.

What slowed code review before AI

Large changes and failing checks also slowed review long before AI, and agents produce more of both. At the same percentile, agent pull requests in the vendor's data reach 293 lines against 157 for unassisted ones².

In public repositories, agent pull requests that were not merged tend to be larger, touch more files and fail the project's CI checks⁵. Each extra failed check goes with about 15% lower odds of a merge⁵. That is an association in public data; it does not prove that running checks first changes the outcome. Still, every failing check is one the author could have seen before asking anyone to look.

A 2018 study of code review at one very large software company found that first feedback on a very large change took several times as long as on a small one⁹. Those are human changes from years ago, so take the principle from them: small changes get fast first feedback.

DORA's 2025 report says AI's acceleration can expose weaknesses downstream¹⁰, and review is downstream.

Agents do write bad code; about a third of the rejected agent pull requests above were the agent's fault⁶. We think the shape the code arrives in matters as much, and the size and check evidence points there.

One engineering leader in the vendor's survey named the shape problem.

At Acme, the CSV ticket needed one endpoint. The pull request also reformats the invoices table and fails one lint check. Acme's reviewers saw oversized changes and unrun checks long before the agent; the agent just sends more of them.

What happens when reviewers read less, or a bot reviews

The longest study we found followed a mid-sized company for more than two years, about ten months of it under a mandate to use AI, and its reviewers kept pace by reading less. Per-reviewer load roughly doubled and automated review overtook human review³. Merge and revert rates held steady, so the volume got through.

What thinned was the human part: a typical reviewer's silent approvals roughly doubled while their commented reviews stayed flat³. The authors note that merge and revert rates miss defects, incidents and maintainability, so thinner review may not have shown up yet.

A bot reviewer does not fill that gap on its own. Across open-source repositories, even the best AI review tool's valid comments led to a code change far less often than human reviewers' comments did¹¹.

A large consumer internet company that built its own reviewer found that developers ignore review comments entirely when faced with too many, much like alert fatigue¹².

The only randomized evidence we found puts machine-written fixes with the author. In production experiments at a large technology company, AI wrote fixes for human reviewers' comments; showing those fixes to reviewers raised review time by over 5%¹³. In a second experiment the fixes went to authors and were collapsed for reviewers, and the authors still accepted them at a similar rate¹³.

The end state, as one developer tells it, is code nobody on the team can explain.

At Acme, under pressure, a second engineer approves the CSV pull request with no comment. The bot reviewer left a long list of suggestions, and nobody read them.

The fix: the author checks the PR before review

When the reviewer is the first to check, the fix is to make the author check first. The compiler project's policy says it in one line: contributors must read and review all generated code before they ask anyone else to review it¹⁴. A data storage project asks authors to explain why each change is correct and to leave out loosely related changes¹⁵.

Practitioners apply the same rule. One engineer suggests making authors present the code live and say what it does, so they own it⁴. Another now requires proof before reviewing anything.

Rules like this slip under pressure. One commenter's company expects self-review, which works well enough, but people sometimes still wave their own work through to the team when they are in a rush⁴. So pair the rule with a gate: tests and lint pass before a reviewer can be requested, and machine-written fixes and bot notes go to the author first. For bot notes that is our extrapolation from the randomized result on AI fixes¹³.

One lead committed shared agent rules, pre-commit checks and CI gates, with automated review on top. After a week of that setup, the lead says, reviewing a junior's code takes a few minutes⁴. It is one anecdote, and automated review earns part of the credit, so it shows only that a gate before the human can help.

Size is the contested part. One code host's own guidance on agent work says a change that needs a long description to review is probably too big¹⁶. One CTO dropped the company's small pull request rule, and every change there now gets a risk label instead¹⁷.

No study we found measures a size cap for agent work, or whether checking by the author shortens the wait. The randomized result on where machine fixes go is the closest evidence, so read the fix as our analysis, not a measured remedy.

At Acme, the same export now has an owner. The owning engineer splits it in two, gets the checks green and works through the bot's suggestions before a human sees it. The reviewer reads a short change someone has already verified.

A pull request template puts the rule on every change. This is the one Acme keeps.

## Owner
Who can explain each line:

## Why
Ticket link:
What it does, in your own words:

## Proof
How you know it works:
(test output, screenshot or logs)

## Repro
Steps a reviewer can follow:

## Before review
- [ ] I read every line myself
- [ ] Tests and lint pass
- [ ] Bot notes handled or answered
- [ ] Nothing outside the ticket

What to do on Monday

1. Split the wait. Measure pickup time and time from first review to merge separately, for agent, AI-assisted and human pull requests.
2. Count real review. Track the share of pull requests with at least one substantive human comment, not only approvals.
3. Name an owner. Every agent pull request gets a named engineer who can explain each change and attaches proof and a repro before review.
4. Gate before the human. Tests, lint and the AI reviewer run before a reviewer is requested, and the bot's suggestions go to the author.
5. Pair the count. Report merged pull requests next to review wait, queue depth and revert rate, against your own last quarter.

The companion, The AI-ready engineering team playbook, is free with your work email.