Linearb's 2026 Engineering Benchmarks Report analyzed 8.1+ million pull requests across 4,800+ organizations, and one finding cuts against most of what you read about AI review speed. AI-generated PRs wait 4.6x longer before anyone picks them up. But once they're picked up, they get reviewed 2x faster than manual work.
So the time you're trying to shave with AI isn't the reading part. It's the waiting part.
The wait is the real number. A typical AI PR sits 16+ hours before a human opens it, versus around 200 minutes for unassisted work. The merge numbers are harsher: only 32.7% of AI-generated PRs merge within 30 days, versus 84.4% for manual. Reviewers hesitate on that 408-line AI PR at the 75th percentile (vs 157 lines manual) precisely because nobody wants to be the one who approved the thing that missed the context.
Graphite's own writeup on AI code review and review cycles makes the same point from the other side: their median engineer takes ~13 hours to merge a PR and spends most of that waiting on a reviewer becoming available. The review itself is the small part.
Mean-time-to-merge isn't the whole story either. A mean drops when AI eats the easy set and the regression hides in the tail. Same trap I flagged with revisiting a vendor's published number vs running your own slice. Don't trust a single time-saved percentage; run your own 2-week slice, split by PR size, and measure time-to-first-review separately from time-in-review. If the fix is a faster reviewer, you've automated the wrong step.
The honest takeaway: AI review doesn't speed up your loop by being a smarter reader. It speeds it up by breaking the pick-up bottleneck, so a reviewer can engage the moment the PR is ready, and by shrinking the second pass once a human actually sits down. Buy the tool on the wait cut, not the "reviewed 10x faster" headline. And keep the human in the loop for the big-move PRs, because that's where the 32.7% merge rate comes from.
Top comments (1)
This is a useful distinction. I’d add one control to the two-week slice: record the timestamp when a PR becomes reviewable separately from the first human review, then split the results by PR size, team, time of day, and whether the PR was agent-generated. Otherwise a routing or queueing change can look like a model improvement. For the tail, I’d track reopen-after-merge, rollback, and escaped-defect rates alongside time-to-first-review. Since the percentages come from a vendor-published benchmark, I’d treat them as a hypothesis and validate the same definitions on a local slice before buying on the headline.