Tech Evolution #9 — on what the human between the benchmark and the deployment costs, measured in minutes.
"Human in the loop" is usually stated as a principle. In practice it behaves like a queue, and in 2026 that queue has a measurable wait time.
The previous essay in this series argued that agents are benchmarked at 50% reliability and deployed where decisions need something closer to 99%. The person who closes that distance is a reviewer, and reviewers are a finite resource. Four recent datasets look at what happens to that resource as the volume of AI-generated code rises. They measure different things in different populations, and none of them settles the question alone. Read together, they make a narrower point that is hard to wave away: review is a cost, and it is being paid in waiting time, in shallower reading, or in not being paid at all.
The wait
LinearB's 2026 benchmarks draw on more than 8.1 million pull requests from 4,800 teams. In LinearB's own discussion of the data, AI-generated pull requests wait about five times longer for a reviewer to pick them up than unassisted ones: roughly a thousand minutes, more than sixteen hours, against about two hundred. The written benchmark page shows the same gap at the 75th percentile, 17.6 hours for agentic pull requests against 3.4 hours for unassisted work.
Once picked up, AI-assisted pull requests are reviewed faster, in about 194 minutes against 252 for manual ones. LinearB's interpretation is that reviewers tend to scan for high-level issues rather than work through the change in depth. That is a reading of the timing, not a measurement of review depth, and it should be held as one. The merge figures are starker. About 32.7% of AI pull requests merge within thirty days, against roughly 84% of human-written ones. A merge rate is not a quality score on its own, since it also reflects abandoned work and scope, but it does show how much generated code never makes it through the loop.
The skip
Faros AI looked at two years of telemetry from about 22,000 developers in its customer organizations, comparing periods of lower and higher AI adoption. Its findings are relative changes. Median time in review rose 441.5%. Median time to first review rose 156.6%. The number of pull requests merged with no review at all, human or agentic, rose 31.3%, which describes a change in that metric, not a third of all pull requests going unreviewed. The ratio of incidents to pull requests rose 242.7%.
One reading consistent with those numbers is that the loop is not being removed so much as skipped under load. The data is observational and cannot establish that by itself, but it points the same way as the LinearB queue.
The gap tests cannot see
METR asked four maintainers of scikit-learn, Sphinx and pytest to review 296 AI-written patches that had already passed the automated tests of the SWE-bench Verified benchmark. Roughly half would not have been merged. For Claude Sonnet 4.5, the newest model in that study, a time horizon of about fifty minutes by the automated grader fell to about eight minutes by maintainer judgment.
The limits matter. The reviews were hypothetical, each patch had a single attempt with no chance to respond to feedback, there was no full continuous integration, and the tasks came from one benchmark with one agent setup. The result measures how far passing tests sat from mergeable code in that setting. It is not a general rate for agent pull requests in production.
The fourth dataset looks at recorded review activity. An EASE 2026 study of 33,596 agent pull requests in the AIDev dataset, drawn from popular GitHub repositories, found that 61% had no recorded review activity, and that 59% of those that were reviewed were reviewed only by other agents. No recorded review is not proof that no human read the code. The figure also depends heavily on the sample: in repositories that receive both agent and human pull requests, the share of agent pull requests without recorded review was about 29%. Neither number describes GitHub as a whole.
Evidence against my read
There is real evidence pointing the other way. METR now says it believes developers are likely more sped up by AI tools in early 2026 than its early-2025 study estimated. It calls its newer estimate, from a later study, likely a lower bound on the true effect, while cautioning that its data is only very weak evidence for the size of that increase. Faros's data is observational and limited to its own customers, and Faros itself says its data directly contradicts DORA's 2025 report, which concludes from survey data that strong engineering foundations amplify AI's benefits and offer protection against its downsides. The two use different populations and methods, so the contradiction is Faros's claim rather than a settled result. Two of the four sources sell measurement products. And an unrecorded review is not always an absent one.
What the sources do support is narrower than a universal rate. AI-generated pull requests can move effort into review and into handling changes that never merge, and that effort is worth measuring directly.
If you run agents
Treat review minutes per agent-hour as a cost, and budget for them. Keep agent pull requests small, for the same human reason that long-standing review guidance exists; Google's engineering practices describe about a hundred lines as usually reasonable and a thousand as usually too large. Give every agent pull request a named human owner, because ambiguous ownership is an easy reason for a reviewer to walk past it. And track merges with no review as risk, not as velocity.
Speculation, flagged as such: what if teams published review minutes per agent-hour the way they publish uptime? The first to do it would change what buyers ask for.
The loop is only as real as the time someone spends in it. How long an agent's pull request waits, and who is measuring that wait, are operational questions, and they have answers.