AI Writes Code 30% Faster. Your Review Queue Just Got 4.6x Slower.

AI-authored pull requests wait 4.6 times longer for a human to start reviewing them than code a person wrote by hand.

That number comes from LinearB's 2026 Software Engineering Benchmarks Report, an analysis of 8.1 million pull requests across 4,800 organizations in 42 countries. It's the largest read we have on what AI coding tools are actually doing to delivery, and the headline isn't the one most teams expected. The code is getting written faster. The software isn't shipping much faster. Those two facts live right next to each other, and the space between them is a review queue.

If you lead a team that adopted Copilot or Cursor or Claude Code in the last year, you've probably watched your pull request count climb and quietly wondered why the release calendar didn't move with it. This is why.

The constraint moved, and most teams are still speeding up the old one

For twenty years the scarce resource in software delivery was typing. Writing code was the slow, expensive, human-limited step, so every tool, every process, every hiring plan was built to make more of it. AI made that step cheap almost overnight. The teams in LinearB's data are generating far more work: developers using AI complete 21% more tasks and merge 98% more pull requests, according to a read of the same benchmark data on dev.to.

Merging twice as many PRs sounds like a win until you ask who reviews them. Because the review step didn't get an AI. A human still has to read the code, understand the intent, decide whether it's safe, and take responsibility for what happens when it's live. That human's day is the same length it was in 2024.

So the queue backs up. LinearB found teams generating 200-plus pull requests a week with the review capacity they had when they were generating 80. The work didn't get faster. It got relocated, from a step you'd spent two decades speeding up to a step you'd mostly ignored.

Reviewers aren't slow. They're triaging.

Here's the part that should change how you read your own dashboards. AI pull requests wait 4.6 times longer before review begins, but once a reviewer actually picks one up, they finish it 2 times faster than a human-written PR. The delay isn't in the reviewing. It's in the getting-started.

That's not laziness. That's rational triage, and the acceptance data explains it: AI-generated pull requests are accepted 32.7% of the time, human-written ones 84.4% of the time. A reviewer staring at a stack of PRs has learned, correctly, that the AI-authored ones are more likely to be wrong, so they reach for the human-written work first. They're protecting their own time from a queue that's mostly going to bounce.

The developer survey data lines up with the behavior. In SonarSource's 2026 State of Code survey, 96% of developers said they don't fully trust that AI-generated code is functionally correct, and 38% said reviewing AI code takes more effort than reviewing a colleague's. Your reviewers distrust the code and find it more tiring to check. Then you hand them three times more of it. The queue is the predictable result, not a surprise.

It compounds because the two things that made human review fast are both missing. A person reviewing a colleague's code leans hard on context they already have: I know how this person thinks, I know they ran it, I trust the shape of their work before I've read a line. An AI pull request strips all of that away. The author was a model prompted at 4pm, so the reviewer can't lean on the author's judgment, because there wasn't any – every line has to be earned from scratch. More code, from a source you trust less, with none of the social shortcuts that used to let a reviewer skim with confidence. That's not a gap a better model closes. It's a permanent change in what the review step has to do, and it lands on the same people who were already full.

The math nobody put on the roadmap

Play it forward. You gave forty engineers AI tools and told the board you'd expect a productivity lift. Generation roughly doubled; review capacity held flat. Two-thirds of the new AI pull requests will bounce, but a reviewer has to open each one to find that out. So the effort you saved on the left side of the pipeline reappears, larger, on the right.

This is why so many teams report the strange feeling of working harder and shipping the same. The activity metrics look incredible. Commits up, PRs up, lines up. The outcome metric, working software in front of users, barely twitches. You got faster at the one thing that was never actually your bottleneck.

It's worth saying plainly, because a lot of tooling pitches depend on you not saying it: buying more generation to fix a review bottleneck is buying a faster horse to beat a traffic jam. The road is the constraint. The horse was never the problem.

What to actually do about it

The instinct, when a queue backs up, is to tell people to review faster. That instinct is wrong here, and the acceptance rates are why. You do not want your reviewers moving faster through code that fails two times out of three. Speeding up the one accountability step you have left is how the verification problem becomes a production incident.

The work is to treat review as the constrained resource it now is, and manage it like one.

Cap the work in progress on review, not just on coding. Most teams put no limit on how many open PRs a person is expected to hold, which means the queue is invisible until it's a crisis. Make it visible. A reviewer with eleven open pull requests isn't a fast reviewer waiting to happen; they're a bottleneck with a name.

Shrink the pull requests. The reason AI PRs bounce is partly that they arrive large and speculative, generated in a burst rather than shaped for a reader. A 60-line change a reviewer can hold in their head clears the queue. A 600-line one sits there. If your AI workflow produces big diffs, the fix is upstream of review: smaller units of change, scoped before generation.

Give the code an owner before it's written, not after it fails. The teams that move AI-generated work through review fastest are the ones where a human decided, in advance, what this change is for and who's accountable for it. That's not a tool you buy. That's a decision you make.

And if you're a leader deciding where to spend the next dollar, the honest question isn't "how do we generate more?" It's "where is the constraint right now, and am I feeding it or starving it?" That question is the whole job. You already manage flow this way in every other part of your operation, where you'd never staff a warehouse's loading dock at triple its shipping capacity and call it efficiency. Software is the one place we keep pretending the loading dock is free.

That's the Research-then-Strategy move, applied to your own delivery: answer the real question first – where does the work actually pile up? – and then point your investment at the answer instead of at the loudest vendor. The pull requests will keep coming faster. Whether any of it reaches a user depends on a step no model is going to do for you.

Faster typing was never the finish line. It was the part we'd already won.