Why AI-generated pull requests wait 4.6 times longer for review

AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up: over 16 hours, against roughly 200 minutes for everything else. That figure comes from LinearB's 2026 Software Engineering Benchmarks, built from 8.1 million pull requests across more than 4,800 organisations. Once a reviewer actually starts, an AI pull request finishes faster than a human-written one, about 194 minutes against 252. The whole delay accrues while the pull request sits untouched in the queue, which makes it a comprehension cost paid up front.

What LinearB measured

The benchmark separates two things most teams report as one number. Pickup time is how long a pull request waits from being opened to a reviewer's first action on it. Review time is how long the review itself takes once that action happens. Teams tend to watch cycle time, which sums them and hides which half moved.

In the 2026 data, review time for AI pull requests improved and pickup time got much worse. Agentic pull requests, the ones opened by an agent rather than assisted by one, waited 5.3 times longer at the 75th percentile. The tail is where this hurts: a p75 number describes the pull request that is annoying enough to skip, and those are the ones that sit overnight.

The wait happens before anyone opens the pull request

A reviewer scanning a list of open pull requests is doing triage on almost no information. Title, author, file count, line count, maybe a description. From that they estimate what each one will cost, and they take the cheap ones first. Nobody decides this deliberately. It is what a person does with a queue and forty minutes before a meeting.

Pickup time measures what a pull request looks like it will cost, before anybody has found out. An agent's pull request advertises itself badly. It is large, it spans directories that have no obvious relationship, and it carries a description written by the same process that wrote the code, so the description confirms rather than explains. The reviewer's estimate lands high, and the pull request goes to the bottom.

A bigger change with no reading order

Size is the first half. LinearB found AI-assisted pull requests run 408 lines at the 75th percentile against 157 for unassisted ones, roughly two and a half times the reading.

Structure is the second half, and it matters more. Salesforce Engineering, writing about their own surge in AI-generated code, observed that agent pull requests span backend, config, tests and UI without preserving narrative structure. A human building the same feature leaves a trail: commits in the order they thought of things, the interesting file first, a description that says which part they were unsure about. An agent emits everything at once. Every file looks equally important, which means none of them tells you where to start.

Put those together and the reviewer faces 400 lines across a dozen files with no entry point. The first ten minutes of that review are spent working out what the change is even about, and that cost is entirely predictable from the outside, which is exactly why the pull request gets deferred. I go into what that first ten minutes is doing to your working memory in cognitive load in code review.

Review runs faster once it starts

The 194-minutes-against-252 result surprised me the first time I read it, and it is the most useful number in the benchmark. Agent-written code is often easier to review line by line. It is consistent, it follows the conventions it was told about, it has tests attached, and it rarely does anything clever. Once you know what the change is, checking it is quick.

So the hard part is the transition from "I have a diff" to "I know what this change is". Everything after that transition is already fine.

Acceptance rate is where the cost lands

The other number worth carrying from the benchmarks: acceptance rate for AI-generated pull requests is 32.7%, against 84.4% for manual ones. Two thirds of agent pull requests do not make it in.

That reframes the wait. A reviewer deferring an agent pull request is making a decent bet, since the base rate says it is likely to be rejected or abandoned anyway. The queue behaviour is rational at the level of the individual reviewer and terrible for the team, because the abandoned two thirds still cost review attention before they die, and the good third waits behind them.

There is a related finding in the 2026 paper "These Aren't the Reviews You're Looking For", which examined 33,596 agent-authored pull requests and found 61.38% received no recorded human review at all. When a queue gets long enough, some of it stops being a queue. I walk through that paper in six in ten agent pull requests are never reviewed by a human.

Would more reviewers fix it?

Only for a while, and you probably cannot hire them fast enough. Faros AI reports feature-branch throughput up 59% year on year under high AI adoption, and pull requests that skip review entirely rising 31.3%. Output went up, review capacity stayed roughly flat, and the difference came out of the review step.

Adding reviewers divides the queue without changing what any one review costs. If a change takes forty minutes to understand, a second reviewer buys you two of those a day and burns a senior engineer doing it, since the person who can hold the architecture in their head is the person the queue routes to. The arithmetic of that is in ten times the pull requests, one reviewer, and it comes out the same way every time: the only input still worth moving is the cost of understanding one change.

What shortens pickup time

Three things work, in increasing order of how much they cost you.

Write a real description. Say what changed and why, in the terms of the system rather than the terms of the diff. This is free and most agent pull requests skip it.

Make the change advertise its own size honestly. A reviewer who can see that a 400-line pull request is 380 lines of generated fixtures and 20 lines of logic will pick it up immediately. A reviewer who cannot see that assumes the worst.

Give the change a shape before the reviewer has to build one. This is the expensive one to do by hand and the one worth automating, because the reviewer builds that picture anyway; the only question is whether they build it from scratch every time. How to review a 400-line pull request in ten minutes is the by-hand version of the routine, and the complete guide to reviewing AI-generated pull requests is the longer method behind it.

What we did about it

PR Lens exists because of this specific gap. It draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request itself, redrawn on every push. Green is new, amber is changed, red is gone. The parts of the system the change did not touch stay on the page, so the picture is a map of where the change landed.

The point is what the reviewer sees during triage. A pull request carrying a diagram gives up its shape in the notification email, before anyone decides whether today is the day. That is the moment where sixteen hours is either spent or not, and it happens long before the first line of code gets read.