When I say things like "delete the code, keep the spec," many people seem to interpret that as a rule: write the specification first, and only then are you allowed to program.
That's not what I mean. It's also not how anyone actually builds software. I think this is the source of a lot of pushback I've heard not just to my own ideas but to any of the various spec-driven development approaches that have spawned in the past couple of years.\
Experienced developers know this in their bones. Programming is one of the most important ways we find out what we actually want. You try something, it's wrong, and you change your mind. Some requirements don't exist until an implementation breaks them.
Here's a rule I know to be true: My first attempts at specifiying a system are always wrong. This is a fact I've treated as a rule since I first started programming in earnest in the 90s. I think this is what drew me to eXtreme Programming immediately when I saw it. "A user story is the promise of a conversation". Sometimes it's a conversation with the business owner. Sometimes it's a conversation with unit tests and a compiler.
Matteo Paltenghi and Satish Chandra seem to have had the same intuition. AfterVibe: What Remains When the Conversation Ends explores this scientifically. They extract specifications from finished AI coding sessions and the code changes those sessions produced. Then they hand the recovered spec to another agent and ask it to rebuild the same changes in the existing repository.
That's the part I find exciting. The first implementation is how you discover what you mean. The second is how you find out whether you wrote it down.
So the order flips. You start with a vague idea and hack until something works. You come out the other side with a spec you couldn't have written on day one. Then you regenerate, and you see what the spec actually kept. Given enough time and money, every software project ever created could have benefited from this. But now we can do it many times per day with (re)generative AI.
None of this removes judgment. Regenerate a bug faithfully and you've just got a bug with better provenance. Someone still has to decide which discoveries become requirements and which were accidents.
You don't have to know everything before you start. You just have to stop throwing away what you learned.
Thanks to Dusan Omercevic, CEO of Codeplain, for pointing me to the paper.