When review can't keep up with agent pull requests

When agent pull requests outrun review, the queue is the visible problem and the invisible one is worse: nobody can say why the system is shaped the way it is any more. Faster review tooling clears the queue and leaves that gap. Backthread sits above the diff, alongside review, capturing the reasoning behind each merged change from the agent session and showing per area how much of the codebase the team still understands.

Why is AI code review the bottleneck now?

Because the cost of producing a change fell to near zero and the cost of reading one did not. LinearB's 2026 benchmarks, drawn from more than 8.1 million pull requests across 4,800 engineering teams in 42 countries, put a number on the mismatch: PRs written by agentic tools wait 5.3 times longer for a reviewer to pick them up than unassisted ones, and only 32.7 percent of AI-generated PRs are accepted, against 84.4 percent for manual ones. Codacy, citing CircleCI's 2026 data, adds that feature-branch throughput is up 59 percent year over year while main-branch throughput for the median team fell.

Read those together and the picture is a funnel with the wide end getting wider. More opens, longer waits, more rejections, and a main branch that is not moving faster despite all of it. The reviewers are the same senior engineers who were supposed to be freed up by the agents. They are now the constraint.

What "rubber-stamping" actually is

It is not laziness. When 30 agent PRs land in a week and each one is 150 to 400 lines of plausible, tested, well-described code, a reviewer has a choice between reading two of them properly and skimming all thirty. Most teams pick skimming, quietly, and call it approval. Intercom's engineers described the same pressure before they automated approval: humans "simply don't have the time or mental capacity to properly review the volume of AI-generated code we're now producing."

The stamp is honest about one thing. It records that a person was willing to be accountable for the merge. It records nothing about whether that person, or anyone else, understood the change. That gap is the subject of a merged pull request is not evidence of understanding, and it is the part every ranking answer skips.

What do the ranking answers recommend?

Search the query and the top results agree with each other almost exactly. Here is what they say, with dates, so you can check.

Every row is the same shape: review is slow, so make review faster, or make an agent do it. And every row is right, as far as it goes. Baseline checks should be automated. Low-risk changes should not wait behind high-risk ones. An agent reviewer that catches a null dereference is worth having. Intercom reports downtime from breaking changes down 35 percent while deployments doubled, which is a real result.

What none of them address

Review, human or agent, fast or slow, operates on the diff. It answers: is this change correct, does it match the style, does it handle the edge case. It does not answer, and was never designed to answer: which approach was rejected, what this change assumes about the rest of the system, what it defers, and who on the team now holds that knowledge.

Speeding review up does not create that layer. Handing review to an agent removes the last human who might have absorbed it in passing. When a person read 30 diffs a week, some of the why leaked into their head as a side effect. When an agent approves 19 percent of PRs and the human skims the rest, that side effect is gone too, and nothing replaces it.

So the fixes on offer make the queue shorter and the team's model of its own system thinner, at the same time. Nobody notices the second effect because nothing measures it.

What survives a merge, and what doesn't?

Three things leave a PR when it merges: the diff, which git keeps forever; the review thread, which GitHub keeps and nobody rereads; and the reasoning, which lived in the agent session and the author's head and is gone the moment the branch is deleted.

We measured the third one on our own repository. Of 4,302 decisions extracted from agent sessions, 1,613 carried any recorded alternative or trade-off, so for 62 percent of them the reasoning was thin to begin with, and for the rest it existed but had nowhere to go. The full count is in most agent-written code has no why. Either way, review is the wrong place to look for it. A reviewer reading the diff cannot recover a rationale that was in the session, and cannot invent one that never formed.

What the leader is left with

A CTO running a 40-engineer team through this sees green CI, fast deploys and a shrinking queue, and has no instrument that says the number of people who could explain the payment retry logic went from three to one. The team is not failing. It is quietly narrowing, and the tooling reports health because it counts merges.

How do you keep understanding without slowing review down?

Not by adding a step to review. Engineers will not do a side-of-desk exercise, and a leader who asks reviewers to also write architecture notes on every agent PR has just made the bottleneck worse. The pattern that works has three parts, all outside the review loop.

1. Capture the reasoning where it already exists. The agent session contains the alternatives considered and the trade-offs accepted, in the agent's own words, at the moment they were live. Capture from the session and from the PR discussion, automatically, and hold each decision until its work merges so the record is of what shipped rather than what was tried. Never fabricate; a decision with no recorded reasoning is shown as a blank.
2. Show it per area, not per PR. A list of 800 merged decisions is a second queue. A map of the system with the decisions attached to the parts they touched, and a knowledge-coverage figure per area, is something a leader can read in five minutes. The first figure is inferred from who authored and reviewed what, capped at 50 percent and labelled an estimate, because a stamped approval is not understanding. Above that, coverage is earned by people explaining decisions. Areas with nothing recorded say "nothing on record here." This is the view described in who knows what in your codebase.
3. Teach it back in the flow. The reasoning goes back to engineers inside the coding agent, while the agent is thinking or on demand for the code being touched. No session, no quiz. The engineer who is about to modify the retry logic gets the two decisions that shaped it, from the person or agent who made them, before the edit.

That is what Backthread does, and the pricing is on the homepage: $25 per seat per month after a fourteen-day trial, one repository included. None of it touches the review queue. Keep whatever review tooling you have or are about to buy; Codacy's gates, Moderne's routing and Copilot's approvals all still make sense. This runs alongside them and holds the one thing they discard.

A test you can run this week

Pick the five agent PRs merged most recently into your riskiest area. Ask the approver, in a hallway, what alternative each one rejected. If the answer is "I'd have to look," you have measured the gap. If the answer is "I don't think there was one," you have measured the other gap, and it is bigger.

Connect one repo and the per-area coverage view is there the same day, with the git-inferred part capped and labelled, and the review queue exactly as it was; the trial is fourteen days with everything on.