AI web development · Glossary
Spec-driven development
Last updated June 29, 2026 · by Tal Gerafi
Spec-driven development is an AI coding practice where you write and approve a short specification before any code is generated, so the artifact you review is the plan — not a large diff after the fact.
Spec-driven development flips the review point. Instead of generating code and then trying to review a large diff, you write a short spec — what to build, why, and the constraints — get it approved, and only then let the agent build against it.
How it works
The spec is the contract. It names the goal, the files in scope, the acceptance criteria, and anything out of scope. Because it's short, a human can actually read and correct it. The coding agent then executes the approved plan, and review at the end is a check against the spec rather than an attempt to reverse-engineer hundreds of lines of intent.
Why it matters for B2B sites
On production work, the expensive failure is building the wrong thing well. A wrong direction caught at the spec stage costs a sentence; caught after the build it costs a rewrite. That's why studios default to spec-driven development for client sites and reserve vibe coding for throwaway prototypes.
Spec-driven development vs. vibe coding
| Spec-driven development | Vibe coding | |
|---|---|---|
| You review | The plan, before code exists | The diff, after the fact |
| Best for | Production, client work, anything maintained | Prototypes, throwaways, exploration |
| Failure mode | Over-planning a trivial change | Confident, wrong code nobody caught |
| Speed on a real feature | Faster overall — less rework | Slower — rework piles up |
The two are not enemies; they are tools for different stakes. Use spec-driven development when being wrong is expensive, and vibe coding when it is cheap.
FAQ
Is spec-driven development only for AI coding?
No — writing a short spec before building is an old engineering habit. It matters more with AI agents because they generate large diffs fast, so reviewing a plan first is far cheaper than reviewing the code after.
How long should the spec be?
Short enough that a human will actually read it — usually a paragraph or a brief bulleted list covering the goal, the files in scope, and the acceptance criteria. If the spec is as long as the code, it is too long.
Greeto's loop puts the spec before the build every time — see Building websites with Claude Code.