Estimate the Review, Not the Writing

A team I work with recently had the world's fastest sprint planning argument. The ticket was a REST endpoint with validation and tests — a textbook three-pointer. One engineer pointed out that Claude Code had done the last one, end to end, in about twenty minutes. So is it a three? A one? A zero? Someone joked they should estimate it in cents.

They were closer to the truth than they realized. Story points were always a proxy for human effort and uncertainty. When an agent does the drafting, the estimate is a lie — not because the work got easy, but because the effort moved somewhere your estimation ritual doesn't look.

Your work is bimodal now

Watch where the hours actually go on an agent-assisted team and a pattern emerges. Work splits into two modes with almost nothing in common.

Mode one: well-specified, well-verified. Clear requirements, good test coverage, established patterns in the codebase. An agent handles this in minutes, and the human cost is a scoped handoff plus a careful review. The old estimate is off by 5–10x.

Mode two: everything else. Ambiguous requirements, gnarly legacy corners, cross-team dependencies, changes where verification means manual poking because the tests don't exist. Agents help at the margins. The old estimate is roughly right.

Average these into a single velocity number and you get noise. Your burndown says the team got 4x faster; your release date says otherwise; and forecasting off historical velocity means your past data no longer predicts anything. Teams that "10x'd their velocity" mostly broke their ruler.

The constrained resource changed

Estimation exists to allocate the scarce thing. For twenty years the scarce thing was engineer-hours-writing-code. It isn't anymore. On an agent-assisted team the scarce resources are, in order: verification capacity (someone has to review, test, and vouch for every diff — and a human can only do that carefully so many hours a day), specification quality (an agent amplifies a good spec and faithfully implements a bad one), and integration risk (ten agent-built branches merging into the same service is a coordination problem no agent solves for you).

So estimate those. In practice, here's what I'd change about planning, concretely:

Size the verification, not the authorship. For each ticket ask: how long will a competent reviewer need to understand this diff, check it against intent, and be willing to own it in production? A generated 800-line change to payment logic is large, even if it "wrote itself" in four minutes. A generated CRUD endpoint with exhaustive tests is small. Note the reversal: the old sizing tracked writing difficulty; the new one tracks blast radius and reviewability.

Split the modes in your tracking. Tag work as agent-eligible or human-led, and forecast them separately. The agent-eligible lane runs on throughput — tasks per week, limited by review capacity. The human-led lane still works fine with t-shirt sizes. One team I know keeps a simple rule: if nobody can describe the acceptance test up front, it's human-led by definition. That rule alone kills most of the misclassification.

Cap agent WIP like you cap human WIP. The failure mode of cheap drafting is a wall of open PRs aging like milk while reviewers drown. If your reviewers can carefully process, say, six substantial diffs a day, then six is your throughput — no matter how many agents you run. Kicking off more work doesn't add capacity; it adds queue. This is the same lesson kanban taught us, back with a vengeance.

Re-baseline, don't extrapolate. Whatever your velocity was before agents, it's not a planning input anymore. Run four to six weeks of the new split tracking before you promise dates off it. Painful, yes. Less painful than committing to a roadmap built on a metric that measures a workflow you no longer use.

What planning is actually for

Here's the part I find useful to say out loud in retros: the point of estimation was never the numbers. It was the conversation — surfacing ambiguity, spotting risk, forcing someone to articulate what "done" means before work starts. Agents make that conversation more valuable, not less, because a vague ticket now turns into confidently wrong code within the hour instead of a clarifying Slack thread. Planning poker over drafting effort is dead weight. Planning around "what would we accept as proof this works, and who can verify it this sprint?" is the highest-leverage meeting on your calendar.

Takeaway: Stop estimating how long code takes to write; almost nothing interesting lives there anymore. Size work by verification cost, track agent-eligible and human-led work as separate lanes, cap agent output at your review capacity, and rebuild your baseline before promising dates. Velocity didn't just get bigger — it changed units. Plan accordingly.