Estimation was always a proxy for scarce human capacity. The capacity that's scarce has changed. Some teams haven't noticed their points now measure the wrong resource.
I've now watched three different answers to the same question play out in real organisations. The question: how do you size a Jira story when an AI does most of the building?
One CTO I know settled it by decree. Every story is one point. Velocity becomes a count of things finished. Another organisation I worked with kept estimating as though a human would write the code by hand, then quietly absorbed the fact that sprints finished early and scope kept getting topped up mid-cycle. The third answer, which is the most common one, is drift: nobody decides anything, the old numbers keep getting assigned out of habit, and everyone privately agrees they mean less each quarter.
All three are responses to the same underlying event. Story points were invented to ration a scarce resource, and the resource they were built to ration has stopped being scarce. Before deciding what to estimate now, it's worth being precise about what the old estimates were actually for.
A story point was always a claim about consumption: this item will consume roughly this much of our team's limited capacity to produce working software. The Fibonacci scale, the poker, the relative-sizing doctrine — all of it existed because the constrained input was skilled human hours spent designing and writing code, and because forecasting required converting a backlog into a number of sprints.
Two things followed from that. First, the estimate had a customer: someone converted points into dates, headcount decisions, or commitments. Second, the estimation conversation had a side benefit that was often worth more than the number — it forced the team to discover, before work started, that two engineers had completely different models of what the story involved.
Both purposes survive. The input being rationed does not.
CircleCI's 2026 throughput data shows feature branch activity up 59% year over year while main branch throughput for the median team fell. Code is being produced faster than it is being accepted.
A Carnegie Mellon and Stanford study of 802 developers and roughly 196,000 pull requests found per-capita PR throughput hit 2.09× baseline — while the load on each reviewer roughly doubled. Agent-authored pull requests receive lower review rates, faster merges, and less discussion than human-authored ones. Scrutiny is thinning precisely where it should be thickening.
The METR randomised controlled trial found experienced open-source developers expected AI tools to make them 24% faster. Measured end to end, they were 19% slower. After living through the experiment, they still believed the tools had sped them up by about 20%. A 39-point gap between perceived and actual velocity, in the population best positioned to know.
The generation step compressed. The verification step didn't, and in many settings it grew, because reviewing a large diff you didn't write is a genuinely different and slower activity than reviewing a colleague's work whose reasoning you watched develop. The cost of a story moved downstream and changed shape.
This is why "estimate as if a human wrote it" fails on two counts. The obvious count: the reference class is evaporating, and within a few years nobody on the team will have a calibrated sense of hand-built effort to reference. The less obvious count: the METR result shows that even people who still possess that reference can't apply it to AI-assisted work. Their introspection is off by nearly 40 points. You'd be anchoring on a memory filtered through a systematically broken perception.
The everything-is-one-point rule deserves more respect than it usually gets, because it's not really an estimation scheme. It's the no-estimates position wearing a Jira costume: right-size every story during refinement, then just count throughput. Cycle time and item count replace velocity, and forecasting becomes Monte Carlo over historical completion rates rather than arithmetic over guesses.
For a certain kind of team this is correct. If your stories are genuinely sliced small, if the flow of work is steady, and if nobody downstream converts points into promises, then estimation was overhead and the flat one prices it accurately.
But notice what the rule actually did: it relocated the judgement. "Every story is a one" only produces a usable forecast if stories are roughly uniform, and making them uniform requires exactly the sizing skill you claim to have retired — exercised implicitly, during slicing, with no number attached and no disagreement surfaced.
The flat one is a reasonable endpoint for teams with mature slicing discipline and no forecast customers. It is a poor starting point for anyone else.
Not code production. Not, increasingly, test production, documentation, or migration scripts. What remains stubbornly human, and therefore stubbornly finite, is attention applied with judgment.
Someone has to convert intent into a description precise enough that an agent's output can be judged against it. Ambiguous stories used to be resolved through a hundred micro-decisions an engineer made while typing. Those decisions still exist; they've moved forward into the spec, or they leak into review as surprises.
Someone has to decide the output is correct, safe, and consistent with the architecture — and the data above says this is now the system's bottleneck. Verification cost has almost nothing to do with lines of code produced and almost everything to do with how expensive it is to check the work: does a test suite meaningfully cover it, or does a human have to reason through the change? Can it be validated in staging, or only against production data? Is correctness observable at all, or only discoverable at month-end close?
Someone has to own the consequences. A change that can be reverted in a minute consumes little attention regardless of size. A change to authentication, money movement, or an irreversible data migration consumes a great deal of it, even when the diff is four lines.
A large, well-documented, well-tested surface is big context and cheap attention. A one-line change to billing logic is tiny context and expensive attention.
The old anchor: how much effort to build this? The new anchor: how much human attention will this consume before we'd bet on it in production?
Concretely, size against three questions during refinement:
A story that scores low on all three is a one regardless of how much code the agent emits. A story that scores high on any one of them earns real points even if the diff is trivial. You will find this produces strange-looking numbers at first — a 3,000-line generated CRUD module sized at 2, a config change sized at 8 — and those strange numbers are the method working. They're pricing the resource you actually run out of.
Two implementation notes. First, start tracking review and verification time as a first-class field, separate from total cycle time. It is your new constraint, and you cannot manage a constraint you don't measure. Second, expect Goodhart. Any number in Jira becomes a target within two quarters; the defence is the same as it always was — keep the number owned by the team that does the work, and never wire it to individual performance.
The scheme above covers work where a human is in the loop. An increasing fraction won't be. Dependency bumps, test backfills, well-specified refactors gated by comprehensive evals — work where the specification exists, verification is mechanical, and blast radius is contained — will run agent-to-merge with no human attention consumed at all.
Don't point that work. Pointing it would be pricing consumption of a resource it doesn't consume. Route it into a separate lane measured the way you'd measure any automated pipeline: throughput, cycle time, eval pass rate, revert rate. Over time, the interesting management signal becomes the migration rate between lanes — how much of your backlog graduates from attention-priced to fully automated each quarter. That number tells you more about your engineering organisation's real AI maturity than any velocity chart ever did.
Story points were never a measurement of the software. They were a measurement of the organisation — of what it found difficult, what it couldn't parallelise, where its judgment was thin.
That hasn't changed. What's changed is the answer. The difficulty was never really in the typing, and now the typing is gone, the estimate finally has to say what the difficulty actually is: deciding what to build, and knowing whether you built it.