10KB
Spec Driven Development — Chapter-02: 0 - Why SDD is essential in the age of AI
- Source: /library/Spec Driven Development/source-file.pdf
- PDF pages: 13–19
- Pages without text: none
0 - Why SDD is essential in the age of AI You open your editor, describe in a single sentence what you need, and seconds later an artificial intelligence hands back code that compiles, runs, and even looks well made. A scene that would have been science fiction a few years ago is now routine. And it carries an uncomfortable, honest question, the one that may have brought you here: if the machine already builds this well, why would it still be worth my time to understand what is being built and to describe it carefully before asking? It is a fair question, and AI deserves the credit: for a good share of everyday tasks, it writes quality code in seconds. But there is a more useful question than “does AI program better than I do?": what separates the people who use these tools to build solid things from the people who just paste back answers they don't understand? Whoever improvises loose requests to an AI, with no method and no clear description of what they want, is doing what is usually called vibe-coding: programming by feel, on a vibe, hoping the result will do. This material is the answer to that improvisation, and by the end of the chapter I hope you walk away convinced, not by me, but by yourself. The thesis: knowledge and specification are leverage
Before any “how” we need the “why,” and it fits into a single idea, the thread running through everything that follows: Knowledge is leverage. Understanding what you want and knowing how to describe it does not compete with artificial intelligence: it multiplies what you can do with it. A lever amplifies the strength you already have. Someone with no strength to apply lifts nothing, no matter how good the lever. It is the same with AI. It amplifies whoever hands it a clear statement of the problem and exposes whoever throws only vague phrases at it. For the person who understands what they are building and can specify, that is, say precisely what they want and why, AI is a multiplier: it delivers drafts in seconds and takes the tedium out of repetitive code. For the person who neither understands nor describes, it becomes a factory of code that looks right and nobody can judge. Common sense says: “if AI does it, I don't need to get involved.” The thesis of this material flips that: precisely because AI does it, specifying well matters more. When producing code stops being the bottleneck, the value shifts to what typing never solved on its own: knowing what to build, judging whether it is right, choosing between paths, and answering for the result. The three arguments: judge, decide, answer The thesis sounds nice, but it has to hold up. Here are three concrete reasons, from the most decisive to the broadest, why understanding remains the leverage even when AI does the manual labor.
First, someone has to judge what the machine produced. AI generates plausible code, and plausible is a dangerous word. Almost always what it writes is correct. The problem lives in the minority: the passage that compiles, passes the obvious test, and breaks silently in some rare case nobody thought to check, like a permission flaw where one user sees data that isn't theirs. Who spots that subtle defect? Only someone who knows what the code was supposed to do, and that comes from having specified the expected behavior beforehand. Without a clear specification in your head or on paper, judging becomes hoping the AI got it right. Second, someone has to decide what to build and why. AI implements what you ask, but what to ask, and why that way, is still yours. Does this screen need to work without internet? Is it worth the complexity of syncing data, or does the problem not justify it? AI suggests competent options, but it doesn't carry the context of your product, your users, your budget, what will hurt to maintain two years from now. Deciding is the very act of specifying: asking for the right thing is worth more than quickly receiving the wrong one. Third, responsibility can't be delegated. When the system goes live, the authorship is yours. If data leaks or the cloud bill explodes, there is no “the AI that wrote it.” And it is impossible to answer for something you don't understand. Owning the result means being able to explain why the system is the way it is, and that only exists when there was recorded intent, a specification, rather than a pile of improvised requests. Judge, decide, and answer: AI does none of the three for you, and specification helps you master all of them. The 70% and the 30%
If you already use AI to program, you may recognize a scene like this. You ask for a feature, say a screen that lists items, filters by status, and updates when something changes. In seconds a huge, impressive answer comes back. The structure is there, the names make sense, much of it simply works. Those are the 70%: the predictable work that has shown up thousands of times in thousands of similar projects. AI is extraordinary at that 70%, and it is good that it is. That is your time coming back into your pocket. But then the 30% begins. The list works with ten items and chokes on ten thousand. The filter ignores a status that only exists in your product. The real-time update works online and vanishes at the first dead spot in the signal. None of that 30% is about typing more code. It is about judgment: noticing what is missing, understanding why it fails, and deciding how to fix it without knocking over the rest. And there is a cruel trap: whoever can't do the 30% also can't tell it is missing. They accept the 70% as if it were 100%, ship it, and discover the hole when a user falls into it. The 70% is speed. The 30% is value, and the value lives in knowing, before you ask, what actually needs to exist. What SDD is, in plain language The method that captures this value has a name: SDD, short for Spec-Driven Development. The idea is simple: you describe clearly what you want, the problem, the rules, what counts as correct, before you ask for the code. The specification becomes the starting point, and the code comes afterward, to fulfill it. Think about building a house. Nobody hands bricks to the bricklayer and says start. First comes the blueprint: where the walls go, how many rooms, where the water runs. The blueprint
is the specification; the build is the code. With the blueprint in hand, you can check whether the wall came out in the right place. Without it, you only find the mistake once the wall is already standing. SDD is drawing the blueprint before raising the building. Why is this essential now? Because the age of AI made the build cheap and made the missing blueprint expensive. Without a specification, vibe-coding's improvisation produces two concrete problems. The first is expensive, unproductive prompts: you describe it badly, get back something crooked, and describe it again, fighting the machine more than calm thinking would have cost. The second is undecipherable code: AI delivers a lot, fast, and you pile up a system nobody understands or can maintain. The more AI produces, the more dangerous it is not to know what to ask for. That first problem has a technical root that explains why improvising comes out expensive. AI processes text in tokens (pieces of words, the unit it reads, generates, and charges for) and keeps no memory of its own between one request and the next. Everything it needs to know about your task has to fit into the context: the window of text that comes back with each interaction. In vibe-coding, that context is the entire conversation, and it only grows. With each new prompt, the AI rereads an ever-larger history to guess what you want, burns more tokens on that rework, and loses precision as the conversation drags on. With SDD, the reference stops being the chat and becomes the specification: a short, stable document. The AI runs against that clear contract instead of reassembling your intent from a long conversation, which costs fewer tokens and produces less rework. SDD is the discipline that keeps the tiller in your hand.
SDD is not exactly new A dose of honesty against the hype: specifying before building was not invented just now. The software industry spent decades experimenting with ways to do it, from waterfall (which wrote the whole specification at the start and only built afterward) to agile (which delivers in short cycles, adjusting the route at every step). Each of those schools got something right and stumbled on something, and SDD inherits the lessons of both. Chapter 1 tells that story properly; for now, it is enough to know that the missing piece for combining the best of both sides was the cost of rewriting, and it was exactly that cost that AI knocked down. For those coming from the agile world: SDD does not replace your sprint. The specification becomes a living artifact, revised each cycle, and AI is what makes the rewrite cheap enough for that to be worth it. The next step If the thesis made sense, you already have the essentials: in the age of AI, the bottleneck stopped being producing code and became knowing what to ask for and judging what comes back. One reasonable suspicion remains: isn't specifying before building the old way of making software, the one the world spent years trying to abandon? Chapter 1 answers by showing where SDD comes from, what lesson each methodology left behind, and what changed for this old idea to come back into play without the cost that used to sink it.
A confession before we go on: this material was written using SDD. Every chapter began from a specification before the first sentence, the way to keep cohesion, not forget details, and check at every step whether it still made sense. What you read is human text, written by me, grounded in facts; the specification served as scaffolding. The method here is the same one you will apply to software: the blueprint in hand before raising the wall, whether the build is a system or a text.