Everyone writing about AI and code review quotes the same statistic. Median pull request review time is up 441.5%.
It gets credited to DORA. It did not come from DORA, and of the three review numbers in the report it did come from, it is the least useful one.
Whose number it actually is
The 441.5% is from Faros AI's AI Engineering Report 2026, subtitled The Acceleration Whiplash. Two years of telemetry from 22,000 developers across more than 4,000 teams, comparing each organisation's period of lowest AI adoption against its own period of highest adoption.
DORA's page reports nothing of the kind. It is a survey of 1,110 responses. It says 90% of technology professionals use AI at work, that over 80% believe it made them more productive, and that higher adoption correlates with more delivery throughput and more delivery instability.
Useful work, and a completely different kind of evidence. A survey records what developers say. Telemetry records what their git history did.
I should own this one. My own post on when to keep work in-house cited these figures as DORA's and linked dora.dev. That was wrong. It is fixed now.
The attribution matters past pedantry. In a planning meeting arguing for review capacity, "a survey found people feel review got slower" and "telemetry across four thousand teams measured median time in review rising 441.5%" land very differently, and only one of them survives a sceptical VP.
Three numbers, and the famous one is the least interesting
Faros splits the review pipeline into three measurements:
| Measure | Change |
|---|---|
| Median time to first PR review | +156.6% |
| Average time in PR review | +199.6% |
| Median time in PR review | +441.5% |
Everyone quotes the third.
The first is the one I would put in front of a manager. Time to first review is queue wait. It is the gap between a pull request opening and any human looking at it at all. That number is untouched by how hard the code is to read, because at that point nobody has read a line of it.
A 156.6% rise in queue wait says your reviewers are already saturated before the difficulty of any individual PR enters the picture. The only two things that move it are more reviewer capacity and less arriving work, neither of which arrives with better review tooling.
The 441.5% blends queue wait, reading time and every round of back-and-forth into a single figure. A rise in it is equally consistent with saturated reviewers and with code that has become harder to read, so it tells you the pipeline hurts while leaving you to guess which of the two you are paying for. The first number answers that question on its own.
Where the size answer runs out
The standard advice attached to the 441.5% is to write smaller pull requests. Average PR size is up 51.3%, so the advice has a basis.
Read the footnote though. Faros notes that 51.3% is down from the 154% increase in their previous report, and flags that "the two datasets differ in size, composition, and time period, so direct comparison should be treated as directional."
Take it as directional and it still cuts against the simple story. Size inflation looks like it is easing while review time is going the other way, hard. Something other than line count is eating the reviewers.
The finding the headline buried
Faros offers its own explanation, and it is the most useful sentence in the report:
the code arriving for review is often not review-ready. Reviewers are not just assessing more code, they appear to be working harder to bring that code up to a standard it should have met before the PR was opened.
That reframes the whole problem. The review queue is now where code gets finished.
The report names the mechanism too. AI-generated code is "often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase." The structural and logical failures sit beneath that surface, and catching them means reading carefully, reasoning about intent and reconstructing the problem the code was meant to solve. Faros calls this "slow, expensive cognitive work" and points out who ends up doing it: your senior engineers, the exact people you were hoping to free up.
The rest of the numbers follow from that. Merges with no review at all are up 31.3% and bugs per developer are up 54%. The incident-to-PR ratio is up 242.7%. Code churn, measured as lines deleted against lines added for merged code in a quarter, is up 861%.
That last one deserves a moment. Churn at that scale means an enormous share of what got merged was thrown away shortly afterwards, which makes every throughput figure in the same report an overstatement of what actually survived.
What this changes about how you work
Make the code review-ready before it becomes a pull request. This is the report's own conclusion, and it does more for the queue than anything else on this list. Every check a reviewer would run, run it first: the test suite, the linter, a self-review pass over the full diff. An agent that opens a PR the moment its code compiles has moved the unfinished work into someone else's queue, where it costs senior time instead of agent time.
Approve the plan while it is still cheap. Deciding what gets built is a review, and doing it before the diff exists costs minutes rather than hours. Plan mode pays off in the review queue: the diff arrives already shaped, so the reviewer spends the time reading code instead of reverse-engineering intent from 900 lines.
Triage by risk. Because the first number is queue wait, what you control is which PR gets picked up first. A migration, an auth change and a permission boundary deserve a senior reviewer today. A dependency bump can wait until Friday.
Watch what "reviewed" means in your own numbers. If a bot leaves comments on a pull request and it merges, most dashboards count that as reviewed, and the bureaucracy of bots is what that becomes at scale: a bot reviewing a bot, with nobody at either end who can explain the decision afterwards. Count how many of your reviews had a person attached, and when one did, remember that what to look for in an agent's pull request is a different checklist from the one you use on a colleague.
The shape of this is old. Your 10x developer is gated by a 0.1x pipeline made the structural version of the argument: generation got cheap, the machinery that turns generated code into shipped value did not, so the constraint moved downstream. Faros put a measurement on where it landed.
The queue is where the code gets finished now. That work was always going to happen somewhere. Right now it is happening in the most expensive place you own, performed by the people you can least afford to spend there, and counted as review.