The Throughput Wall: Redesigning Sprint Velocity When Agents Generate 10x Your Review Capacity

Sprint velocity becomes meaningless when agents generate code faster than humans can review it. Story points go up; cycle time stays flat. The sprint board looks productive right up until the review queue contains thirty-seven unmerged pull requests and it's day eight of ten.

This is what happens when teams add coding agents without redesigning the operating model around them. The agents execute overnight — reliably, quickly, without complaint. By morning, GitHub shows dozens of open pull requests. The developers arrive, feel good about the output, and then realize nobody planned for who reviews all of this. The sprint was designed the old way: estimate what the team can build, assign the work, measure velocity in points completed. That model assumed code generation was the rate-limiting step. Agents removed that assumption in one sprint cycle.

The throughput wall is the point where agent code generation capacity outpaces human review capacity. It is not a tooling problem — adding better agents makes it worse. It is a sprint design problem: the operating model was built for a world where writing code was slow and expensive. Redesigning for a world where writing code is nearly free requires inverting the planning logic entirely. You plan sprints backwards now, from review throughput, not forward from agent capability.

Eliyahu Goldratt's Theory of Constraints^[1] offers the clearest framework for what happens here. Every system with interdependent stages is bounded by its slowest stage — the constraint. Improve any other stage and you do not improve the system: you build up more work-in-progress in front of the actual bottleneck.

For most software delivery pipelines, code generation was never the constraint. Code review, QA, and deployment approval were slower. AI agents accelerated code generation — a non-constraint stage — without touching any downstream stage. The result is more code arriving at the review gate faster than reviewers can clear it. The queue grows. Review quality degrades as reviewers rush through larger piles of increasingly unfamiliar code. And the problem compounds: agents building on top of unreviewed code produce PRs with assumptions baked in that nobody has validated.^[6]

This is why practitioners describe encountering the wall as a sudden shift rather than a gradual slowdown.^[4] The agents are efficient enough that a small team can hit review capacity within the first sprint or two of adoption. The code keeps generating. The reviews don't keep up.

The Agile Leadership Day India framework for AI-augmented Scrum teams^[5] puts this plainly: "A 24/7 AI agent will quickly outpace human reviewers. If you do not plan human capacity for code review, your agents will stack up a massive backlog of unmerged pull requests, stalling your entire continuous integration pipeline."

The instinct when facing this is to add more agents — the reasoning being that agents are cheap, so scaling them is low-cost. This is the wrong response. More agents at the generation stage mean more PRs at the review stage. The constraint is not generation; it is review. Adding capacity to the wrong stage increases inventory without improving throughput.^[7] The correct response is to constrain agent output to what reviewers can actually clear.

The inversion is this: instead of asking "what can agents generate this sprint?", ask "what can reviewers approve this sprint?" Build the sprint backwards from that number.

This feels counterintuitive because agents have surplus capacity. They could generate far more than the sprint assigns them. That surplus feels like waste. It is not waste — it is correctly identified excess that exceeds the system's throughput capacity. Agents sitting idle while the review queue clears is the right state. Agents running while the review queue grows is the wrong state, regardless of how full the sprint board looks.

The formula has three inputs: the number of available reviewers, the sustainable daily review hours per reviewer, and the average hours required to review one agent PR.

Sprint review throughput = (reviewers × sustainable review hours per day × sprint days) ÷ hours per agent PR review

The "sustainable" qualifier matters. A senior engineer can maintain focused code review for roughly 2–2.5 hours per day before quality degrades meaningfully. Review beyond that threshold still happens, but defect detection drops — reviewers are reading without fully processing. This is not a criticism of the individuals; it is how sustained cognitive load works under context-switching pressure.

Using 2.5 hours as the sustainable budget: a team with three reviewers across a ten-day sprint has 75 review-hours available. If the average agent PR is 400 lines and requires approximately 75 minutes of careful review, that's roughly 60 PRs the team can responsibly approve in that sprint. Assign agents to work that will generate more than 60 PRs and the sprint is over-committed before it starts.

Two variables drive this formula above all others: PR count and PR size. Reducing average PR size from 600 lines to 300 lines roughly doubles review throughput with no additional headcount. This is the highest-leverage control variable in a hybrid team's sprint design.

Story points were designed to capture human cognitive and execution cost. An agent executes a 5-point ticket in minutes. Applying story points to agent work produces inflated velocity numbers and, worse, a planning model that has no concept of the review burden being created.

Hybrid teams need a different sizing unit for agent work: scope (what gets changed) rather than effort (how long it takes). The relevant question for an agent ticket is not "how many hours?" but "how many files, how many systems, and how many review-hours does this generate?"

Standard acceptance criteria were written for human-generated PRs, where the developer carries context about what they changed and why. Agent-generated PRs arrive without that human context — the reviewer is reading code from a process that has no standing relationship with the codebase and no institutional memory.

This means agent ticket acceptance criteria need two additions: context requirements (what the agent must include in the PR description to make the reviewer's job feasible) and scope constraints (guardrails that prevent agents from modifying code outside the ticket's stated boundaries, which is a common pattern that silently expands review surface area).