Most teams reach for an AI assistant the same way they reach for autocomplete: type a vague prompt, accept whatever comes back, then spend the afternoon repairing it. The problem is rarely the model. It is that nobody wrote down what done means before the work started.
Spec-Driven Development flips the order. Before any code is generated, we write a short specification: the inputs, the outputs, the edge cases, the things explicitly out of scope. It is the same document a careful engineer would want before picking up a ticket — the difference is that we now hand it to the model as well.
The specification does three things. It forces the ambiguity out into the open while it is still cheap to resolve. It gives the assistant enough context to make the boring decisions correctly. And it becomes the checklist the reviewer reads against, which is what makes the review fast instead of exhausting.
This post walks through the template my team uses, the parts that matter most, and the failure modes we hit before we adopted it.