From Vibecoding to Spec-Driven Development

You have probably heard about the concept of vibecoding. You take a tool like Claude Code, Codex or OpenCode, or something even easier like Lovable, give it your idea, and in minutes it builds an entire app that works. It’s amazing and everybody is impressed the first time they see it.

And now that you have your app, some of these tools even let you publish it. In a few minutes you have a running app that helps you organise your wedding or a personal task manager that is personalised and powerful.

But.. if I can build a personal tool with vibecoding, I can translate the same concept to work, right? There are so many tasks that could be automated, so many things that could work better.. the possibilities are endless!

And that’s where the problems start. Because.. is this app secure? Is it accessible? We are talking about company data now, not the same league as an app for organising your weekly football matches with your friends.

What is Spec-Driven Development

SDD is a way of working where you first write down what the application has to be and which rules it has to follow, and then the code comes out from that definition.

It is the next step in using AI to build applications, because the bottleneck is no longer the code, it is the definition.

With vibecoding you talk to your agent and the application appears. But you never say everything. You don’t say whether there is a login, or what happens when the form fails. The agent decides all of that for you, and those decisions go straight into the code, where you will not see them.

SDD lets you produce complete specifications that follow your company rules, and then create the code with the right level of security and quality.

The spec becomes the document that stays alive, and the code becomes what derives from it.

But.. how does it work?

There are different tools that help you start working with SDD. I chose Spec Kit, open source from GitHub, which works especially well with new projects. But there are other implementations like OpenSpec that work better with projects that already exist.

After installing it in your project, you will have two folders, one with the slash commands for your agent and the other with the templates and the constitution file.

Now it is time to open a session with your agent and start the magic with these five commands.

1. The constitution (/speckit.constitution)

You tell it your rules in plain language, something like “WCAG 2.1 AA accessibility is mandatory and business logic has to be testable without the interface”.

And notice that you are not inventing any of this. In your company there are already rules that define how to work, and what good code going to production looks like. Architecture has them. Security has them. Accessibility has them. Design has its own system. The usual problem is that they live in different systems and documents.

The constitution is the file where all those layers come together. You write it once, and every project inherits it. The rules stop depending on whether somebody remembers them.

What it writes for you is nothing exotic. It is a text file that looks like this:

### I. Accessibility First (WCAG 2.1 AA)

- Every interactive element MUST have an accessible name.
- Every form control MUST have an associated `<label>`.
  Placeholders MUST NOT be used as labels.
- **Rationale**: an interface nobody can operate with a screen reader is a defect, not a preference.

2. The spec (/speckit.specify)

Give it one sentence with the specification of the application, what it has to do and why, with no technology in it.

The result is a file with everything you said, and, more useful, everything you didn’t:

**FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]

## Assumptions
- Existing authentication system will be reused
- Mobile support is out of scope for v1

So it is telling you two things at once. What it needs from you, and what it decided without you. Both take ten seconds to read, and both are cheap to change now, not when the code already exists.

3. The plan (/speckit.plan)

The spec said nothing about technology. In this step, we will define it: language, frameworks, where the data lives, the test framework, the platform it runs on, etc.

## Technical Context
Language/Version: Python 3.11
Primary Dependencies: FastAPI, SQLAlchemy
Storage: PostgreSQL
Testing: pytest
Target Platform: Linux server

And before moving on, it goes through the constitution rule by rule and checks whether what it just decided complies. If something doesn’t pass, it either gets fixed or it gets written down as an exception with its justification.

4. The tasks (/speckit.tasks)

It splits the plan into an ordered list of tasks, small enough that you can read the list and see what is about to happen before any code is written.

5. The implementation (/speckit.implement)

Finally, it writes code following the constitution, spec, plan and tasks, creating a project that runs with your company rules inside it.

Conclusions

With vibecoding you can get something that works, but with SDD you can get something you can put in front of your company. And it’s even better than before, because your rules now get applied every time you create something instead of depending on who remembered them.

So go and find what those rules actually are, get them out of the PDF nobody opens, and share them. Creating with AI is wonderful, and the whole point is that more people get to do it.

Related reading: what an agent harness is.