Spec-Driven Development, and Why I Build That Way
Writing the spec before the code sounds slow. With AI in the loop it is the opposite: the spec is what makes fast building not turn into fast mess.
Writing a spec before writing code has a reputation for being slow and corporate, the thing you skip when you actually want to ship. That reputation was earned in a world where a human wrote every line and the spec went stale before the feature was done. That world is gone. With AI doing a large share of the typing, the spec is the highest-leverage thing you write, because it is now the actual input to the machine that builds.
The bottleneck moved
When a person writes all the code, the slow part is the typing, and the spec feels like overhead on top of it. When AI writes a large share of the code, the typing is cheap and the thinking is the bottleneck. The scarce thing is a clear, correct description of what should exist. That description is the spec. Skipping it does not make you faster now. It makes you generate a large amount of confident, wrong code very quickly.
A spec is a decision you only make once
The reason I write the spec first is not process for its own sake. It is that a decision captured in a spec is a decision I do not have to re-make every time I touch the code. What are the acceptance criteria, what is out of scope, what does done mean. Answer that once, clearly, and both I and the AI build against the same target. Answer it never, and every session re-litigates the same questions and drifts. This is the same "do the durable thing once" logic behind the compounding foundation under all my ventures.
It only works if the spec is the source of truth
The trap is writing a spec and then ignoring it. A spec that the code has quietly drifted away from is worse than none, because it lies. So the rule is simple: the spec leads, the code follows, and when reality changes you change the spec first. That discipline is what keeps fast building from turning into fast mess, which is the whole difference I wrote about in from demo to shippable.
This is the model Bootspring is built around: plan first, spec the work, then let the AI build against acceptance criteria instead of vibes. It is also how I ship across a portfolio without the whole thing collapsing into chaos, which I get into in what AI-assisted development should mean.
If your AI-assisted builds keep producing plausible code that solves the wrong problem, the fix is almost never a better model. It is a better spec.