The Throughput Wall: Why Adding Coding Agents Slowed Your Sprint Down

Velocity is a lie when agents generate code faster than humans can read it. Story points climb. Cycle time does not. The board looks productive right up until day eight, when the review queue holds thirty-seven open pull requests and nobody is sure which ones are safe to merge.

This is what teams hit in the first or second sprint after onboarding coding agents. The agents run overnight. By morning, GitHub shows dozens of PRs. The developers feel the dopamine, then realize nobody owns review. The sprint was planned the old way — estimate what the team can build, assign the work, count points. That model assumed code generation was the slow stage. Agents removed that assumption in one cycle.

The throughput wall is the point where agent generation capacity outruns human review capacity. It is not a tooling problem. Better agents make it worse. It is a sprint design problem: the operating model was built for a world where writing code was the bottleneck. Writing code is no longer the bottleneck. Review is. And review does not scale by adding agents — it scales by capping what agents are allowed to push at it.

The planning logic inverts. You no longer ask what agents can generate this sprint. You ask what reviewers can clear. Then you build the sprint backwards from that number.

Goldratt's Theory of Constraints^[1] names this exactly. Every system of interdependent stages is bounded by its slowest stage — the constraint. Improve any other stage and you do not improve the system. You build inventory in front of the actual bottleneck.

For most software pipelines, code generation was never the constraint. Review, QA, and deployment approval were slower. Agents accelerated a non-constraint stage and left every downstream stage untouched. The result: more code arriving at the review gate faster than reviewers can clear it. The queue grows. Quality erodes — reviewers rush larger piles of unfamiliar code. Then the failure compounds: agents start building on top of unreviewed code, baking in assumptions nobody validated.^[6]

Practitioners describe hitting the wall as a step change, not a gradual slowdown.^[4] One sprint, the queue is fine. The next, it has calcified. Agents are efficient enough that a small team blows through review capacity inside the first two sprints of adoption.

What broke in our early hybrid designs: we assumed senior engineers would drift toward review as their primary contribution once agents handled implementation. They did not. They kept owning implementation and treated agents as a force multiplier on their own output. Review became a shared burden with no owner — which is the structural definition of nobody's job. The fix was not a tool. It was role redesign: one senior engineer per sprint named as primary reviewer, protected from new implementation assignments for the sprint duration. That single ownership change broke the queue accumulation pattern.

The Agile Leadership Day India framework for AI-augmented Scrum^[5] states the failure mode 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 on first contact is to add more agents. Agents are cheap. Scaling them feels low-risk. It is the wrong move. More agents at generation means more PRs at review. Generation is not the constraint. Adding capacity to a non-constraint stage builds inventory. It does not raise throughput.^[7] The correct move is the opposite: constrain agent output to what reviewers can actually clear, and treat any surplus generation capacity as deliberate slack — not waste.

The inversion is one sentence: stop asking what agents can generate this sprint. Ask what reviewers can approve. Build everything backwards from that number.

This feels wrong because agents have surplus capacity sitting on the table. They could generate three times the work the sprint assigns them. That surplus reads as waste. It is not waste. It is correctly identified excess that exceeds the system's actual throughput. Agents idle while the review queue clears is the right state. Agents running while the review queue grows is the failure state — no matter how green the sprint board looks.

Three inputs: number of available reviewers, sustainable daily review hours per reviewer, 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 word sustainable carries the formula. A senior engineer can hold focused review for roughly 2–2.5 hours per day before quality degrades meaningfully. Past that threshold, review still happens. Defect detection drops. Reviewers are reading without processing. This is not a character flaw. It is how sustained cognitive load behaves under context-switching pressure.

Use 2.5 hours as the sustainable budget. Three reviewers across a ten-day sprint give you 75 review-hours. If the average agent PR is 400 lines and takes roughly 75 minutes of careful review, that is about 60 PRs the team can responsibly approve in the sprint. Assign agents to work that will produce more than 60 PRs and the sprint is over-committed before it starts.

Two variables dominate the formula: PR count and PR size. Cutting average PR size from 600 lines to 300 lines roughly doubles review throughput with zero new headcount. PR size is the highest-leverage control variable in a hybrid team's sprint design. Nothing else comes close.

Story points were built to capture human cognitive and execution cost. An agent finishes a 5-point ticket in minutes. Apply story points to agent work and you get inflated velocity numbers and — worse — a planning model with no concept of the review burden it is generating.

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

The non-obvious corollary: teams that drop story points entirely for hybrid sprints often report better planning accuracy, not worse. Story points in a hybrid context create false precision. You are estimating effort for work that finishes in minutes while ignoring the review burden that actually determines sprint throughput. Replacing points with scope sizing for agent tickets removes a metric that was misleading the planning process, not informing it.

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

Agent ticket acceptance criteria need two additions the human version does not. Context requirements — what the agent must include in the PR description so the reviewer's job is feasible. Scope constraints — guardrails that stop agents from modifying code outside the ticket's stated boundaries, which is a common drift pattern that silently expands the review surface. Both belong in the ticket template, enforced before the PR opens. If they live in reviewer goodwill, they will be skipped under load.