Spec-driven development inverts the usual order of AI-assisted coding. Instead of a prompt producing code that then gets reviewed, a written specification, the requirements, the acceptance criteria, and often a task breakdown, is agreed first, and the code is generated against it as a downstream artifact. Tools like AWS’s Kiro and GitHub’s open-source Spec Kit implement this as a literal pipeline: define the spec, turn it into a plan, break the plan into tasks, then generate implementation.
It matters because most of the rework in AI-assisted coding traces back to ambiguity that only surfaces after code exists, a requirement nobody wrote down, an edge case nobody named. Writing the spec first forces that ambiguity to surface while it’s still cheap to fix, before an agent has committed to one interpretation of a vague ask.
The real test of a spec’s quality: hand it to a different agent, or a different person, and see if it produces the same result. A prompt rarely survives that test. A good spec does, which is the whole point of writing one down instead of just describing it out loud.