Tell an engineering leader that AI will triple the code their team generates, and some of them start planning a smaller team. Six months later, code volume is up, delivery is barely faster, and the most senior engineers spend their days reading diffs. Nothing broke. The constraint moved to code review, and the org chart did not move with it.
AI coding tools speed up generation, so the queue forms at review and verification, and a team that cuts review capacity to fund the speedup ends up slower. Review capacity means the senior attention available to read, test, and accept changes before they merge. We run client delivery through agentic pipelines with a deliberately small senior team, so review load is not a trend we read about. It is the operating condition we design around.
Why don't AI coding tools make delivery faster?
AI coding tools accelerate the one stage that was never the main constraint. Before AI, software did not ship slowly because of typing speed. Work waited on understanding the problem, agreeing on the change, checking that it did not break nearby code, and integrating it with everyone else's work. Generation got a large speedup out of the box. The stages around it inherited the extra volume, unimproved.
Queueing does the rest. Speed up one stage of a pipeline and work piles up in front of the slowest stage after it. On an AI-accelerated team, that stage is review, and review runs 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 formed where nobody was tracking capacity.
GitHub now measures review time for AI-assisted work
The vendor selling the generation tool now treats review latency as the number to watch. On July 7, 2026, GitHub added review-cycle metrics to the Copilot usage API: the median time from pull request creation to first review, and the median number of review submissions before merge, broken out by AI adoption phase. Generated volume is a solved problem. Reviewed, merged, verified volume is the product.
Both numbers also count merged pull requests only, so a pull request that is reviewed but never merges does not count. That is the right accounting, and most internal AI dashboards still get it wrong.
How to staff for review capacity
Staff review as deliberately as you staff feature work. Once review is the binding constraint, the team design question stops being "how much generation can the tools absorb" and becomes "how do we expand and protect acceptance capacity." Four moves pay off consistently in our delivery work.
Make review a role, not an interrupt. On most teams, review is what senior people do between meetings. That turns the constraint of the whole delivery system into a background task. Assign review the way you assign features: an owner, capacity, and a priority.
Design verification before generation. Write the tests, invariants, and acceptance criteria before the agent generates. Reviewers then check against something instead of reverse-engineering intent from a thousand-line diff. It is the highest-return practice we know in agentic delivery, and it anchors how we run AI coding agents in production.
Cap batch size. Agents will produce enormous changes, and review cost grows faster than diff size. A reviewer can hold a 200-line change in their head. At 2,000 lines, they skim and approve on trust. With an agent doing the generation, slicing small costs almost nothing.
Push verification down to machines. Every property that types, contracts, tests, or CI enforce returns senior attention to the questions machines cannot answer. Is this the right change? Does it belong in this system? What does it break conceptually? Automated checks do not replace the reviewer. They stop spending the reviewer on clerical work.
What an AI-era delivery team looks like
The team that follows from this is not smaller. It is shaped differently: generation capacity that scales with tooling, review capacity that is deliberately staffed and protected, and seniority concentrated at the point where changes are accepted. It looks less like a room of typists with fast autocomplete and more like a small editorial desk with a large newsroom feeding it.
Google's DORA 2025 State of AI-assisted Software Development report calls AI "an amplifier, magnifying an organization's existing strengths and weaknesses." Thin review capacity is one of the weaknesses it magnifies.
The budget consequence is plain arithmetic. If an AI adoption plan reduces review capacity while multiplying generated volume, the plan does not close. The queue in front of the remaining reviewers consumes the assumed savings, with interest.
You do not need a reorganization to test this. Pick one delivery stream, instrument time to first review and review cycles to merge, and move one senior engineer's week from generating to accepting. Compare cycle time a month later. In our experience, the result settles the staffing argument faster than a slide deck. Sometimes it settles it the other way: a team with strong review discipline may be constrained somewhere else, and the same instrumentation shows where.
If delivery slowed after the AI speedup arrived, check the review queue before you change models. Our AI implementation framework is where we re-sequence a delivery pipeline around review capacity. AI that ships, not AI that demos.