The velocity trap

Why generation can outpace verification and reduce real delivery throughput.

The velocity trap: generation outruns verification

In an agentic workflow, code generation is cheap and verification is the bottleneck, so an engineer’s value moves from how fast they write a function to how rigorously they can prove that a generated one is correct. The Velocity Trap is what happens when generation outruns verification. A team adopts agents, output surges, and they try to verify the new code the old way: a senior engineer opens a thousand-line agent-generated pull request and skims it, because the LLM does not tire but the reviewer does, assumes it “probably got it right,” and approves. The felt velocity is real while actual throughput can move the other way, because unverified code generates its own rework: incompatible state-management patterns, hallucinated database strategies, edge-case bugs that only surface in production. The only escape is to automate the verification; if you cannot automatically verify an agent’s output, you should not be using the agent.

The March of Nines explains why the impressive demos mislead. An agent demo works about 90% of the time, the happy path, and that first nine is cheap because it dominates the training data. Enterprise software needs four or five nines, and each additional nine costs roughly the same engineering effort as the one before while the visible improvement shrinks: edge cases and error handling for the second nine, race conditions and timeout handling for the third, scale and query optimization for the fourth. Addy Osmani calls the same shape the 70% problem: AI gets about 70% of the way, and the last 30%, the edge cases, architecture, tests and cleanup, still needs the engineer’s work (The AI-Native Software Engineer, Addy Osmani (opens in a new tab), 5 December 2025). The cheap bulk arrives first, and the hard tail carries the real engineering.

Closing loops pushes the agent as far up that ladder as automation can carry it, but the ladder has a top: the distributed-locking race, the timeout that corrupts billing, the N+1 query that melts the cluster are exactly the failures unit tests, types, linters, and CI do not catch on their own. That residue is the last 30%, and it stays with human judgment, not with another check.

Field reporting from inside Anthropic puts numbers on the split. Rewriting the Bun runtime from Zig into Rust, 535,496 lines excluding comments, went from start to merge in eleven days on 64 parallel agents and $165,000 of tokens at API prices, against an estimate of roughly a year for three engineers holding full context; implementation was about 15% of the effort and fixing plus validating the result the other 85%. Two conditions carried those eleven days, and neither was the agents. The existing test suite was written in TypeScript and therefore did not depend on the implementation language, so it graded the new code without being ported first, and the runtime’s creator supplied the domain judgment the agents could not. The lab’s head of platform engineering states this page’s thesis in the same terms, that verification is more time-consuming than implementation, and its engineers report that most tokens go to discovery, prototyping, mocking, and verification rather than to writing the code (The Pragmatic Engineer - How software gets built at Anthropic (opens in a new tab), July 2026, paid).

Resources

Field accounts

• The Pragmatic Engineer - How software gets built at Anthropic (opens in a new tab) - Paid interview-based account of engineering practice inside an AI lab, with effort splits, agent counts, and token costs from two shipped projects.