At the last event I spoke at, I asked the audience to raise their hands three times: those who have ever tried vibe coding, those who have generated an entire project fueled by prompts and coffee, and those who eventually threw it all away and rewrote it from scratch. The hands went up almost in unison, and almost always, it was the exact same people all three times.
Dejected faces, almost resigned to having to rewrite something that seemed perfect after the first few days of development. It seemed, indeed.
The reality, however, is very different from the one told through clickbait titles and online banter. The truth is that leaving an AI ungoverned is like giving a marker to a toddler and leaving the room, convinced that the piece of paper you gave them will be used to create a masterpiece rather than a handful of confetti, which is what will actually happen.
The blame lies (partly) on a tweet
If you are looking for a culprit, the most cited name is Andrej Karpathy. Co-founder of OpenAI, former head of Autopilot at Tesla, and now at Anthropic—Karpathy is someone who knows a thing or two about language models. In January 2023, he tweeted that “the hottest new programming language is English”. The tweet reached millions of views and triggered apocalyptic headlines for software developers. Two years later, he doubled down and coined the term “vibe coding”: you accept everything the AI generates, you don’t read the diffs anymore, you paste errors without commenting on them, and you request random changes until the bug disappears. He said it with a smile, referring to weekend throwaway projects, but half of the Internet took it as a serious working methodology.
This approach brings to mind a famous line by Italian director Nanni Moretti in “Ecce Bombo”: “faccio cose, vedo gente” (“I do things, I see people”). It seems very productive, until someone asks you what you have actually built.
Then there is what we might call the “Next, Next, Next laziness”: how much pleasure do you get when you install software by clicking “Next” repeatedly, without having to answer any questions? In vibe coding, the same thing happens: we write a poorly written prompt—the kind our elementary school teacher would have ripped to pieces in front of the class—but the model, trained on trillions of parameters, understands and interprets everything correctly.
The myth of zero-to-prod
Vibe coding works beautifully in online demos, where the AI behaves like a senior fullstack developer capable of solving everything in five minutes. The problem arises when you apply it to a real company’s legacy management software: a hundred thousand lines of code written by people who have since changed jobs.
In that context, the AI stops looking like a senior dev and starts resembling an hyperactive intern on their first day of free coffee: the one who, panicking, tries to fix bugs by commenting out random lines of code just to show you that “it compiles”. And you are left staring at the screen, wondering why you accepted that pull request.
The reason is technical and has a precise name: context rot. The more tokens enter the context window, the less reliable the model’s response becomes. As the chat grows longer, the system forgets the decisions made at the beginning and ignores the constraints established ten messages before. How many times did you feel like punching the monitor when the model, for the nth time, started including that library you had explicitly told it not to include, or got fixated on creating variables in camelCase when the entire program is written in snake_case? Without a spec anchoring the conversation, you aren’t optimizing anything: you are simply losing context with every exchange.
The practical effect is a spaghetti code born from different chat sessions: three distinct conversations produce three different ways of handling errors within the same project, and no one remembers which one is the “right” one anymore.
The worst problem, however, is not the obvious error that stands out immediately. It is the plausible hallucination: code that looks correct, passes a superficial review, and hides a subtle bug. The example I use most often is a fictional native Array.shuffle() in JavaScript, which simply does not exist. The generated code invokes it with such natural confidence that your instinct is to to nod, think “ah, finally they standardized it,” and let it pass because “after all, it’s an edge case.” Then, production goes down.
Horse, rider, and harness
The thesis I brought to the stage is not that vibe coding is dead: it is dead as a unique approach. There is a way to turn the AI from an unpredictable assistant into a governable executor, and it’s called Spec-Driven Development (SDD).
The metaphor of harness engineering illustrates the concept better than any formal definition: AI projects fail in production due to a lack of infrastructure surrounding the model, not because of the model itself.
The language model is like a fast, powerful horse that doesn’t know where to go on its own. The harness represents the set of constraints, guardrails, and feedback loops that direct that energy in a controlled way. In this scenario, the developer is the rider: providing the direction and validating the path, without having to hold the reins at every single step.
Spec-Driven Development is a methodology where specifications assume the role of first-class executable artifacts. The flow is reversed: you write the contract first, and then let the AI generate the code respecting it. The most effective synthesis is encapsulated in this principle:
The prompt must not make the AI guess what you want. The spec must tell it exactly what to execute.Writing a contract the AI cannot misunderstand
The instruction “I want a secure login” might be enough for an experienced developer who has faced the problem a thousand times and knows the company standards.
For an AI agent, however, it is not enough. Without details, it will fill the gaps with assumptions, and the hypotheses of a language model are statistically plausible, but not necessarily correct. The skeleton of a structured spec I adopt for any complex task is essential, fits in a few Markdown lines, and is enough to eliminate most of the ambiguity:
## OBJECTIVE
What the system must do: one clear line
## NON-GOALS
What it must NOT do (refresh token, OAuth, unapproved libraries...)
## CONSTRAINTS
Stack, allowed libraries, expected performance
## EXPECTED OUTPUT
- [ ] Verifiable success criterion 1
- [ ] Verifiable success criterion 2Code language: PHP (php)You don’t need proprietary tools: Markdown is easily readable by the team and represents, at the same time, the mother tongue of Large Language Models. If you want to eliminate natural language ambiguities altogether, you can use EARS (Easy Approach to Requirements Syntax), a rigorous notation created by Alistair Mavin at Rolls-Royce in 2009 for jet engine requirements. Patterns like “WHEN [event] THE system shall [action]” map every decision to a logical constraint that can be tested automatically.
Although it was not born for artificial intelligence, this syntax neutralizes the main weakness of autonomous agents. A solution designed to prevent misunderstandings between humans turned out to be ideal for regulating communication between developers and machines.
A real case: from two hours of chaos to half an hour
The difference is best seen with a concrete example.
Imagine a PHP API that stops working after upgrading to PHP 8.1. In vibe coding mode, the workflow quickly degenerates: you write “it’s not working anymore”, the model suggests a patch, you reply “it’s still not working”, the system generates a second version that breaks another component, and finally a third version that goes back to the first with a new bug. The tally? Two hours lost, wasted resources, and no clear record of what actually changed.
With a minimal spec, the same problem is solved in a fraction of the time:
## PROBLEM
API /v2/orders returns 500 after PHP 8.1 upgrade
## CONTEXT
Error: [specific log] | File: OrderController.php:45-67
## OBJECTIVE
Fix while maintaining backward compatibility with v1 client
## DO NOT TOUCH
src/Models/* | migration files
## VALIDATION
- [ ] Test suite passes
- [ ] v1 API continues to workCode language: PHP (php)If a test highlights a missing detail—such as date serialization in the server’s time zone instead of UTC—the solution does not consist in arguing in chat. You update the spec by adding the explicit constraint on the time zone and rerun the task. This way, the knowledge remains formalized and tracked on Git, available to anyone who needs to modify that code in the future, instead of being forgotten in a chat history that no one will ever reopen.
The gap between documentation and source code has always been a primary cause of bugs and regressions. Spec-Driven Development solves this problem at its root, turning the spec into an indissoluble contract that guides the code’s evolution.
When the approach is not needed
It would be naive to present SDD as a cost-free solution. Writing a fifteen-minute spec for a bug that can be fixed in two minutes is bureaucracy, not engineering: for elementary tasks, vibe coding remains the most logical option. Moreover, specs are code in all respects and require maintenance. If the software evolves through manual hotfixes while the contract remains obsolete, the spec transforms from a source of truth into a source of lies. A constant alignment process is necessary: you cannot just write the document once and forget about it.
There is also a more subtle risk: an extremely precise but incorrect spec will produce, with deterministic rigor, the wrong software. The requirements document must be validated with the same care reserved for code, as it does not constitute an automatic safe conduct.
Code is a side effect
The true value of Spec-Driven Development emerges in medium-to-long term projects or those developed in teams: in these scenarios, the benefits materialize after a few days, with a reduction in iterations and unexpected issues.
This is a cultural revolution: source code shifts from being the primary product of work to the role of a simple compilation artifact.
The spec becomes the real asset. Today, knowing how to write it in a clear, verifiable, and unambiguous way represents the real competitive advantage for those who want to govern AI instead of being subjected to it.
If you too have clicked “Accept” after endless chat sessions that had melted your cerebral cortex, just to finish the job and go home, approving a PR with the solemn promise “I’ll review it on Monday”; if you too are part of this club, SDD won’t magically solve all your problems, but it will drastically reduce the number of coffees you have to buy your colleagues for losing the race of the code with fewer errors.
