“Vibe coding” became a label for iterating with AI almost on autopilot: describe the mood, accept the diff, move on. Spec-Driven Development (SDD) sounds like the opposite, formal, slow. In practice, both can use the same editor and model; the contrast is the mental contract with code that lands in the repository.

Editorial diagram: SDD anchors review; vibe coding tends to skip steps.

1. Two modes, same tool

Vibe coding prioritizes flow and the feeling of progress: chained prompts, visual tweaks, “worked on my machine”. SDD prioritizes traceability: problem, scope, acceptance criteria, and limits before, or alongside , assisted generation.

Neither is “without AI”. The difference is whether the AI gets verifiable context or only a fuzzy wish.

2. What SDD requires

A useful spec can fit on one page: user, expected behavior, out of scope, technical constraints. The agent (or dev) implements against it; review asks “does it meet the spec?” instead of “looks ok?”.

SDD does not remove creativity, it bounds where creativity is welcome (UX, algorithms) and where it is dangerous (permissions, billing, persistence). Specs also feed tests and minimal product documentation.

3. What vibe coding optimizes

Exploration: validate color, layout, unknown APIs, disposable spikes. Setup cost is low; feedback is immediate. For personal prototypes or concept demos, that is a feature, not a bug.

Trouble starts when the spike becomes production without a contract, especially in shared codebases where nobody knows which parts to trust.

4. Compared risks

Vibe coding accumulates invisible debt: inconsistent names, dead paths, hidden dependencies, missing tests. Bad SDD accumulates visible debt: stale specs, empty bureaucracy. The worst SDD is theater; the worst vibe coding is software nobody dares touch.

Human review is mandatory in both modes. SDD only works if someone updates the spec when reality changes; vibe coding only works in production if someone turns exploration into explicit decisions before merge.

5. When to use each

Use vibe coding (with planned discard) to learn, mock, test UI hypotheses. Use SDD when code must survive another developer, audits, integration, or long maintenance, typical of real products such as desktop utilities or flows with sensitive data.

A common hybrid flow: vibe in discovery, short spec before the PR, AI for boilerplate, review against the spec. The goal is not to moralize speed, it is to consciously choose what deserves to stay.