Hindsight-Driven Development: An Iterative Approach to Building Software With AI

AI makes trying cheaper than guessing, yet spec-driven development still asks you to guess first. Meet Hindsight-Driven Development. Still writing the spec. The product is already done. You spend two hours writing a detailed spec for a feature. An AI coding agent builds it in ten minutes. You try it, and within a minute you see what the spec got wrong. In those same two hours, you could have built it, tried it, thrown away three versions, and kept the fourth. Specs force us to make our most detailed decisions at the moment we know the least. For decades, that was a fair trade. Building was expensive, so we paid to describe software first. AI broke that trade. Yet a popular response to AI coding agents is spec-driven development. Tools like GitHub’s Spec Kit and Amazon’s Kiro have you write and sign off on requirements, a design, and a task list before the agent writes any code. More detail, decided earlier. That gets it backward. Writing detailed specs for AI agents is waterfall, rebranded for the AI era. Even when that spec gets edited later, you still decide before you see. One exception, which I’ll come back to: decide up front whatever is expensive to undo. Build everything else. A spec is a guess with a signature on it Writing a spec means imagining a product that doesn’t exist yet and simulating it all in your head. That takes three kinds of guessing: Behavior: How will it respond in situations nobody has seen yet? Experience: Will this workflow feel natural, confusing, or frustrating? Function: Which features will people actually need once they start? Writing a spec: predicting the product by staring into a crystal ball. No amount of good writing fixes this. Imagination has limits. People don’t know what they want until they see what they don’t want. Yet the spec gets reviewed, approved, and signed off, and the guess gains an authority it never earned. A spec can be perfectly clear, perfectly consistent, and completely wrong. If you’ve ever shipped a feature exactly as specified and watched people ignore it, you already know the problem. Writing a spec: predicting the product by staring into a crystal ball. We get very good at building what we imagined, and never find out what we actually needed. Agile chopped up the spec. It didn’t kill it. Agile admitted part of this problem. But building was still expensive. Three versions of one feature, just to see which felt right? Rarely worth the cost. So the spec survived as user stories, tickets, and acceptance criteria. Agile shortened the distance between guessing and feedback. You still had to guess first. Talk to it instead of meeting about it Say you’re building a customer-support assistant. Should it ask two questions or five? Suggest a fix early, or wait? Will it feel helpful or pushy? Skip the meeting. Generate one and talk to it. The first version asks too many questions, forgets what you told it, and jumps to answers too early. You see all three in minutes, and they produce better requirements than anything you’d write in advance. Real requirements, found in five minutes. You might say AI can write the spec in ten minutes too. It can, but only what you already imagine, and the limit was never typing. A faster spec is still a guess. Illustrative, not measured: where the lines cross, building beats predicting. Meet Hindsight-Driven Development I call this Hindsight-Driven Development. A spec asks you to decide with foresight, before anything exists. This approach lets you decide with hindsight, after you’ve seen the real thing. One pass versus a loop. Start with one sentence of intent. Build a rough version, use it, and keep correcting it until it does what you want. The fastest hindsight comes from a real user, so put the rough version in front of one early. The corrections sound like this: “This workflow is confusing.” “Don’t offer a refund before I’ve finished explaining.” “Show me three different approaches.” Nobody writes “don’t offer a refund before I’ve finished explaining” into a spec. Everyone says it the first time the bot does it. The third one matters most: asking for several approaches early stops you from polishing only the first idea. Predicting what’s right is hard. Recognizing what’s wrong is easy. This approach trades the hard problem for the easy one. “Isn’t this just Agile? Or vibe coding?” Neither. Agile still writes each ticket first. Here, the product writes the next one. And vibe coding accepts whatever the AI produces and moves on. Hindsight-Driven Development questions every result, corrects it, and keeps every correction as a test or a line in the spec. Fred Brooks wrote “plan to throw one away” in 1975, then later called that too simple. His better lesson, from 1986: “grow, not build, software.” Slack began as the in-house chat tool of a team building an online game. The game failed. The tool became the product. The idea is old. What changed is the price. A prototype used to be a project. Now it’s a prompt. “But agents drift without a spec!” They do. But a spec written in advance can’t cover a gap nobody knew was there. Agents drift less from forgetting than from decisions we haven’t made yet. When the agent guesses wrong, you see it the first time you use the product, and the fix costs minutes. That fix then goes into the tests, and the spec the agent reads next time. The spec comes last, not first What’s harmful is the spec written first, from foresight, by people asked to imagine what they can’t yet see. Hindsight-Driven Development flips the order: the spec comes last, from what the team has already seen. Each person corrects the product from their own angle. Only the version you keep goes through code review, and the decisions behind it go into the spec. The ones you throw away cost a few minutes and nothing else. Every checkable correction becomes an automated test, like “it should remember my order number.” A correction like “this feels confusing” stays a note in the spec until someone decides what better looks like. AI merges it all into one readable spec, flags where people disagree, and asks the team to settle it. Nobody writes the spec. Everyone shapes it, and AI keeps it whole. The testable parts stay matched to the product, because a test fails the moment they drift apart. The team aligns around the spec, and the agents read it too, so they stop guessing. Spec-driven development with extra steps? The document may look the same, but here it records what people saw, not what they imagined. And the risks no demo reveals, like security holes or failure under heavy load? You don’t guess those either. You inherit the rules others learned the hard way, and test for them. For everything else, workflows, features, and behavior nobody predicted, you discover it by building. The exception I promised at the start: anything other people build on, like an API another team uses, a customer contract, or anything a regulator requires, is expensive to undo, so agree it up front. That list is short. Most of what a product does sits outside it. Everyone steers AI now handles much of the slow part: writing the code. The bottleneck becomes deciding what to build, and that’s a job for the whole team: product, engineering, and architecture. Three kinds of correction, one shared spec. Even architecture works this way. A good design is never written in one go. It starts rough and gets refined, round after round. Until now, all that refining happened on paper. Now the architect refines the working product itself. Steer toward intent. Let the old spec float away. The scarce skill now is knowing what’s wrong when you see it. The five rules of Hindsight-Driven Development Don’t write the spec first. Grow it from everyone’s corrections. Build before you agree. Debate working versions, not documents. Turn corrections into tests. Fix each thing once. Commit early only to what’s costly to undo. For what no demo shows (security, privacy, load), inherit proven rules and test for them. Clean up what you keep. Kept versions become production code, so review, refactor, and simplify them. We’ve had it backward We spent fifty years getting better at describing software before building it. That made sense when every line took real effort. That’s no longer true. When a working version of a feature costs minutes, a detailed spec written before a single experiment is premature commitment dressed up as diligence. For decades, we built with foresight. Now we can build with hindsight. What’s the biggest thing your spec got wrong that you only saw once the product ran? Tell me in the responses. And if you think I’m wrong, tell me why.