The problem with vibe coding
Left to infer intent from a casual prompt, an agent guesses: it invents an API, picks a data shape you didn't want, skips the edge case you cared about. Each guess is small. Over a feature they compound into drift — because intent was never written anywhere you could check against.
What SDD does
Write a structured spec first, then let the agent implement against it through a loop:
SPECIFY -> spec.md what + acceptance [review]
PLAN -> plan.md architecture + risks [review]
TASKS -> tasks.md atomic, ordered [review]
IMPLEMENT -> code task by task, vs spec
Fixes flow upstream: wrong intent → spec, wrong architecture → plan, wrong expression → code.
The core trade-off
Vibe coding optimises for speed; SDD optimises for intent. Neither is always right.
If the intent matters beyond the next prompt, structure wins.
Throwaway script? Vibe away. Production feature a colleague will build on? Write the spec.
Why it caught on
SDD emerged in 2025 and within a year every major AI coding ecosystem shipped its own version. When every vendor independently lands on the same four phases, the pain was real.
Free cheat sheet: the whole method on a few pages — the loop, spec anatomy, EARS, right-sizing — SDD Cheat Sheet.
Go deeper: the full reference — every phase, the tool landscape, three walkthroughs — Spec-Driven Development: The Complete Guide.
How many times have you re-explained the same requirement to an agent in one session? 👇
Top comments (1)
The upstream-fix framing is the useful part here: wrong intent belongs in the spec, wrong architecture in the plan, and wrong expression in code. I also like the SPECIFY -> PLAN -> TASKS -> IMPLEMENT loop because it makes review checkpoints explicit before the agent has already scattered assumptions through a feature. For founders, the real win is not just better code generation; it is turning product intent into a shared artifact that survives beyond one chat session and gives the next engineer something concrete to challenge.