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 (2)
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.
Well put — the upstream-fix framing is the part that actually changes behavior, because it tells you where to look when something's off instead of just debugging the output.
One thing I'd add: the artifact only survives if the team treats the spec as the source of truth and keeps it in sync, not as scaffolding you discard once the code compiles. The failure mode I've seen is the spec quietly going stale while the code moves on — then the "shared artifact" becomes a liability instead of something the next engineer can trust enough to challenge. The explicit checkpoints help, but the discipline of updating upstream when reality shifts is what keeps the whole loop honest.