Velocity has always been a proxy. The assumption behind it is that human coding effort correlates with delivery complexity: a higher-point sprint means more done. That assumption held roughly true for long enough that most teams stopped examining it. It stopped being roughly true for us around the beginning of 2026, and we spent two quarters discovering that in the worst possible order.
The quarter we started using coding agents heavily, velocity went up. Tickets that had taken a senior engineer a morning to write were being generated in under an hour, reviewed, and closed. Sprint numbers looked excellent. Then we hit two integrations in the same fortnight where the code was correct at the function level and wrong at the system level. The agent had written what was asked for and encoded the wrong decision in both cases, because the ticket had not been specific enough about which decision was being made. Nobody caught it in review because the code passed tests, and the tests encoded the same misunderstanding as the ticket.
Where the risk sat
This is the particular way agent-generated code fails. It is not usually wrong in an obvious sense. It fails at the seam between what the ticket specified and what the system needed, because the agent executes what it is given. If what it is given is ambiguous, the result is confident code built on an unresolved question. Confident code fails quietly until it fails loudly.
Our estimation process did not account for this because the process was designed around effort, not around decision resolution. A five-point ticket used to mean roughly five times the effort of a one-point ticket: more reading, more writing, more decisions, all blended into a single estimate. When agents compressed the writing to near nothing, what remained was the thinking and the reviewing. Those did not compress at the same rate. A five-point ticket's worth of thinking and verification remained roughly as much work as it had been; the writing disappeared, but the decision work and the review work did not.
Two attempts at a fix
The first repair was to re-size tickets to reflect review time rather than writing time. We started estimating a ticket as the combination of what it would take to specify clearly and what it would take to verify that the agent's output had understood the specification correctly. This held for about six weeks before the incentives moved: engineers closed tickets faster by spending less time on review. The metric rewarded speed of closure; the system had no mechanism to distinguish a careful review from a cursory one. We had adjusted the number without changing the thing the number was supposed to measure.
The second attempt was to add a verification checklist to the definition of done. This introduced overhead without improving clarity. The checklist became a formality about a week after it was introduced, which is the same thing that happens to checklists in most teams when they are designed to satisfy a process requirement rather than to resolve a genuine uncertainty.
The question we were not asking
What we got wrong in both attempts was treating estimation as a planning question. Both repairs were attempts to preserve the planning model by adjusting its inputs. The underlying question was different: not how long will this take, but what is the scope of decision encoded in this ticket, and has that decision been made.
A ticket that describes a clear, well-scoped change with explicit acceptance criteria is genuinely low-risk when an agent writes it, because the agent has enough to work with and the reviewer has enough to check against. A ticket that describes a design decision the team has not yet made, expressed as an implementation request, is high-risk regardless of how quickly the code is generated, because neither the generation step nor the review step will surface the missing decision. The estimation model needed to distinguish between those two kinds of ticket. It did not.
We now size by decision complexity rather than coding effort. The sprint planning conversation asks how many decisions a ticket encodes, whether those decisions have been made, and whether the people reviewing the agent's output will have enough context to recognise a misunderstanding. This is a blunter instrument than the point-based system it replaced. It is harder to explain to a client who wants a velocity chart and does not lend itself to burn-down graphs.
The objection worth taking seriously is that decision complexity is difficult to define consistently across a team, and that a system based on it is prone to the same drift as the checklist: it becomes whatever the team agrees to call it, which is not necessarily what it was designed to measure. We have not solved that. What we have done is replace a metric that looked precise and was measuring the wrong thing with a metric that is obviously approximate and at least attempting to measure the right thing.
We are asking, before any code is generated, whether we understand the decision well enough to describe it to something that will execute it literally. When the answer is no, we stop and make the decision before writing the ticket. This is not a new engineering practice. It is the old practice of writing a clear specification before writing code, restated for a context where the code is not written by an engineer. The restating has made it harder to skip.
“We are asking, before any code is generated, whether we understand the decision well enough to describe it to something that will execute it literally.”