AI rarely writes the "wrong" code on purpose. More often, it writes perfectly reasonable code for an underspecified request.
Spec-Driven Development, or SDD, addresses that problem. Instead of starting with "build this feature," the team starts with a reviewable specification.A prompt is not a specificationImagine asking an AI agent to "add password recovery."That's enough to generate an endpoint, a form, and an email. But what happens when the account doesn't exist? How long is the link valid? Can it be reused? What stops abuse?If the requirements don't answer those questions, the model will. Its assumptions may look convincing while still violating product or security rules.With SDD, the request becomes a contract: the response must not reveal whether an email is registered; the link expires after 15 minutes and works once; a new request invalidates earlier tokens; each account and IP gets five requests per hour; the event is recorded without the token.Now the AI isn't guessing the behavior. It's implementing it.
What the workflow looks like
GitHub's Spec Kit summarizes the process as Spec → Plan → Tasks → Implement.First, the team defines user scenarios, constraints, and acceptance criteria. The AI then proposes components, data models, API contracts, and tests. That plan becomes small, verifiable tasks. Code generation starts only after people review the intent and approach.Each stage produces a Markdown artifact for the repository. Decisions no longer disappear into chat history, and another session or agent can use the same context. Spec Kit supports more than 30 agent integrations, so the workflow is not tied to one model or IDE.
Where the savings come from
SDD adds time before the first line of code is written. That's also when change is cheapest.Finding a missing scenario in spec.md means editing a few sentences. After implementation, it may mean changing the API, database, UI, tests, and an open pull request.The useful metric isn't lines generated. It's how much ambiguity the team removed, and how many requirements can be verified through tests.
The specification does not replace engineering judgment
A bad specification only helps you build the wrong system faster. Someone still needs to ask uncomfortable questions, challenge architectural choices, and decide which trade-offs are acceptable.SDD changes the AI's role. It stops improvising and starts implementing an explicit, reviewable intent. For production software, that's worth far more than an impressive one-shot demo.