AI made code review the bottleneck, not writing code

Your board says the team is moving. GitHub says 41 open pull requests, the oldest eleven days old, and the feature you promised for Thursday still is not out. Everyone reports feeling faster, and about their own hours they are probably right.

GitLab's AI Accountability Report, fielded by The Harris Poll among 1,528 developers and technology buyers in six countries and published 23 June 2026, found 85% agreeing that AI has shifted the bottleneck from writing code to reviewing and validating it. That is a survey, so it measures a feeling. Three telemetry datasets from this year agree with it, then contradict almost every fix sold for it.

My bias, once: I work on a project tracker. It turns up in one section near the end, with what it cannot do written down.

Three datasets, three dates, and what they actually say

Most posts on this topic quote the same pair of numbers, 98% more pull requests merged and 91% longer review time, with no date on them. Both are from Faros AI's July 2025 report. The 2026 edition is an order of magnitude worse.

Dataset	Published	Sample	The number that matters
CircleCI, State of Software Delivery	18 Feb 2026	28.7M workflows	Feature branch throughput up 15%, main down 7%
LinearB, Engineering Benchmarks	2026	8.1M+ PRs	AI PRs wait 4.6x longer for pickup, review 2x faster
Faros AI, 2026 engineering report	12 Apr 2026	22,000 developers	Time in review up 441.5%, unreviewed merges up 31.3%

The CircleCI split is the shape of the problem. Across 28.7 million workflows from September 2025, the median team ran 15% more feature branch work and 7% less on main. More gets built. Less arrives.

Faros compared each organization against itself, lowest AI adoption period against highest. Epics completed per developer rose 66%, median time in code review rose 441.5%, and bugs per developer rose 54% against the 9% its 2025 edition reported. Same companies before and after, so weak teams do not explain it.

The most quoted number in this argument is the wrong one

Half the pages on this topic tell you developers feel 20% faster and are actually 19% slower. The result is real. It is not what most people cite it for.

It comes from METR, 10 July 2025: 16 experienced open source developers, 246 tasks, in repos they had known for years. Sixteen people, and the number now gets quoted beside LinearB's 8.1 million pull requests as though the two were the same kind of evidence.

It is also out of date. METR's update of 24 February 2026 ran 57 developers at $50 an hour instead of $150. The returning group now shows an 18% speedup, confidence interval from 38% faster to 9% slower, and METR calls the signal unreliable: developers unwilling to work without AI declined to take part, and 30% to 50% of participants skipped tasks they did not want to do unassisted.

Quote the 19% today without that update and you are doing the thing this post exists to complain about. Whether AI makes one developer faster is unsettled. Whether the queue in front of review got longer is not.

It is a queue, and queues are not mysterious

flowchart LR
  A["Arrivals from humans and agents"] --> B["Queue of open PRs"]
  B --> C["Review, the service stage"]
  C --> D["Merge to main"]
  D --> E["Deploy and enable"]

Work arrives, waits, gets served, leaves. When arrivals rise and the service rate does not, the line grows and everything in it waits longer. Agner Erlang worked this out for telephone exchanges in 1909, and the math does not care that a model writes the arrivals now.

The LinearB benchmarks, drawn from 8.1 million pull requests across 4,800 organizations, tell you which term moved. AI-assisted pull requests wait about 4.6 times longer before anyone picks them up, agentic ones 5.3 times longer, and once a human starts reading they are reviewed about twice as fast.

Service time went down. Wait time went up by a factor of five. The delay is not in the reviewing, it is in front of the reviewing.

The other term people skip is batch size. Faros measured average PR size up 154% in 2025 and up 51.3% in the 2026 dataset. A bigger unit is slower to serve and harder to start, which is why nobody opens it at four on a Tuesday. LinearB puts acceptance of AI-generated PRs at 32.7% against 84.4% for manual ones, so part of that queue is waiting to be rejected. What to do with an agent PR that is 80 percent right is a separate call, and it happens after the wait, not during it.

What the queue cost two projects that could not absorb it

On 14 March 2026, Jazzband announced it was winding down: 3,135 members, 84 projects, over 150 million downloads a month. Jannis Leidel's announcement names GitHub's "slopocalypse", the flood of AI-generated spam PRs and issues, and cites the figure that one in ten AI-generated pull requests meets project standards.

It names a second cause without flinching: the whole thing ran through one person, and open membership with shared push access cannot absorb that arrival rate on one reviewer.

curl attacked the other end. On 26 January 2026 Daniel Stenberg ended the curl bug bounty, effective 31 January, closing a program that had run since April 2019 and paid over $100,000 across 87 confirmed vulnerabilities. Confirmed submissions had been north of 15% in earlier years and fell below 5% from 2025 on. Paying for reports had turned into paying for triage.

Should you buy a review bot?

The rest of the internet answers yes, right after correctly diagnosing a queue problem. Prices come from each vendor's pricing page, checked July 2026.

Tool	Plan	Price	Included
CodeRabbit	Pro	$24/user/mo annual, $30 monthly	Reviews, pre-merge checks
Greptile	Pro	$30/seat/mo	50 credits/seat, $1 each after
Graphite	Team	$40/user/mo annual	Unlimited AI reviews

A review bot earns its money on mechanical checks nobody should do by hand, and on triage that says which of the 41 to open first. If your seniors are writing lint-adjacent comments, buy one.

What it does not touch is the term that moved. Capacity added to a stage that was not starved does not shorten the wait in front of it, and Faros found unreviewed merges up 31.3% in the same period that review time rose 441.5%. Part of that queue is already being cleared by not reviewing it. I sell a tracker, so I will keep the claim narrow: the delay that got measured is queue wait, not service time.

One structural note: Greptile is the only one whose bill has a per-review component, so it scales with the arrival rate you are trying to bring down.

Measure before you cap, because Fenton might be right about you

Steve Fenton published the opposite of my headline in The New Stack on 16 July 2026: coding was never the bottleneck, review is not the bottleneck now, and the constraint sits downstream in deployment batching. His test is good. For the service you work on, how many changes have passed review but are not yet deployed and enabled for users?

DEPLOYED=$(curl -s https://your-app.example.com/version | jq -r .sha)
git fetch origin main
git rev-list --count "$DEPLOYED"..origin/main

If that count is large, close this tab and go fix deployment.

Three numbers are worth having first. Time in review as a distribution, not a mean: a median of four hours with a 95th percentile of nine days is a different disease from a flat two days. Arrival rate split by author type, weekly. And the ratio of reviewed to merged, because climbing unreviewed merges mean the queue is being relieved the worst way available.

gh pr list --state open --json author --jq 'group_by(.author.login)|map({(.[0].author.login): length})|add'

Our project reports carry cycle time and throughput; workspace insights carries median lead time across projects. Cycle time vs lead time covers which is which and project reports and insights walks the pages. Any tool will do. The number has to live where everyone sees it.

The fixes, cheapest first

First, make the queue visible. A review stage should be a named column with a count on it, not a browser tab one person keeps open. In our tracker you name the columns, each mapped to one of seven fixed status categories so reports still know what "open" means. Turning the WIP view on counts cards per column and recolours the header past a built-in target: three for review, four for in progress.

I have to be exact, because most writing about this is not. That counter is a signal and it refuses nothing. There is a per-status WIP limit field in project settings, readable and writable over the API, and nothing acts on it: not the board, not any write path. If a post tells you a capped column bounces the card back, that is not what happens here.

Second, make the sequence enforceable. Each status carries a list of the statuses it may move to, and every write path checks it: board drag, bulk edit, the REST API, the transition endpoint, automation rules. A status with no rules stays unrestricted, so the gate exists only once somebody writes the rules down.

stateDiagram-v2
    state "In progress" as Prog
    state "In review" as Rev
    [*] --> Backlog
    Backlog --> Prog
    Prog --> Rev
    Rev --> Done
    Rev --> Prog

Nothing reaches "Done" without passing through review: a person dragging a card, a bulk edit across 40 tickets, an agent hitting the API at 3am.

curl -X POST https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/transition \
  -H "Authorization: Bearer tfk_live_..." -d '{"status": "backlog"}'

requests.post("https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/transition",
    headers={"Authorization": "Bearer tfk_live_..."}, json={"status": "backlog"})

{ "error": { "code": "validation",
  "message": "Workflow blocks this transition: \"In Review\" cannot move to \"Backlog\".",
  "details": { "code": "workflow_transition_blocked", "from": "In Review", "to": "Backlog" } } }

HTTP 400, whichever door the write came through. Custom workflow statuses covers editing the graph and how to use a kanban board covers the WIP view.

Third, and this is the one with evidence behind it, reduce the arrival rate. curl did not hire reviewers. It removed the reward, and on 25 February Stenberg wrote that "the inflow tsunami has dried out substantially"; intake moved back to HackerOne on 1 March, triage only, no money.

I would be selling you something if I stopped there. On 15 June the project announced it would not accept or handle any vulnerability report during July, citing "a huge pressure for the last four months or so". Cutting arrivals bought months, not a cure, and the only lever left was closing intake.

You will not delete your PR queue that way, but the lever is the same shape: make each unit smaller. Split the epic before the agent starts, rather than reading 900 lines afterwards. Write the ticket so a good result is 150 lines and you have done more for your queue than any bot will. Human-in-the-loop approval is the other half: a gate in front of a write beats a queue behind it.

What none of this fixes

We do not review code: no diff view, no inline comments on a patch, no suggested fix. If you want a machine reading your diff, buy one of the three above.

Our GitHub integration consumes push and release webhooks only. It links commits to issues from #KEY-NUM and ships a release when a matching tag lands. It never sees pull_request events, so it does not know a PR's review state: a column called "In review" is your team's word for it, not GitHub's. GitHub is the only provider, so GitLab and Bitbucket teams get nothing here.

A board cannot make a reviewer read carefully. It can make skipping the stage impossible and the queue impossible to ignore. Everything past that is one person, one hour, and their attention. More of that attention now comes from people who used to spend it writing code, which is part of what your junior engineer does now.

One thing to do this week

Turn the counter on, or write the number on a whiteboard if your tool has none. Then do nothing for five days except look at it each morning: how many sit in review, how many merged, how many arrived.

Most teams find one of three things. The queue is flat, in which case Fenton is right about you. It grows from human PRs, a staffing problem. Or from agent PRs, a batch size problem. Five mornings of counting costs less than any of the fixes.

If you would rather argue frameworks first, scrum vs kanban is the honest version, and neither causes this. If you want the columns and transition rules without the argument, Taskfolk is free for five projects and a counted review column takes ten minutes.