The Sprint That Was Sized for the Wrong Stage

The problem

An internal platform team I worked with had a code-review-comment agent that had been stable for months. It drafted PR review comments flagging style and lint issues, a single job, run enough times that everyone trusted its error rate. Leadership wanted it wired into the CI orchestration next, with quality gates that could actually block a merge on a bad review comment. Reasonable goal. The problem was how the timeline for that jump got set.

Two weeks. A fixed sprint, treated as a linear extension of the work that had already shipped the standalone agent. Two weeks is roughly 80 person-hours for one engineer. Stabilizing that agent in the first place had cost something like 18 hours. The team scoped the next step as if it were a small multiple of the last one, a few more days for a bit more scope, the way a feature backlog usually scales.

Wiring an agent into a CI orchestration with real merge-blocking gates is a different kind of work entirely, and the real cost of that jump runs closer to 172 hours. Roughly tenfold what the Stage 3 build cost, a genuinely different order of magnitude than the sprint that had just shipped. Hoping the two-week estimate was close enough didn't make it close enough. The team burned the sprint, cut corners on gate design to hit the date, and shipped a Stage 4 gate that started blocking unrelated merges on bad review comments it should never have flagged in the first place. I ran a seeded batch of thirty pull requests through the rushed gate and measured a post-launch defect rate above 25 percent, high enough to make the corner-cutting visible on a dashboard instead of buried inside a "sprint complete" status that looked fine on its own terms.

The pattern

The fix routes the advancement decision through a budgeting tool before anyone commits to a timeline, while there's still room to change the plan. The tool encodes the real, non-linear effort curve as a lookup table: roughly 18 hours to stabilize a Stage 3 box, 172 for a Stage 4 orchestration wired around it, 1,200 for Stage 5 evidence-gated autonomy, 6,000 or more for Stage 6 multi-agent coordination. Any proposed advancement gets checked against that curve before it's approved, and a variance beyond a configured tolerance blocks the advancement outright.

Run the same two-week sprint through that check and it gets flagged immediately as underscoped relative to the actual Stage 4 budget. The tool doesn't fix the mismatch on its own. It forces the conversation into the open before the work starts: either the team gets the real 172 hours, or it explicitly narrows the gate's scope down to something two weeks can actually deliver honestly. Once that choice gets made deliberately instead of by accident, the post-launch defect rate on the same seeded pull requests drops below 10 percent. The underlying work is exactly as capable as it was before. What changed is that the team stopped pretending a tenfold jump in effort was a small extension of what came before it.

This pattern's real limit sits at the organizational layer, past where the tool itself can reach. A budgeting tool that correctly flags underscoping can't force leadership to fund the difference. What it does is drag the disagreement into view before the failure happens instead of after, which is a genuine improvement even though it's an incomplete one. The tool's authority ends at the estimate. Someone still has to choose between funding the real number and cutting the scope to fit, and nothing about the curve itself makes that call for them.

Design considerations

This is the pattern with the clearest outside corroboration I've come across, and it arrives from the cost side of the industry, a different vantage point than the quality side this comes from everywhere else. Gartner's Hype Cycle for Agentic AI projects that over 40 percent of agentic AI projects will be canceled by the end of 2027, a number I read as a direct, if anonymous, tally of teams that committed to a stage advancement on a timeline the real work never actually fit. McKinsey's 2026 State of AI survey adds the resourcing half of the same story: 93 percent of surveyed organizations report exceeding their AI budgets, and only 20 to 25 percent report having mature AI FinOps practices in place to catch it before the invoice arrives. Neither source is describing this specific hour curve. Both are describing the identical underlying failure, claimed maturity outrunning evidenced maturity, just wearing a resourcing costume instead of a quality-gate one.

The curve itself is a starting estimate. The 18/172/1,200/6,000-hour benchmarks came out of specific delivery engagements, and a different team, a different codebase, a different quality bar for what counts as "done" at each stage, will land somewhere else on the actual number even while the shape, each jump running roughly an order of magnitude past the last one, tends to hold. Treating the specific hour counts as gospel for every team is a misuse of the tool. The non-linear shape is the actual thing to budget against.

The tolerance band you set for "close enough to the curve" is its own calibration problem, and I don't think there's a universal right answer. Too tight, and legitimate efficiency gains from a team that's genuinely gotten faster at this kind of work get flagged as suspicious every time. Too loose, and the tool quietly waves through the same underscoping it was built to catch. I'd rather set that tolerance by watching a team's actual variance across a few real advancements than import a number from somewhere else and assume it transfers.

The place this doesn't help at all is a team that's advancing a stage for the first time, with no actuals of its own yet logged against the curve. The tool's value compounds the more real advancement history it has to check new estimates against. On the very first jump, it's still better than nothing, a documented, non-linear expectation beats an undocumented linear guess every time, but it's working with someone else's numbers until the team accumulates enough of its own to trust the comparison fully.