Your agent isn't failing. It's guessing.

The speed argument is over and nobody won

The most careful team measuring AI developer productivity ran a second experiment, then published a paper explaining why you should not use its results.

METR produced the most-cited number in this whole argument in July 2025: experienced open-source developers were 19% slower with AI tools. In February 2026 they published the follow-up. The second experiment ran 57 developers, and the raw numbers point the other way: an 18% reduction in task time for returning participants, 4% for newly recruited ones. Negative means faster here. The confidence intervals are −38% to +9% and −15% to +9%, which is statistician for we cannot rule out that nothing happened at all.

Then they disown the numbers. The data, they write, “gives us an unreliable signal of the current productivity effect of AI tools.” Three things went wrong, and each one bends the result a different way. Developers who depend on AI increasingly declined to join a study that might assign them to work without it, so the people these tools help most removed themselves from the sample, which METR says “likely biases downwards our estimate of AI-assisted speedup.” The pay dropped from $150/hr to $50/hr, changing who volunteered at all. And the stopwatch itself stopped working: you cannot cleanly time a task when the person doing it is supervising four agents at once.

So the famous slowdown is not the current number, and there is no current number. The sharper question went unmeasured: when the agent finishes, did it build the thing you wanted?

Underspecification doesn't cause failure. It causes guessing.

In July 2026 a team at HKUST published UnderSpecBench. They took 69 task families of real DevOps work, grounded in documented incidents and CVEs, and varied one thing: how the instruction was written. 2,208 prompt variants across five agent-and-model configurations spanning Claude Code, Codex, and OpenCode.

In their words, “the axes perturb only the natural-language instruction; the environment, the available tools, and the test oracle are held fixed, so any change in agent behavior is attributable to underspecification.”

One axis carries the result: target certainty. At the baseline the instruction names “a fully qualified, unique target.” At the top level it uses under-determined references that match several candidates (the paper's own examples are “the old one,” “the stale config”), “so the agent must decide whether to confirm or to guess.”

Wrong target, named identifier

9.6%

Baseline instruction names a fully qualified, unique target.

Wrong target, “the old one”

75.1%

Same model, same environment, same correct action available.

Safe success, same swing

8.6%

Down from 67.9% at the precise baseline, among runs where the agent acted rather than asking.

The only thing that changed was whether the sentence named the thing it was talking about.

The paper's own summary: “underspecification does not mainly make agents fail; it makes them guess.”

If you have ever written “clean up the old migration files” in a ticket, you have already run this experiment.

Confident wrongness is the expensive kind

The failure mode matters more than the rate. An agent that stops and asks a question is nearly free. An agent that picks the wrong database and proceeds with total confidence is not, and confidence is what underspecification produces. Across all five configurations, between 55.8% and 67.8% of runs violated at least one boundary.

Nor do they get more careful as the stakes rise. The same study varied blast radius, moving the identical operation from a contained development surface to “a shared or production surface where a mistake propagates to others and cannot be undone.” Action rate on the contained surface: 65.5%. On production: 64.0%.

Faros AI published telemetry in April 2026 from two years of data across 22,000 developers and more than 4,000 teams. Delivery accelerates. And then the rest of the picture arrives.

Faros sells engineering intelligence, so read them with one eyebrow up, and note this compares different teams rather than the same team before and after. But an 861% churn gap tracks with a lot of code getting written and then thrown away.

METR's March 2026 note found that many SWE-bench-passing PRs would not be merged into main. Passing the test and passing review turn out to be different achievements.

An observational study of 20,574 real agent sessions across 1,639 repositories, published in May 2026, found that 91.49% of visible resolutions still require explicit user correction. And on Hacker News in March 2026, the maintainer of Marginalia Search itemised a task that took eight rounds of correction: “Now the 15 minutes of amazingly fast AI code gen has ballooned into taking most of the afternoon.”

More words is not the fix

We sell specification tooling. The evidence says most of what you currently write is dead weight.

In February 2026, researchers at ETH Zurich evaluated AGENTS.md files directly across multiple agents and models. The finding: “providing context files does not generally improve task success rates, while increasing inference cost by over 20% on average. This observation holds across different LLMs, coding agents, and for both LLM-generated and developer-committed context files.”

If you maintain a 400-line context file that opens with a tour of your architecture, that tour is costing you 20% more tokens and buying nothing measurable.

But the next sentence changes the picture: “while instructions in the context files are well followed by coding agents, repository overviews, although popular and recommended by model providers, are not helpful.” Their conclusion: context files “are useful for specifying non-standard coding practices.”

The split runs between instruction and exposition, not between specification and no specification. The agent already knows what a repository is. It does not know that your billing module writes to two tables and that the second one is load-bearing.

A sufficiently detailed spec is code

In March 2026 Gabriella Gonzalez published the strongest argument against everything above, and it reached 652 points on Hacker News. She names two misconceptions behind spec-driven development: that specification documents are simpler than the corresponding code, and that specification work is necessarily more thoughtful than coding work. Her worked example is OpenAI's Symphony project, a showcase of spec-driven generation, whose SPEC.md she finds “less of a specification and more like pseudocode in markdown form”.

Dex Horthy of HumanLayer, who advocates for this way of working, conceded the point in July 2026: to guarantee the spec produces the code you want, “the spec will look a lot like code (and will be roughly the same effort to review as the code itself anyway, saving you no time).”

One commenter, on why this fails for non-trivial tasks: “I can research the problem and think about it really hard in detail to give bulletproof guidance, but that's just programming without the typing.” Another, running hundreds of concurrent agents in February 2026: “you can't spec out something you have no clue how to build.”

They are right about something specific: novel work. Writing the spec is the exploration, and demanding it up front relocates the hard part to a worse place.

That is UnderSpecBench's finding, published by the movement's sharpest critic four months before the benchmark existed. She and the people she is arguing with do not disagree about the mechanism, only the prescription.

The company everyone writes specs for doesn't write specs

Anthropic's product lead, Catherine Wu, describes her team's process: “PMs, designers, and engineers build demos instead of write docs.” They prototype in hours, ship internally, and watch what people do with it. When a product engineer relayed the approach to r/ProductManagement in April 2026, it drew 133 upvotes and a long argument.

That costs the spec-first pitch something. It should.

Kent Beck made the deepest version of this objection in February 2026, distinguishing The Finish Line Game, where you ship X and you are done, from The Compounding Game, where each thing you finish funds the next. “The hidden assumption behind this style of spec-driven development is that we're playing The Finish Line Game.” And: “A better spec will never get you from dollar sign N to dollar sign N+1 forever.”

The failure data won't flatter us either. That same 20,574-session study puts underspecified instructions at 15.36% of failure causes. The largest category, at 36.49%, is instruction-following failure: the agent received a clear instruction and did something else. Specs address the 15% problem, not the 36% problem.

Marc Brooker argues that spec-driven development “isn't about pulling designs up-front, it's about pulling designs up”, making specifications “explicit, versioned, living artifacts”. He works at AWS and writes regularly about Kiro, an AWS product in exactly this category, so weigh it accordingly. But the shape of the claim is right.

Practitioners describe the bottleneck in unglamorous terms. One, in a June 2026 thread: “My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.”

Specify the boundary, not the solution

The process argument collapses into a short list about nouns.

• Name the target exactlyNot “the old one.” The identifier. The one move with a hard number behind it: a 9.6% wrong-target rate against 75.1%. It costs you eight seconds.
• Say what must not happenAgents do not price in consequences. Moving the same operation onto a production surface changed the action rate from 65.5% to 64.0%. If something is irreversible, the instruction has to say so.
• Delete your repository overviewETH Zurich measured it: overviews are not helpful and context files cost over 20% more tokens. Spend that budget on the three constraints that are non-obvious about your system.

One honest caveat, since this piece has spent 2,000 words demanding evidence from everyone else. “Write acceptance conditions rather than architecture tours” is the natural next step from all of this, and nobody has run that experiment. ETH showed overviews don't help and instructions get followed; it did not show that acceptance criteria improve outcomes. Treat it as a reasonable inference, not a finding, and be suspicious of anyone selling it as more than that, including us.

And know which game you are in. If you are exploring a problem nobody has solved, prototype, and let the building be the specification. Anthropic does, and they are not wrong. If you are acting on a system that already exists, where “the stale config” resolves to four candidates and one of them is production, the noun you choose is the cheapest risk reduction available to you.

The historic thing here isn't that agents got good. It's which constraint binds now. For decades the expensive part of software was making the computer do the thing, and ambiguity was survivable because a human implementer would hit it and walk over to your desk to ask. Ambiguity no longer produces a question. It produces a confident action on the wrong object, at machine speed. Roughly two-thirds of the time, the agent acts rather than asking.

The stopwatch broke. The measurement that replaces it is less flattering and more useful: how much of what you built was what you meant.