Where the AI Speed-Up Goes: Into the Review Queue

On my own backlog, 30 agent-written PRs merged a median 44 minutes after they opened, review and fixes included. Across companies, DX measured AI adding just under 8% to PR throughput, and Faros measured median review time up 5x, which points at the review queue. My explanation for the gap, which the timestamps support and can't prove: the one reviewer had written the tickets and was expecting the PRs.

For my own work I estimate 2–3x, and not more. The merge timestamps are measured; the solo baseline is my estimate, and the arithmetic is below. In LinearB's 2026 data, AI-written PRs wait more than 16 hours on average just for a reviewer to pick them up. The vendor answer is to automate the first pass with a tool. Mine is cheaper: name an owner for review pickup time, then measure it.

How much faster is AI coding, according to the data?#

The large studies find small gains. I take them seriously because they measure merged work:

• DX, 11 Mar 2026: in a random sample drawn from 400 companies (Nov 2024 to Feb 2026), AI usage rose 65% and PR throughput rose 7.76%. The author, Justin Reock, adds from talks with engineering leaders that most organizations land between 5% and 15%. (DX newsletter) DX's 2026 benchmarks (last updated 21 Jul 2026) report PR throughput up nearly 20%. (DX benchmarks)
• LinearB, 4 May 2026: across 8.1 million PRs from 4,800 teams, AI-generated PRs waited more than 16 hours on average before a reviewer picked them up, against about 200 minutes for unassisted work. Only 32.7% of AI PRs merged within 30 days, against 84.5% of manual ones. (LinearB)
• Faros, 2026: its "Acceleration Whiplash" report, two years of telemetry from 22,000 developers across 4,000 teams, found median review time up 5x and PR size up 51%, while deployments per week fell 11.7%. The report is labelled Q2 2026; the page gives no publish date. (Faros AI) Its July 2025 study had already seen review time up 91% on high-adoption teams.
• METR, 24 Feb 2026: its 2025 trial had experienced developers 19% slower with AI. The 2026 update estimates 18% faster for the original group and 4% faster for new recruits, with confidence intervals that cross zero. METR thinks AI speeds developers up more than in early 2025, and calls its own data "only very weak evidence" for how big that increase is. (METR)

LinearB and Faros put the delay at review, and DX and METR find gains that are small or uncertain. DX's nearly 20% is PR throughput from all causes, not a measured AI effect. Against that data, 2–3x is the high claim, so it needs its arithmetic shown.

My clock: 30 agent PRs, from open to merge#

In March 2026 an agent fleet opened 31 PRs on my own admin dashboard and I merged 30 after review; the full account, including what review caught and missed, is in the 30-PR case study. Here is only the clock, pulled from GitHub with gh pr list --json createdAt,mergedAt on 12 Oct 2026:

The October run on this site has the same shape: nine PRs merged a median 27 minutes after opening, in 2 sittings. Across the 36 PRs merged on this repo from 10 October to 14:57 UTC on 12 October, the median was 27 minutes and the 90th percentile 2.3 hours.

Here is the division. The solo side is my estimate of 5–7 working days. The elapsed side is 2.1 days from the first worker wave to the last merge, or 2.8 days from the first PR, nights included. 5–7 days over 2.1–2.8 days gives 1.8x to 3.3x, which I round to 2–3x and quote as an estimate. Of 30 PRs, one waited longer than 16 hours. It was #95, the first PR, opened a day before the worker waves started; the second slowest, #97 at 9.5 hours, redid a PR I had closed.

Why didn't my agent PRs wait?#

Three conditions I think explain it, from one reviewer's timestamps.

1. The queue is one person who is expecting the PRs. I dispatched each agent wave and then sat down to review it. Merges landed in 9 bursts, and PR size didn't predict the wait in March: the rank correlation between lines changed and minutes waited was 0.07. The wait was set by when I sat down. My guess is that LinearB's 16 hours is mostly reviewers who weren't expecting the PR.
2. The reviewer wrote the tickets. I scoped every issue in that run, so I knew what each diff was supposed to do before I opened it. That shortens the reading, and it is something a team reviewer picking up a stranger's agent PR doesn't have.
3. Almost everything merges. 30 of 31 PRs merged, and 25 of them needed a fix commit first. Rejected work is the most expensive kind, and in LinearB's data two thirds of AI PRs hadn't merged after 30 days.

Where this breaks:

• A team of ten. Review becomes a queue between people again, and the 16 hours comes back unless someone owns pickup time.
• Unclear or greenfield work. My runs were backlog and feature work against an existing system. I haven't measured a vague "build me a product" brief, and I expect it to go slower than solo while the rewriting happens.
• Bigger PRs as the habit. My median PR changed 388 lines, close to LinearB's 400+ at the 75th percentile for AI PRs. In October, across 36 PRs, bigger ones did wait longer (rank correlation 0.56).
• The ramp. In my experience it took months of harness work (rules, hooks, review gates) before runs like these held up. I'd expect a team's first weeks to be slower than working without agents.

What review cost, and what it still missed#

Review is counted against the clock, and it isn't free. 25 of 30 PRs needed a fix commit before merge. Review fixed 3 shell-injection paths from request input before merge. It missed 5 security bugs, found when I re-audited the run on 12 October 2026: 3 shell strings, one of them from request input (#98), and 2 stored XSS sinks. They had sat in the code since March; I fixed all 5 the same day. The case study has the list.

One data point on speed: #109, one of the 5 misses, merged 29 minutes after it opened, in a sitting that merged two PRs in 13 seconds. The bug sat in the code for seven months before the re-audit found it.

That's why I won't quote a bigger number. Dropping review would make the clock look better, and the misses above happened with review in place.

How to measure review wait on your team#

You can get the measured half of this for your team from data GitHub already keeps:

gh pr list --state merged --limit 200 --json number,author,createdAt,mergedAt,additions,deletions \
  | jq -r '.[] | [.number, .author.login, ((((.mergedAt|fromdate) - (.createdAt|fromdate)) / 60) | floor)] | @tsv'

If your agents open PRs under a human's login, as mine do, split them by branch prefix or label instead of author. Then track three numbers, agent PRs against the rest:

1. Open-to-merge time, median and 90th percentile. If agent PRs wait hours, the speed-up is going into the queue.
2. Fix commits per PR before merge. This is the review cost. Mine was 25 of 30 PRs with at least one.
3. Review sittings. Merges that land minutes apart are one sitting. In my runs, a few planned sittings kept the median wait under an hour.

If the median wait for agent PRs is in hours, the cheapest gain is a named owner for pickup time, before any new tool. If nobody on the team can own it, that's the gap I fill: agents write, I review every PR before it reaches you, on my services page.

Related: what review caught and missed in the 30-PR run · how to review AI-generated code · 463 Claude Code sessions, counted.