Vibe coding vs. SDD (Spec Driven Development): two ways of working with AI

Since code assistants based on language models became part of daily work, two very different ways of using them have emerged. One consists of asking, looking at the result, adjusting, and asking again: it is fast, fun, and very useful for exploring. The other consists of first writing precisely what the system should do, and only then generating or implementing the code. The first is known as vibe coding; the second, as SDD (Spec Driven Development).

The discussion is usually framed as a fight: is vibe coding the end of rigor, or is SDD an elegant way to slow the team down? Neither stance helps. They are approaches with different costs and benefits, and the right decision depends on the type of problem, how long the code will live, and who will pay the consequences if something fails.

What vibe coding is, in practice

Vibe coding is a short cycle of conversation with the tool: an intention is described in natural language, the assistant proposes code, it is run, the behavior is observed, and corrections are made on the fly. The acceptance criterion is immediate and sensory: it works or it doesn't work, it looks good or it doesn't look good.

Its great advantage is the speed of learning. It makes it possible to have something running in minutes, test an idea before committing to an architecture, and discover requirements that no one had thought of until seeing the first version. For prototypes, proofs of concept, one-off internal tools, or automation scripts, it is hard to beat.

Its limits appear when the code has to last. In a purely conversational flow, decisions are easily lost: why a certain structure was chosen, what edge cases were considered, what was deliberately left out. The result is a system that works today and that no one can explain tomorrow, with dependencies that accumulate without review and tests that are written afterward, if they are written at all.

What SDD is and why it puts the specification back at the center

Spec-driven development reverses the order. Before writing code, a specification is drafted: what problem is solved, what inputs and outputs exist, what business rules apply, what behaviors are mandatory, and what is explicitly out of scope. That specification is the contract, and the code—written by hand or generated with the help of an assistant—is an implementation of that contract.

The novelty is that, with language models capable of reading an extensive document, the specification stops being a formality and becomes an operational tool: it is given to the assistant as context, and from it, drafts of implementation, tests, and documentation are generated. The document becomes the source of truth, and the code, a reviewable consequence.

The cost is obvious: writing a good specification takes time and requires thinking before typing. That effort pays off when the project is large, when several people are involved, when there are regulatory requirements, or when the system will be maintained for years.

The differences that really matter

Beyond the anecdote, the two approaches diverge along concrete axes:

• Starting point. In vibe coding, you start from a vague intention and refine it with the result in view. In SDD, you start from a written agreement and work down to the implementation.
• Success criterion. In vibe coding, the criterion is the demonstration: it is seen working. In SDD, the criterion is compliance with the specification, verifiable with tests.
• Change management. In vibe coding, change is cheap at first and expensive later, because no one knows what broke. In SDD, change is negotiated in the document and then propagated.
• Traceability. In SDD, each requirement can be traced to its implementation and its test. In vibe coding, that chain usually does not exist.
• Code review. In vibe coding, you review a diff that appeared all at once. In SDD, you review an implementation against a contract known in advance.
• Team knowledge. In vibe coding, knowledge stays in the head of whoever talked to the assistant. In SDD, it stays in a document that anyone can read.

Common mistakes when adopting either one

On the vibe coding side, the most frequent mistake is not setting limits. You start with a prototype and, without any explicit decision, that prototype ends up in production serving real users. It is also common to accept code that no one understands because it "works," and to discover months later that it includes unnecessary dependencies or assumptions that no longer hold.

On the SDD side, the risk is the opposite: turning the specification into an end in itself. Extremely long documents that no one reads, approvals that take longer than the implementation, and a sense of bureaucracy that pushes the team back to shortcuts. A useful specification is the shortest one that eliminates ambiguity, not the most complete possible one.

There is a third mistake, perhaps the most costly: choosing the approach because it is trendy. Applying SDD to a one-afternoon script is wasteful; doing vibe coding on the module that handles billing is a bet that rarely turns out well.

How to combine them without breaking the project

In practice, the teams that coexist best with these tools do not choose a side: they use a graduated approach based on risk and the useful life of the code.

• Explore with vibe coding. When it is still not clear what is to be built, it is best to prototype quickly, without commitment, on a separate branch and with the explicit expectation of throwing that code away.
• Set the specification before consolidating. When the idea matures, write what the system should do and what it should not. That document is the starting point for the version that will actually be maintained.
• Generate and review against the contract. With the specification as context, the implementation is produced and reviewed requirement by requirement, not just "by eye."
• Automate verification. Each rule in the specification should have at least one test covering it. Without that, the document is a promise without backing.
• Keep a record of decisions. Decisions that are not in the specification or in the code are lost. Writing them down costs little and saves repeated discussions.

A simple criterion for deciding: if the code will live longer than it took to write, or if an error would have consequences for third parties, the specification is advisable. If it is disposable and the goal is to learn, free conversation is advisable.

Closing

Vibe coding and SDD are not competing for the same place. One is an exploration tool; the other, a control mechanism for systems that matter. The problem is not using assistants to write code, but doing so without first deciding how much rigor the project needs. The useful question is not "which is better?" but "what happens if this fails and who is going to maintain it?" The answer to that question points the way.