Six in ten agent pull requests are never reviewed by a human

Of 33,596 agent-authored pull requests examined in the 2026 study "These Aren't the Reviews You're Looking For", 61.38% received no recorded review at all. Of the review comments that did appear on agent pull requests, 71.58% were written by agents rather than people. That is the state of play: most agent code merges with nobody having formed an opinion about it, and most of the feedback that does exist comes from another model. The interesting question is why, because the teams doing this are not careless. They are rationing a scarce resource, and the rationing is working exactly as you would expect.

What the study counted

The paper compares human review behaviour on agent-authored pull requests against human-authored ones across a large sample of public repositories. Three findings carry the argument.

The first is coverage: 61.38% of the agent-authored pull requests had no recorded review. That phrasing matters and the authors are careful with it. A review recorded on the platform is what can be measured, so a maintainer who read the change over someone's shoulder, or discussed it in Slack, leaves no trace in the data. Some fraction of the 61.38% is that, though a gap this size does not close that way.

The second is authorship of the feedback: 71.58% of review comments on agent pull requests came from agents. Review bots have become the default first responder, which is a real service and a different service from someone deciding whether the change belongs.

The third is the shape of the human comments that remain. Agent-steering commands, instructions addressed to the bot to go and fix something, appear in 25.92% of reviews of agent pull requests, against 1.63% for human-authored ones. The reviewer's role shifts from judging a change to operating the thing that produced it.

This is a rationing problem

Nobody writes a policy that says agent pull requests skip review. It emerges. Every reviewer, looking at a queue on a Tuesday afternoon, takes the changes they can price and defers the ones they cannot, and the agent pull requests are systematically the ones they cannot price.

LinearB's 2026 Software Engineering Benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, measured that deferral directly: AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up, over 16 hours against roughly 200 minutes. Agentic ones waited 5.3 times longer at the 75th percentile. Faros AI, looking at a different customer base, reports pull requests that skip review entirely rising 31.3% under high AI adoption.

An unreviewed merge is still a decision, made by everybody deferring it at the same time. Nobody chose it, everybody contributed to it, and it shows up in the metrics as a healthy cycle time.

The volume side of the arithmetic is in ten times the pull requests, one reviewer, and the pickup numbers are unpacked in why AI-generated pull requests wait 4.6 times longer for review.

How much of this applies inside a company?

Less directly, and the direction holds. The study's sample is public repositories, where a maintainer can merge their own agent's work without a second approver and frequently does. Most companies have branch protection turned on, so a required approval means the 61.38% cannot happen in that literal form.

What happens instead is the approval without the reading. A required reviewer under a full queue clicks approve on the pull request they cannot price, having checked that CI is green and the diff looks like the kind of thing the team writes. That review is recorded. Whether it happened is a different question, and it is the one the platform data cannot answer for either sample. The organisation-level numbers from LinearB and Faros AI, which do come from companies, point the same way: longer pickup, more skipped review, more of it as adoption rises.

What CI does and does not cover

The usual defence is that the tests pass. They generally do, and it is worth being precise about what that establishes.

CI proves that the tests present in the repository still pass against the change. When the agent that wrote the change also wrote its tests, that statement gets thinner. GitHub calls the two failure modes here CI gaming, where the change edits the thing doing the checking, and hallucinated correctness, where the tests assert the implementation rather than the requirement. Both are invisible in a green check mark, and both are cheap to spot if someone looks at what moved in the workflow files. I mapped those and the other three red flags in five red flags in agent pull requests.

Then there is the class of problem tests were never going to catch. The 2026 paper "Is Vibe Coding Safe?" evaluated SWE-Agent running Claude 4 Sonnet and found 61% of its solutions functionally correct and 10.5% secure. Working code and safe code are not the same population, and the gap between those two numbers is what an unreviewed merge is betting on.

What you actually lose

The obvious loss is defect detection, and it is the smaller one. Bots are good at defects; GitHub reports Copilot code review has processed over 60 million reviews, a tenfold increase in under a year, and more than one in five code reviews on GitHub now involve an agent. If finding bugs were the whole job, the 61.38% would matter much less than it does.

The loss that compounds is knowledge. Review is how a team stays current with its own system. Skip it for a quarter and you have a codebase where the only entity that has read the recent architecture is a model with no memory between sessions, and a team whose picture of the system is however old their last real review was. When something breaks at 2am, the person paged has to reconstruct from the code what nobody ever internalised.

That is the part of review that cannot be handed to a bot, and it is why we started building diagrams instead of another linter.

What to do about it

Set a floor rather than a rule nobody can meet. Requiring a full line-by-line human review of every agent pull request will fail within a month, because the numbers above say it must. Requiring that one person can say what the change did to the system, in a sentence, before it merges is a floor that survives contact with a busy week.

Getting to that sentence is the whole cost, and it is mostly assembly work: file list, entry point, what is new, what was deleted, how it connects. The complete guide to reviewing AI-generated pull requests is the method for doing it by hand in about ten minutes.

PR Lens does the assembly for you. It draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request itself, updated in place on every push. Green is new, amber is changed, red is gone, and the parts of the system the change did not touch stay on the page so the change has somewhere to sit. It finds no bugs, deliberately, because that end is well served. What it hands back is the thing the 61.38% is costing you: a current picture of your own system, drawn every time an agent moves something in it.