Short answer
Why didn't AI make teams ship faster? Because writing code was never the slow part. Faros AI found high-AI teams merge 98% more pull requests while review time per PR rose 91% and PRs grew 154%. The work piled up in front of human reviewers, so the fix is to change review, not to type faster.
Your developers have Copilot, Cursor or Claude Code. They say they are faster, and the commit graph agrees. Yet the release date for the feature everyone is waiting on hasn’t moved. Pull requests sit open for days, the two people who know the payment code are buried in review requests, and standups have turned into a list of “waiting on review”.
That is not a failure of the tools. It is what happens when one stage of a pipeline gets much faster and the next stage doesn’t. Code review was always a queue. AI made the queue longer.
What the data says about AI and code review
The clearest numbers come from Faros AI’s 2025 Productivity Paradox report, which looked at telemetry from over 10,000 developers on 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. The same teams saw review time per pull request rise 91%, average PR size grow 154% and bugs per developer go up 9%.
The detail that matters most is in the same report: Faros found no significant correlation between AI adoption and improvement at the company level. Teams did more. The organisation didn’t ship more. Twice as many pull requests entering a stage that takes nearly twice as long per item is a recipe for a traffic jam, and that is what the numbers describe.
DORA’s 2025 report on AI-assisted development reaches a similar conclusion from survey data. AI now correlates with higher delivery throughput, but software delivery instability keeps rising too. DORA calls AI an amplifier: it magnifies whatever the organisation already does well or badly. If review was already slow, AI makes it the slowest thing you have.
Why review time grew 91%
Several things compound here, and none of them is “reviewers got lazy”.
More pull requests arrive. If the number of reviewers stays the same and their utilisation was already high, waiting time does not grow in a straight line. Queues behave badly near full capacity: going from 70% to 95% busy multiplies the wait, it doesn’t add a little to it.
Each pull request is bigger. Agents happily produce 800-line changes because typing costs them nothing. Review research has said for years that this is where quality falls apart. SmartBear’s study of a Cisco team recommends reviewing 200 to 400 lines at a time, at under 500 lines an hour, and notes that the ability to find defects drops beyond 400 lines. A 1,000-line diff is not one review. It is three reviews pretending to be one.
The author knows less about the code. When a person writes code, the reviewer can ask “why did you do it this way?” and get an answer. When an agent wrote it and the developer skimmed it, the honest answer is often “the model did that”. The reviewer now has to reconstruct the intent from scratch, which is slower than checking someone else’s reasoning.
And the code looks right. AI-written code is fluent. It has sensible names and comments and passes a glance. The bugs are in what it assumed, not in how it reads, so a careful reviewer has to slow down further.
A pull request spends most of its life waiting
Look at the path a typical change takes. Most of the elapsed time is not anyone working. It is a pull request sitting in someone’s queue.
Where a pull request waits on people
- Agent
- Person
- Automated check
Steps as text
| Step | What happens |
|---|---|
| 1. Agent writes code | Agent — minutes |
| 2. Developer skims it | Person — waits for a free hour |
| 3. CI runs | Automated check — build, tests, lint |
| 4. Reviewer picks it up | Person — waits in a queue for hours or days |
| 5. Author fixes comments | Person — waits for context to return |
| 6. Merge | Automated check |
| Loop | another review round: back from step 5 to step 4 |
Three of the six steps are a person, and each one starts with a wait. The agent’s part shrank from hours to minutes, which is exactly why the rest became visible. I wrote about mapping these waits in more detail in where the hours go, and about why a faster coding step barely moves the total in Amdahl’s law for software teams.
Approaches that make the bottleneck worse
Some common reactions feel responsible and make the problem bigger.
Adding a second required reviewer to “be safe with AI code” doubles the queue for every change, including the trivial ones. It spreads attention thinner rather than making any one review deeper.
Asking developers to “use AI more” to hit an output target pushes more work into the same narrow stage. You will get more pull requests and the same number of releases.
Rubber-stamping is the quiet failure. When the queue gets long enough, people approve what they did not read. The review still happens on paper, the bugs get through, and DORA’s rising instability is the bill that arrives later.
Bolting on an AI review bot that leaves twenty style comments per pull request adds noise. If the human still has to read every line plus every bot comment, you added work to the bottleneck, not taken it away.
What actually moves the review bottleneck
The goal is to make each human review smaller, rarer and better informed, or to remove it for changes where a person adds little.
- Cap diff size. Make agents work in slices that land as pull requests under about 400 changed lines. This is the cheapest change with the biggest effect, and I cover the mechanics in small diffs for AI agents.
- Require evidence, not claims. A pull request should arrive with the commands that were run and their exit codes: build, tests, any check written for the acceptance criteria. A reviewer who sees proof can skip re-verifying it.
- Put an independent machine reviewer before the person. A different model reading the real diff against the criteria catches a lot of what a tired human would. The human then reviews something that has already survived one round.
- Move disagreement before code exists. The most expensive review comment is “this whole approach is wrong”, because it arrives after the work is done. Settling the approach first is cheaper than arguing about it in a diff.
- Route by risk. Not every change needs the same review. Decide in advance which classes of change need a person.
On the fourth point I have one public data point of my own. I gave one task to three setups and published the prompt and procedure. Claude Code alone took 3.7 hours and left about 13 bugs. Adding one review at the end cut bugs to about 7 but made the run longer, 4.2 hours. Having two models write independent positions before any code took 1.5 hours with no broken mechanics. It is one task with bugs counted by hand, so treat it as an illustration, but the direction matches what review research has said for decades: catching a problem earlier is cheaper.
For the fifth point, a simple routing table is enough to start with.
| Change class | Example | Who reviews |
|---|---|---|
| Mechanical | dependency bumps, renames, formatting | checks plus machine review only |
| Local logic | a screen, a handler, a query behind a test | machine review, person samples a share |
| Shared contracts | public APIs, schemas, migrations | machine review plus a person |
| High blast radius | payments, auth, data deletion | a person who owns that area, always |
Where review is heading
Here is the bold version, and I think it is where most teams will end up. For the first two rows of that table, a person reading every diff adds very little. The defects that matter in those changes are caught by tests, by checks written from acceptance criteria and by a reviewer model that did not write the code. Human review there mostly adds waiting.
That does not mean trusting the writer. It means building a pipeline where trust comes from independent checks, not from a person’s signature. Google said in 2024 that more than a quarter of its new code was AI-generated and then reviewed by engineers. The next step is deciding which of that code still needs the engineer. I walk through a staged way to get there in can you take people out of code review.
The teams that get faster will not be the ones whose developers type the most prompts. They will be the ones that redesigned review for a world where code is cheap and attention is not.
Questions
Why is code review a bottleneck with AI coding tools?
AI made writing code much faster, but review still depends on a few people reading every change. Faros AI measured 98% more pull requests and 91% longer review time per pull request on high-AI teams, so work piles up in front of reviewers.
Does AI code review replace human reviewers?
Not wholesale today. An independent AI reviewer works well as a first pass that catches defects and checks evidence before a person looks, and for low-risk change classes it can be the only review once your tests and checks are trustworthy.
How big should a pull request be when an AI agent writes it?
Keep it under about 400 changed lines. SmartBear’s study of a Cisco team found defect detection falls beyond 400 lines at a time, and that holds whether a person or an agent wrote the code.
How do I measure whether review is my bottleneck?
Track the time from a pull request being opened to its first review and to merge, next to the time spent writing it. If waiting is several times longer than writing, review is your constraint.