When the Agent Can Drive the Machine, Review Becomes the Bottleneck
Doubling the fleet of agents takes an afternoon; doubling the number of changes a week a team can genuinely accept takes a refactor

Ihor K
CEO
Doubling the fleet of agents takes an afternoon; doubling the number of changes a week a team can genuinely accept takes a refactor

Ihor K
CEO
A coding agent with a shell, a browser and screenshot-and-click control of a desktop is ordinary tooling now rather than a demo. What a team notices first after switching one on is rarely the code. It is the queue.
Take a team that merges twelve pull requests in a normal week. Nothing about the team changes — same people, same service, same bar. What changes is upstream: the agents writing against that codebase can operate the machine. They run the suite, read the failure, open the app in a browser, reproduce the bug, and come back with a diff they have already watched work. Sixty of those land on Monday. The team still merges twelve. The other forty-eight are forty-eight decisions the week did not contain enough hours to make.
Review does not parallelise the way authorship does. Writing a change requires understanding the change. Accepting it requires holding the system the change lands in — what else reads that table, which caller assumed the old ordering, what the retry does now. When Bacchelli and Bird sat with reviewers at Microsoft and asked what the work actually consists of, the answer was change and context understanding, and that turned out to be the part the tooling supports worst. The load sits in one head and does not split. A second reviewer does not halve it; they build it again from the beginning. A team's weekly merge count is the number of those loads it can afford, and that number changes slowly.
Price it before scaling the fleet. All sixty diffs get read whether or not they merge, and declining one competently costs about what accepting it costs, because either verdict requires understanding it. At twenty minutes a diff — generous for a change you genuinely follow — sixty diffs is twenty hours of senior review a week: an hour and forty minutes of a team's most expensive attention for each of the twelve changes that ship, and half an engineer, paid year-round, to merge precisely what was being merged before. That number exists whether or not anyone writes it down. The only choice is whether it was set deliberately or discovered in a standup.
Twenty minutes is a variable, and that is where the leverage sits. A change that brings the failing test that motivated it, the same test green beside it, and a direct statement of what it does not cover is a decision about one file: the reviewer audits an argument already on the page. Four hundred lines and a fluent description of what happens inside them cannot be read at any speed, because the argument has to be rebuilt from scratch before the reviewer has standing to disagree with it. Google tells its own engineers that a reviewer may reject a change for its size alone; what that rule protects is a budget of human attention. An agent emits either shape with equal ease, and which one you get is set by what you require of it.
The same pressure passes through the diff and reaches the codebase. Module boundaries, typed contracts and small blast radii used to be matters of taste, defensible on maintenance grounds and quietly deferrable for a quarter or two. They now decide what accepting a change means — reading one file, or reconstructing half the system — which is to say they set the twenty minutes. Bring it down to eight and the same twenty hours covers a hundred and fifty diffs instead of sixty: a fleet two and a half times the size, staffed by the people already there. Hiring cannot match that, because every reviewer added begins by building the context from nothing, and the context was the thing in short supply.
The queue is already producing the measurement that says which seam to open first. Sort a week of diffs by how long the decision on each one took, not by how long each one sat waiting. The expensive ones will not be spread evenly across the service; they cluster on a few boundaries, because what makes a change costly to read is almost never local to the change. That ranking is architectural evidence obtained as a by-product of work already being paid for, and it orders the candidate refactors by the review hours each one gives back. Open the top one, and the same reviewers take on more agents next quarter than any hiring plan would have handed them.