My experience is that such one-shotted projects never survive the collision with reality. Even with extremely detailed specs, the end result will not be what people had in mind, because human minds cannot fully anticipate the complexity of software, and all the edge cases it needs to handle. "Oh, I didn't think that this scheduled alarm is super annoying, I'd actually expect this other alarm to supersede it. It's great we've built this prototype, because this was hard to anticipate on paper."

I'm not saying I don't believe your report - maybe you are working in a domain where everything is super deterministic. Anyway, I don't.

I've been doing spec-driven development for the past 2 months, and it's been a game changer (especially with Opus 4.5).

Writing a spec is akin to "working backwards" -- this is the outcome I want, how do I get there?

The process of writing the spec actually exposes the edge cases I didn't think of. It's very much in the same vein as "writing as a tool of thought". Just getting your thoughts and ideas onto a text file can be a powerful thing. Opus 4.5 is amazing at pointing the blind spots and inconsistencies in a spec. The spec generator that I use also does some reasoning checks and writes property-based tests (Python Hypothesis), which anchors the generated code to some reality.

With a spec, I can get a version 1 out quickly and (mostly) correctly, poke around, and then see what I'm missing. Need a new feature? Tell the LLM to update the spec and code it.

And here's the thing -- if you don't like version 1 of your code, throw it away but keep the spec (those are your learnings and insights). Then generate a version 2. This echoes Grant Slatton's "Write everything twice" [1] heuristic -- write your code once, solve the problem, then stash it in a branch and write the code all over again. This is effective because initial mental models of a problem are usually wrong.

> A piece of advice I've given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better. So you get maybe 2x higher quality code for 1.25x the time — this trade is usually a good one to make on projects you'll have to maintain for a long time.

Spec-driven development lets you do this even faster, and it improves the quality of your insights into the actual problem by removing the friction of writing code multiple times.

[1] https://grantslatton.com/software-pathfinding

I think there's a difference between people getting a system a d realising it isn't actually what they wanted and "never survive collision with reality".

They survive by being modified and I don't think that invalidates the process that got them in front of people faster than would otherwise have been possible.

This isn't a defence of waterfall though. It's really about increasing the pace of agile and the size of the loop that is possible.