/ 8 min read
Destroying vibe coding
Why AI can make developers slower, what happened when an agent wiped a database in nine seconds, and how real work with agents gets done.
On October 2, 2026 I gave the talk Destruyendo el vibe coding (Destroying vibe coding) at Dev Days Caracas, the GitHub gathering at the School of Computer Science of Universidad Central de Venezuela. This article collects what was said there, with the data and its sources, for anyone who was not in the room or wants to check the numbers calmly. The full recording, in Spanish with subtitles, is on YouTube, and the slides are at destruyendo-el-vibe-coding.luisdavidcolina.com.
What vibe coding is
The term was coined by Andrej Karpathy, OpenAI co-founder and former head of AI at Tesla, in a post on February 2, 2025. He described it as giving in to the vibes and forgetting that the code even exists: asking the machine to program and keeping whatever comes out. Relax, let things flow and let the tool do the work. Before the year was over, Collins Dictionary picked it as its word of the year.
Behind the term sits a belief almost everyone shares: that these tools make us program better and, above all, faster. What cannot be seen is what decides the outcome.
The METR study
METR, an organization that evaluates AI models, ran a randomized controlled trial in 2025 with experienced developers working on their own open-source repositories. Each task was randomly assigned to one of two conditions, with or without AI assistance, and the real time was measured. With AI they took 19% longer. And afterwards they estimated they had been 20% faster.
A McKinsey survey of 4,500 developers at 150 companies helps explain the paradox. Assistance cuts the time of routine tasks by 46% and that of complex tasks by less than 10%. The part that speeds up is rarely the part that is hard.
In February 2026 METR published new data, with tools from late 2025. For the developers of the original study the estimate moved to 18% faster, and to 4% for the new participants. METR itself warns that this measurement is unreliable: more and more developers refuse to work without AI, and the time of those who use several agents at once can no longer be measured well with that design. The 2025 lesson still stands. The feeling of speed is not a measurement, and most of us have lost more time fighting the tool over a change we would have made faster by hand.
The PocketOS case
On April 24, 2026, PocketOS, a platform car rental companies use to manage bookings, payments and customers, lost its production database. A coding agent, Cursor running Claude Opus 4.6, was working in a staging environment. It hit a credentials problem and, instead of stopping, looked for a fix on its own. It found a Railway token in the code, meant for minor tasks but with no scope limits. It ran a single command, volumeDelete, and in nine seconds deleted the database along with every backup, which lived on the same volume.
The service was down for 30 hours and three months of bookings and customer records were lost. The case is registered in the OECD AI Incidents Monitor.
What matters is the cause. Nobody asked the agent to delete anything, but it had permission to do it and the key was within reach. AI does in seconds what it should never have been asked to do, and nine seconds are enough to destroy what took years to build.
So is AI the problem?
No. None of the three data points blames the model. They all point at how the work is requested. People who work seriously with these tools are not vibe coding. They program with several agents at once and act as project manager, orchestrator and software engineer. The vibe coder builds a rocket that looks flawless from the outside. It lifts off, and it blows up.
From prompt to brief
The first correction pays off the most. There is a lot of talk about prompt engineering, as if there were a magic phrase. A model rarely fails for lack of capability. It fails for lack of a brief, and a good brief has four parts:
- Context: which files and which conventions the project follows.
- Goal: what has to be true when it is done.
- Limits: what it must not touch.
- Verification: how to check it came out right.
A request like "fix the login" can return twelve files touched and none tested. The same request with context, goal, limits and verification returns one file, the session fixed, the schema intact and the tests green. And the brief is written once: on GitHub it lives in the repository, in .github/copilot-instructions.md, and applies to everyone working there.
How to work with agents
The first tip is the one nobody expects: briefs are dictated, not typed. Spoken, they come out longer and with more context than typed, and context is what decides the outcome. The talk, its slides and this article were directed that way, by microphone.
Three rules are not negotiable. Minimum scope, because no agent works with permissions it does not need. Human review before merging. And small pieces with a written acceptance criterion.
The flow goes from task to pull request. An issue is assigned, the Copilot coding agent works on it in GitHub's infrastructure and returns a pull request, which gets reviewed and approved even from a phone. Each task gets the model it needs, small for routine work and large only when it pays off. And what repeats is saved as a skill, an instruction written once that the agent reuses.
This year's certifications test exactly that. The GitHub Copilot GH-300 exam guide, in its August 7, 2026 version, covers agent mode, sessions with sub-agents, MCP and the CLI. Microsoft's AI-103 covers RAG, orchestrated multi-agent solutions, guardrails and approval workflows.
Several agents on the same project
The usual pattern is to send a request and watch the screen while it answers. That is not working with agents yet. In a management system I built this year, several agents moved forward at the same time on different parts of the project, coordinated by a Kanban board that reached 323 stories. An agent only sees the stories nobody is touching and whose dependencies are done, claims one before writing a line, and the board can refuse it.
Once two agents came in with the same identifier, the board mixed them up and both wrote the same file. A whole task was lost. Since then the board rejects a repeated identifier. Coordinating agents looks a lot like coordinating people. And it is just starting: according to Databricks' State of AI Agents 2026 report, multi-agent workflow usage grew 327% in four months of 2025, and only 19% of organizations have agents in production.
A 2022 project and a 2026 one
AI is not for doing the same things faster. It is for building far more, and that only happens when it is used well.
In 2022 I led a job platform with a team of six developers: six months to get it running and 779 commits. In 2026 I built a management system for swimming schools on my own, coordinating agents: five weeks, from August 19 to September 24, and 1,148 commits. Commit count does not prove a project is complete, and an agent's commit is usually smaller than a hand-written one. What does prove it is that it went live, with six different roles, 22 applied migrations and 92 data isolation checks.
The digital archive of the UCV Faculty of Sciences, which I also built, is designed the opposite way from PocketOS: a fixed spending cap, credentials that never leave the server, and no record changes without a person's approval.
The layers of programming
Every layer of computing raised the level of abstraction: punch cards, assembly, high-level languages, libraries, the cloud and now agents. None of them removed the need to understand the layer below. That is why computer organization courses still teach assembly. The layer below is the real way to find the errors, weaknesses and limits of the layer above. Without it, an agent's mistakes cannot be fully seen, and its work cannot be optimized.
BairesDev's Dev Barometer, published on June 11, 2026 with 1,569 developers from 77 countries, puts a number on it. 85% of juniors say AI improved their understanding of code, and only 16% of seniors think juniors fully understand the code they deliver. AI does not replace those who study. It replaces those who stopped.
And what needs to be studied changes fast. According to the World Economic Forum's Future of Jobs Report 2025, 39% of a worker's current skills will change or become outdated between 2025 and 2030. Almost everything described here may be outdated in a few months, and at the same time new criteria are being born, like orchestrating agents. Whoever is studying today is right on time to master them.
Bringing this into a company
I apply this every day. At Workforce.com, a workforce management platform with more than ten thousand clients, I lead the Latin America integrations: I connect time tracking with point of sale systems like Oracle Simphony and NCR Aloha, with SAP and with ADP payroll. At Diamond Hotel PMS, where I am a partner and technical lead, the hotel management system runs in five countries. In both, AI comes in with the same rules as this article: a controlled budget, per-role permissions and a person who approves before anything is written.
Sources
- METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025.
- METR. We are Changing our Developer Productivity Experiment Design, February 24, 2026.
- McKinsey. Survey of 4,500 developers at 150 companies on the impact of generative AI.
- OECD. AI Incidents Monitor, PocketOS incident, April 27, 2026.
- Hackread. Cursor AI Agent Wipes PocketOS Database and Backups in 9 Seconds, April 2026.
- Databricks. State of AI Agents 2026.
- BairesDev. Dev Barometer, Q2 2026, June 11, 2026.
- World Economic Forum. Future of Jobs Report 2025.
- Microsoft Learn. GH-300 GitHub Copilot exam study guide.
- Microsoft Learn. AI-103 exam study guide.
- Andrej Karpathy. Post on X, February 2, 2025, where the term vibe coding appears.
- Collins English Dictionary. Word of the year 2025.