What replaces velocity when agents write code

Velocity measured effort, and effort is no longer the scarce thing. Replace it with three numbers that still mean something when the worker is a machine: verified throughput (completions that passed a gate, never raw completes), first-pass verification rate (what share passed on attempt one), and cycle time split by phase (where the time went). None of them can be inflated by producing more output faster. That is why they still work.

Why did velocity stop working?

Because it used effort as a stand-in for value. Effort changed by an order of magnitude. Value did not.

Story points were always an estimate of effort. Effort was a fair stand-in for value because producing work was the expensive part. That link is what broke. An agent can generate the code for a story in seconds, so the effort estimate no longer describes anything scarce. A team whose agents produce a hundred points in an hour has not delivered a hundred points of value. The unit has stopped measuring anything.

The industry data shows the split you would expect. Teams with heavy AI adoption have been seen merging far more pull requests while review time rose sharply. Their net productivity gains landed between the low single digits and around ten percent. Throughput and delivery came apart. DORA's 2025 report found the same tension from another angle: AI adoption improving throughput while relating negatively to delivery stability.

Velocity cannot represent that. It goes up in both the good case and the bad one.

Should you keep estimating at all?

Yes, for planning. Stop reporting it as an outcome.

An estimate is still useful for its original job. It helps you decide what fits and spot a task that is much bigger than it looks. It also starts the conversation where somebody says "that is not a two, that is a rewrite". That conversation has value even when the number is wrong.

What has to stop is the second job estimates picked up: adding them together and using the sum as a performance measure. That was always a bit dishonest. Now it does not work at all. The same estimate can be met by four seconds of machine time or two days of human time, and the number cannot tell you which.

One practical note if you keep estimating. Use a scale with real gaps. Make the field a person reads the same field the chart counts. T-shirt sizes plus a lookup table somewhere else give you two versions of one fact, and they drift apart.

What is verified throughput?

Completions that passed verification, per period. The important word is verified.

Raw completion counts are the vanity metric of engineering with agents. They are worse than useless because they look like progress. A worker that can mark forty tasks done in an hour turns "completions per week" into a measure of how fast your workers can claim things are done. The chart rises whether or not anything was delivered. Somebody will still present it.

Verified throughput is the same chart with the numerator fixed. It moves more slowly, and it is sometimes embarrassing. It is the only version you can defend to a stakeholder who checks. The gap between the two lines is the most useful thing on the page. It shows how much work was claimed and did not hold up.

Which numbers should be on the wall?

Four. Each one answers a different question:

The pairs tell you more than any single number. If throughput rises while first-pass rate falls, you are shipping specification debt. A first-pass rate of 100% usually means the gate is not checking anything. If cycle time stays flat while build time collapses, the constraint has moved into spec or review. That is the most common finding when a team adds agents and wonders why nothing got faster.

What about the review time that ate the gains?

Measure it separately, because it is the part you can fix.

Human wait share is the percentage of cycle time spent waiting on a person instead of on work. It is where the AI productivity gains have been going. The expensive part is usually the queue in front of the review, more than the review itself. That queue is the gap between work being ready and somebody picking it up.

It is worth measuring on its own because it responds to different levers from everything else on this list. Specification quality is an engineering and writing problem. Wait share is a scheduling problem. Scheduling problems are cheap to fix once somebody can see the number.

How do you move from one to the other?

Run both for a quarter and let the difference make the case.

Do not announce that velocity is cancelled. Add verified throughput beside it and wait. Within a few sprints the two lines separate. The gap between them starts the conversation: this is what we counted, and this is what held up. That is a much easier case to make than an abstract one about proxy metrics. It also uses your own data instead of someone else's report.

If you still can, take the baseline before the agents scale up. Four to eight weeks of it beats any model built after the fact. Once agent volume is high, the pre-agent comparison is gone for good.

In Cognibl every headline number is computed from the verifier's records, not from activity. That is why the figures are smaller and duller than a usage dashboard's. It is also why you can show them to somebody who checks.