Piero Savastano
Vibe Coding vs Spec-Driven Development

Vibe Coding vs Spec-Driven Development

January 12, 2026
6 min read
Table of Contents
index

In my opinion vibe coding was a godsend, because it created a powerful debate between the conservatives of development, who say “no, this is all garbage, you cannot trust it, what even is this stuff, this does not exist,” and, on the other side, all the people who had never programmed and suddenly found a fantastic tool for building prototypes and starting to learn how to code.

And on top of that, something happened: little by little it differentiated. What we called vibe coding a few months ago has become three or four different things.

Vibe coding proper

What people still call vibe coding has, I think, shifted toward those who are not ordinary code writers but could become so. Because with vibe coding you actually learn to program better too, in my opinion. These people take Lovable, Cursor, various tools, to build small prototypes and applications, things they put online. They have fun, they learn, and they get the chance to bring their own ideas down to earth.

I want to stress that this is a huge advantage even for those who have been coding hardcore their whole lives, because you no longer have to sit and listen to some crackpot coming to you saying “ah, I want to build Facebook but I want it blue,” or “I want to build Instagram but only for puppies.” When these people have an idea that makes no sense, now they have already tried it, already brought it down to earth. Or you invite them to: you have an idea? Do not come straight to me, do not go straight to the techies. Now you no longer have the entry barrier of the technician, you have the chance to put your ideas to the test, try them, watch them grow, see whether they make sense, directly with vibe coding. And then you can bring the purely graphic designer and the programmer into the design of the product, because you can collaborate on these vibe-coded objects, since they cost little and allow for a lot of creativity. In my view it is an advantage for everyone. I really believe in this. It brings a lot of people closer to programming, and it saves those who already program from the flood of nonsense spouted by people who have never written a line of code. So I am thrilled.

Enter spec-driven development

Then some sub-branches of vibe coding formed, and they are no longer called vibe coding. In particular I want to flag one for anyone who does not know it yet: spec-driven development. What is it?

The professional programmer looks at vibe coding and says “there is no way I let an agent write all this stuff, and so much of it, and then I have to review all of it. It writes me a heap of junk, the codebase gets too wide, it puts its hands everywhere.” Spec-driven development consists of taking AI agents, in particular the absolute coolest one in use at the moment, which is Claude Code, though you can use others too. There is already an open version called OpenCode, very nice, and various others. In this mode of development you take for granted that the agent’s work must be circumscribed and then reviewed by you. So it is no longer pure vibe coding, it is already restricted, and that should be more palatable for long-time programmers.

And what do you do? In the folder, in the project, you create specially structured files where, by communicating with the agent, you agree on what the features are, which ones should be implemented, in what order, what we are working on right now. Organized as Markdown files inside folders. There are also specs for this. My favorite is called OpenSpec, but there are already several. And a pseudo-standard is emerging out of OpenAI, called agents.md.

In any case, you write directly into the project a tree of folders and Markdown files, and inside these folders sits a kind of shared documentation between the developers and the AI agents they collaborate with. So when you open your editor or your terminal, you enter the project, you talk to Claude, to OpenCode, to whatever it is, and you say “let’s work on this feature, plan this feature, I want this, this, and that.” Once it then writes the Markdown files into the proper folders, at any moment, without rebuilding the context from scratch every single time, you are good. And this was another problem: until a few months ago you always had to rewrite everything, always give it all the details, the style, and so on. Now, by organizing this folder structure, this shared documentation, you open the chat and say “I want to work on this,” and in here it is already written how I want it done. Make me a plan, let’s look at it together, reason it through, and then you unleash it. You unleash the beast only when you are convinced that what is about to be done satisfies you and is circumscribed the way you decided, on the feature you decided, planned the way you decided.

From programmers to managers of agents

And as we have said many times, this is a sign that we are shifting from being programmers toward being more like managers of AI agents. So we should study a bit of what we always criticized in the category of human managers, whom we always, well, looked down on, especially when they did not come from a technical background. Now it is our turn to learn to be managers a little more.

And this is great stuff, because vibe coding, in my opinion, created the debate and created a huge opportunity for people who did not write code, and I am especially happy about that. With spec-driven development and its derivatives, in my opinion, professional programming with agents is opening up. Beautiful, folks.