Tell an engineering leader their team will generate three times the code and some of them start planning for a smaller team. Six months later the code volume is up, delivery is barely faster, and the most senior engineers spend their days reading diffs. Nothing malfunctioned. The constraint moved, and the org chart did not move with it.
We ship client work through agentic delivery pipelines with a deliberately small senior team, so the review-load problem is not a trend we read about. It is the operating condition we design around. And the conclusion from running it on real estates: generation was never the constraint, and staffing as if it was is currently the most expensive mistake in AI adoption.
Generation was never the constraint
Before AI, typing speed was not why software shipped slowly. Work queued behind understanding the problem, agreeing on the change, verifying it did not break the ten things nearby, and integrating it with everyone else's work. Generation is the one stage AI accelerates by an order of magnitude out of the box. The surrounding stages inherit the volume, unimproved.
Queueing behavior does the rest. Accelerate one stage of a pipeline and work piles up in front of the slowest stage downstream of it. On an AI-accelerated team, that stage is review and verification, which run on the scarcest resource in the building: senior attention. The team did not get slower. It got faster at the wrong stage, and the queue moved to where nobody was watching headcount.
The vendor number that concedes the point
You do not have to take a consultancy's word for where the queue forms. This month GitHub added review-cycle metrics to the Copilot usage API: median time from pull request creation to first review, and median review submissions before merge, broken out by AI adoption cohort. When the vendor selling the generation tool instruments review latency as the number worth watching, that is the market conceding where the bottleneck lives. Generated volume is a solved problem. Reviewed, merged, verified volume is the product.
The metric design carries a quieter lesson too: both numbers are scoped to merged pull requests only. Work that is generated but never lands does not count. That is the right accounting, and most internal AI dashboards still get it wrong.
Re-staff for verification, not against generation
If review capacity is the binding constraint, the team design question inverts. It stops being "how many generators can we replace" and becomes "how do we expand and protect acceptance capacity." Four moves consistently pay.
Make review a first-class role, not an interrupt. On most teams, review is what senior people do between meetings, which makes the bottleneck of the whole delivery system a background task. Teams that assign review the way they assign features, with owners, capacity, and priority, stop being surprised by where work stalls.
Design verification before generation. Tests, invariants, and acceptance criteria written before the agent generates give reviewers something to check against, rather than reverse-engineering intent from a thousand-line diff. This is the single highest-return practice we know in agentic delivery, and it is the spine of how we run agentic coding in production.
Cap batch size ruthlessly. Agents will happily produce enormous changes, and review cost grows worse than linearly with diff size. A reviewer can hold a two-hundred-line change in their head; at two thousand lines they are skimming and approving on vibes. Small verified slices beat heroic branches, and with an agent doing the generation, slicing small costs almost nothing.
Push verification down to machines. Every property enforced by types, contracts, tests, or CI is senior attention returned to the judgments machines cannot make: is this the right change, does it belong in this system, what does it break conceptually. The point of automating verification is not replacing the reviewer. It is spending the reviewer on review instead of on clerical checking.
The team shape that follows
What falls out of this is not a smaller team. It is a differently shaped one: generation capacity that scales elastically with tooling, verification capacity that is deliberately staffed and protected, and seniority concentrated at the acceptance boundary where judgment actually gates delivery. The teams that thrive with AI look less like a room of typists with a fast autocomplete and more like a small editorial desk with an enormous newsroom feeding it.
That shape has a budgeting consequence worth saying plainly. If your AI adoption plan reduces review capacity while multiplying generated volume, the plan is arithmetic that does not close. The savings assumed from generation will be consumed, with interest, by the queue that forms in front of your remaining reviewers.
None of this requires a reorganization to start. Pick one delivery stream, instrument its queue, and move one senior engineer's week from generating to accepting. Compare the stream's cycle time a month later. In our experience the result settles the staffing argument faster than any deck could, and it occasionally settles it in the other direction, which is worth knowing too: a team whose review discipline was already strong may really be constrained somewhere else, and the same instrumentation will say where.
If delivery slowed down after the AI speedup arrived, look at the review queue before you look at the model choice. Instrument time-to-first-review and cycles-to-merge, find where the work actually waits, and staff that. If you want help re-sequencing a delivery pipeline around verification capacity, that is work we do. AI that ships, not AI that demos.