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.<\/p>\n\n\n\n
The blame lies (partly) on a tweet<\/h2>\n\n\n\n
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\u2014Karpathy 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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\u2014the kind our elementary school teacher would have ripped to pieces in front of the class\u2014but the model, trained on trillions of parameters, understands and interprets everything correctly.<\/p>\n\n\n\n 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. 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 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).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n 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. 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The difference is best seen with a concrete example.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n With a minimal spec, the same problem is solved in a fraction of the time:<\/p>\n\n\n If a test highlights a missing detail\u2014such as date serialization in the server’s time zone instead of UTC\u2014the 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-articolo-2-1024x572.jpg\")
<\/figure>\n\n\n\nThe myth of zero-to-prod<\/h2>\n\n\n\n
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.<\/p>\n\n\n\nArray.shuffle()<\/code> 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.<\/p>\n\n\n\nHorse, rider, and harness<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-articolo-3-1024x572.jpg\")
<\/figure>\n\n\n\nThe prompt must not make the AI guess what you want. The spec must tell it exactly what to execute.<\/code><\/span><\/pre>\n\n\nWriting a contract the AI cannot misunderstand<\/h2>\n\n\n\n
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:<\/p>\n\n\n## OBJECTIVE<\/span>\nWhat the system must do<\/span>: one clear line\n\n## NON-GOALS<\/span>\nWhat it must NOT do<\/span> (refresh token, OAuth, unapproved libraries...)\n\n## CONSTRAINTS<\/span>\nStack, allowed libraries, expected performance\n\n## EXPECTED OUTPUT<\/span>\n- [ ] Verifiable success criterion 1<\/span>\n- [ ] Verifiable success criterion 2<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nA real case: from two hours of chaos to half an hour<\/h2>\n\n\n\n
## PROBLEM<\/span>\nAPI \/v2\/orders returns 500<\/span> after PHP 8.1<\/span> upgrade\n\n## CONTEXT<\/span>\nError: [specific log] | File: OrderController.php:45<\/span>-67<\/span>\n\n## OBJECTIVE<\/span>\nFix while<\/span> maintaining backward compatibility with v1 client\n\n## DO NOT TOUCH<\/span>\nsrc\/Models\/* | migration files\n\n## VALIDATION\n- [ ] Test suite passes\n- [ ] v1 API continues to work<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nWhen the approach is not needed<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/24-SpecDrivenDevelopment-infografica-1024x572.jpg\")
<\/figure>\n\n\n\n