Build first,
ask questions later.

I built three of the prototypes my team reviewed last quarter the night before the meeting. Each took ninety minutes. Two were rejected on sight. One shipped.

Five years ago that exercise would have cost three engineer-weeks and lived behind a Figma click-through. The fact that it now costs a single evening with a capable model is the boring part. The interesting part is what it does to the spreadsheet every software methodology has implicitly been running since 1970.

01 The slide everyone has seen

Every consulting deck on software process eventually arrives at the same chart. A defect costs 1x to fix in requirements, around 6x in implementation, 15x in testing, and 60 to 100x in production. The slide is usually attributed to the IBM Systems Sciences Institute. Laurent Bossavit has noted that the source study is hard to actually produce, but the directional truth has been confirmed enough times by NIST and Capers Jones that no senior engineer would bet against the shape of the curve.

That curve is the load-bearing argument for every "measure twice, cut once" methodology of the past fifty years. Waterfall took it to its logical conclusion. Spec everything upfront, because changing your mind in code is fifteen times more expensive than changing your mind on a wiki. Agile did not refute the curve. It said: ship smaller and reach production faster, so the 100x cannot accumulate.

02 What the curve was actually measuring

The curve was always measuring two things at once. Code was expensive to write, and the further a change moved through an organisation, the more people had to be talked through it. Sometimes for technical reasons. Sometimes just to keep stakeholders content. Agentic coding only changed the first.

Most of that fact has now been priced out of prototype work.

At Anthropic, more than 80% of the code merged into their own production codebase is now written by Claude, and code shipped per engineer has grown roughly eightfold against the pre-agent baseline. Stripe rolled the same tooling out across 1,370 engineers and watched one team complete a 10,000-line Scala-to-Java migration in four days, against a prior estimate of ten engineer-weeks. That is a 25x compression on a real piece of load-bearing work, not a toy benchmark. For genuinely throwaway code, credible estimates put the multiplier in the 5 to 10x range.

When the cost of being wrong in code drops by an order of magnitude, the break-even point for "spec everything upfront" moves a long way to the right. For any task small enough to be built in a single session, it is now cheaper to use the prototype itself as the spec than to write the spec first.

03 A prototype is a more honest artifact than a spec

The waterfall versus agile debate was always the wrong axis. The real axis is: what is the cheapest representation of an idea you can put in front of a stakeholder? In 2010 that was a wireframe. In 2020 it was a Figma click-through. In 2026, increasingly, it is a working app.

That matters because Figma lies about feasibility and working apps do not. A demo that hits a real API and breaks on real edge cases is a more honest artifact than any specification document. The cost of having a product conversation in code instead of slides has dropped below the cost of preparing the slides.

04 Where the curve refuses to flatten

If the story ended here it would be a victory lap for vibe coding. It doesn't. The 2025 DORA report on AI-assisted software development finds two things in the same breath: AI is now associated with meaningfully higher throughput, and meaningfully higher delivery instability. Both, at once. The report calls AI a mirror that amplifies whatever an organisation already is.

The supporting data is uncomfortable. Veracode's 2025 GenAI Code Security Report puts the rate of security flaws in AI-generated code at around 45%, with 86% failing to defend against XSS. Cloud Security Alliance research finds secret leakage in AI-assisted commits at roughly twice the rate of human-only commits. CVEs attributed to AI-generated code jumped from 6 in January to over 35 by March. None of this is fatal. All of it is the curve refusing to die quietly.

And that is only the technical half. The other half is the slow paperwork around any production change. Approvals, sign-offs, the people who need to be in the room. None of that runs faster because the agent does.

The cost of building has cratered. The cost of understanding the result has not. Once a codebase is large enough, reading outpaces writing as the binding constraint, and AI writes faster than any human can responsibly read.

05 The curve did not flatten. It split.

Three costs used to track each other. They no longer do.

• Wrong prototypeCratered.An afternoon, often less.
• Wrong architectureUp.More generated code means more to read when it breaks.
• Wrong productUnchanged.Users do not care that you shipped wrongness quickly.

That asymmetry is the part the productivity headlines miss. METR's widely-shared study found experienced developers working in their own large codebases were 19% slower with AI tools. The 19% became the headline; the caveat did not. The cost the model paid was reading time, against humans who already had the codebase loaded in their heads. Agentic coding is fastest where humans are slowest, on foreign codebases and mechanical migrations, and slowest where humans are fastest, in code they have already internalised.

06 What this means in practice

Waterfall has moved one level up. The spec used to be the document the contractor implemented. The contractor is now an agent, and the spec is now the prompt. The artifact that mattered in 1995 still matters in 2026, just expressed differently and consumed by something that can read it at machine speed.

The rule I have ended up with is unromantic. Build first for anything below a complexity threshold where the whole thing fits in a single agent session and the cost of being wrong is an afternoon. Above that line, write the spec first, not because the build is expensive but because the read will be, and an agent given ambiguous intent will produce ambiguous code at an alarming rate.

The advice in the title still works, but only for prototypes. For anything past the prototype the questions still matter, and have only moved up a level into the spec the agent is reading.