Vibe coding and spec-driven development (SDD) are two ways of building software with AI. In vibe coding you describe what you want in a chat, accept what the model writes and keep prompting until it works. In spec-driven development you first write a specification (what the system must do, how you will know it works, and the rules it must respect), and the AI implements against that spec, which is checked by tests.
The short answer: vibe coding is fine for prototypes and throwaway scripts; anything that will go to production, hold real data or be maintained by a team needs a spec. Below is the side-by-side comparison, how to decide, and how a spec-driven workflow with AI agents runs in practice.
Spec-driven development vs vibe coding at a glance
| Vibe coding | Spec-driven development (SDD) | |
|---|---|---|
| Source of truth | The chat history | A written spec, versioned with the code |
| Starting point | A prompt | Requirements, acceptance criteria and constraints |
| How “done” is decided | It seems to work | Every acceptance criterion is met and the tests pass |
| Speed on day one | Very fast | Slower: the spec takes time to write |
| Speed after a few months | Drops: each change can break something else | Stable: changes start by updating the spec |
| Security | Whatever the model happened to write | Rules written in the spec and checked in review |
| Who can pick the project up | Whoever has the chat history | Anyone who reads the spec |
| Good for | Prototypes, demos, one-off scripts, learning | Production software, client projects, teams |
What vibe coding is
The term comes from Andrej Karpathy, who in a post on 2 February 2025 described coding where you let the model write everything and “forget that the code even exists”. He presented it as a way to build weekend projects, not production systems.
That is exactly where it shines: you get from idea to something clickable in minutes, you can try three approaches in an afternoon, and people without a development background can build small tools for themselves.
The problems appear when that code has to live on:
- Nobody decided the architecture. Each prompt solves the problem in front of it, so the project ends up with several ways of doing the same thing.
- The intent is lost. Why a module works the way it does is somewhere in a chat log, if anywhere.
- Security is left to chance. Code that works can still trust user input, leak data or skip permission checks; the model only fixes what you notice.
- Changes get riskier. Without tests that describe the expected behaviour, every new prompt can break something that was working.
What spec-driven development is
In spec-driven development the specification is the main artifact, not the chat. A useful spec for a feature answers four questions:
- What it does, from the user’s point of view (user stories).
- How we know it works: acceptance criteria that are specific and testable. “Fast” is not a criterion; “the search returns results in under 1 second for 10,000 products” is.
- What can go wrong: edge cases, errors, permissions, empty states.
- What rules it must respect: architecture, technology, security and performance constraints.
A short example of an acceptance criterion block for a contact form:
- A visitor can submit the form without JavaScript enabled.
- Submitting with an invalid email shows an error next to the field and keeps the rest of the data.
- Each submission reaches the CRM and the sales inbox; if the CRM is down, the email still arrives.
- The form rejects more than 5 submissions per minute from the same IP.
With that, the AI agent has a precise target, and a person can review the result against something objective instead of “looks fine”.
Spec coding, SDD and spec-driven development
You will see the same idea called spec coding, SDD or spec-driven development. They refer to the same practice: write the specification first and make it the reference for the AI and for the team. Tools have appeared around it; GitHub’s open-source Spec Kit, for example, organises the work into phases: specify, plan, break into tasks and implement.
When to use each one
Vibe coding is enough when all of these are true:
- It is a prototype, a demo or a script you will throw away.
- It does not handle personal data, payments or credentials.
- Nobody else will have to maintain it.
You need a spec as soon as any of these is true:
- The software goes to production or to a client.
- It handles user data, payments or permissions.
- It has to integrate with other systems (CRM, ERP, payment gateways, APIs).
- More than one person will work on it, or it has to last more than a few weeks.
A sensible way to combine them: use vibe coding to explore and discover what to build, then write the spec and build the real thing from it.
How a spec-driven workflow with AI runs in practice
This is how we work at Omitsis when we build with AI agents:
- Interview and scope. Each delivery phase starts with questions until the scope is unambiguous: what it delivers, for whom, what is out of scope.
- Specifications. Technical requirements, a plain-language version for the client to review, user stories and edge cases.
- One folder per feature. Each feature has its spec with testable acceptance criteria and its test strategy: which tests prove it works and how to run them.
- Plan before code. Before implementing, the agent proposes which files it will touch, the risks and the order; a developer approves it.
- Implementation with tests. The agent implements in small steps and runs the tests after each one. A feature is not done until every test passes and every acceptance criterion is checked.
- Human review. A senior developer reviews the result against the spec, not against their impression.
The spec stays in the repository with the code, so the next person, or the next agent, starts from the same reference.
Who designs the spec: the role of the AI architect
Writing a good spec is not filling in a template. It takes someone who knows how systems fail: where security goes wrong, what breaks when traffic grows, how an integration behaves when the other side is down. That is the job of an AI architect: usually a senior developer who designs how AI fits into the architecture and reviews that the generated code respects it.
Without that experience, a spec-driven process with AI only produces well-documented mistakes faster.
If you want to build software with AI that will still be maintainable in two years, take a look at our AI solutions or tell us about your project.
