Ten times the pull requests, one reviewer: the arithmetic of the agent era

The bottleneck moved to review, and the arithmetic is not subtle. Microsoft studied its early-2026 rollout of Claude Code and GitHub Copilot CLI and found adopters merged roughly 24% more pull requests. Faros AI reports feature-branch throughput up 59% year on year under high AI adoption. Neither of those numbers came with a matching increase in reviewers, because there is no version of a coding agent that also grows your senior engineers. Production went up, review capacity stayed where it was, and everything downstream of that is a queue problem with four possible responses, three of which teams have already tried.

What went up

Take the two published figures at their own terms. Microsoft's 24% is a merged-pull-request count among adopters of two specific tools inside one very large company. Faros AI's 59% is feature-branch throughput across their customer base. Different populations, different metrics, same direction.

Change volume is only half of it. LinearB's 2026 Software Engineering Benchmarks, built from 8.1 million pull requests across more than 4,800 organisations, put AI-assisted pull requests at 408 lines at the 75th percentile against 157 for unassisted ones. So it is more changes, each about two and a half times bigger at the tail. If you want a rough number for the review load, multiply.

What did not go up

Review capacity is the only input in the system that did not get an agent. A team that had four people qualified to approve an architectural change last year has four this year, working the same hours, with the same working memory.

You can see the saturation in the data. Faros AI reports pull requests that skip review entirely rising 31.3% under high AI adoption. The 2026 paper "These Aren't the Reviews You're Looking For" examined 33,596 agent-authored pull requests and found 61.38% received no recorded human review at all, with 71.58% of the review comments that did exist written by agents rather than people. A queue that gets long enough stops behaving like a queue and starts behaving like a filter that passes everything. I walk through that paper in six in ten agent pull requests are never reviewed by a human.

The four levers

Throughput through review is roughly the number of reviewers, times the hours each spends reviewing, divided by the cost of one review. Three terms there, plus the demand you point them at: four places to push.

Put rough numbers on it. Four reviewers, ninety minutes a day each, forty minutes to understand and sign off one change: that clears about nine changes a day. Add a quarter more changes and you need eleven. Let each change get bigger too, so forty minutes becomes fifty-five, and the same four people now clear six a day against a demand of eleven. Those figures are illustrative rather than measured, and the shape is the point: a modest rise in volume and a modest rise in size compound into a queue that grows a little every day it stays open.

Lever one: more reviewers

This is the first thing every team tries and it disappoints for a specific reason. Reviewers are not interchangeable. The question an agent pull request raises is usually architectural, which means it routes to whoever holds the system in their head, and that is a short list that does not grow by hiring. Faros AI's framing of this as a senior engineer review burden is the right one: the load concentrates rather than spreading.

There is also a second-order cost. Every hour a senior engineer spends in review is an hour not spent on the design work that keeps the architecture coherent while agents move code around inside it.

Lever two: more hours in review

Nobody says this out loud, and it is what actually happens. Review spills into the evening, into the gaps between meetings, into the twenty minutes before standup. It works for a quarter or two. The failure mode is rarely burnout. Reviewers get faster in the wrong way, skimming for style issues because those are visible in a diff, and stopping short of the question they cannot answer in ten minutes.

Lever three: fewer pull requests

Cap the agents. Require changes under 200 lines. Insist that every pull request be split into reviewable units before it is opened.

This one honestly works, and I have watched every version of it slip. Splitting a change after an agent has written it costs a person an hour to save reviewers ten minutes each, so it gets skipped on a busy week and then permanently. A line-count cap is also a poor proxy: a 600-line change that adds one endpoint reads in five minutes, while a 200-line change that alters a shared type, a migration and two call sites is the expensive one. More on why in cognitive load in code review.

The honest version of this lever is a cultural one, and it works in teams that already had the discipline before the agents arrived.

Lever four: cost per review

Which leaves the denominator, and it is the only term with real slack in it, because so much of a review is currently spent on work that tells you nothing about the code.

Watch what the first ten minutes of a review actually contains. Reading a file list. Guessing which file is the entry point. Opening three files that turn out to be generated. Working out that the change has two centres rather than one. Building, from scratch, a picture of the change that the author, human or otherwise, already had. None of that is judgement. All of it is assembly, and it is repeated by every reviewer on every pull request.

The evidence that this is where the time goes is in the pickup numbers. LinearB found AI pull requests wait 4.6 times longer to be picked up, over 16 hours against roughly 200 minutes, and then run faster than human ones once review starts, about 194 minutes against 252. Reviewers are pricing the assembly cost before they commit to it. I go through that in why AI-generated pull requests wait 4.6 times longer for review.

Cut the assembly and the same four reviewers clear a much longer queue without working an extra hour. That is the whole argument for reviewing a 400-line pull request in ten minutes, and the method is in the complete guide to reviewing AI-generated pull requests.

Where the bots fit

Defect-finding is already being automated at scale. GitHub reports Copilot code review has processed over 60 million reviews, a tenfold increase in under a year, and that more than one in five code reviews on GitHub now involve an agent. That is a real saving on one part of the job.

It does not touch the part that decides your throughput. A bot that finds a null dereference has answered a question you could have automated in 2015. The question that costs you sixteen hours of pickup time is what this change did to the system, and the reviewer is still assembling that answer by hand, one file at a time.

That is the gap PR Lens was built for. It draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request, redrawn on every push, with green for new, amber for changed and red for gone. The reviewer opens the pull request already holding the shape of it. Everything they do after that is judgement, which is the only part of review worth paying a senior engineer for.