Vibe coding: what it is and the real risks of using it without supervision
It makes it possible to build tools by programming directly with AI, without writing or understanding the code. Suitable for testing an idea, but with real risks in production.
6 min read
In this article
Would anyone get into a brand-new car, built only with artificial intelligence by someone who knows nothing about mechanics, and drive it at 120 km/h on the highway with their family inside?
It would probably start. It might even get there. The problem is everything nobody has checked: what happens when it brakes on a wet road, what the car does when something fails, and who repairs it afterward. The same happens with software made with vibe coding, and that is why it is worth understanding what it is and how far it can go.
What is vibe coding?
Vibe coding is creating an application by asking AI for it in plain language, without reading the code it writes. The user describes what they want, tests the result, and asks for a change when something does not look right. The term was coined by Andrej Karpathy, one of the founders of OpenAI, in February 2025: programming by giving in to the vibes and forgetting that the code even exists!
What vibe coding does well
For testing an idea, it works very well. In a few hours there is something that can be shown, tested, and discussed, when before it took a mockup or several weeks of development. For someone who wants to validate a concept, or for a department that needs to explain what tool it is missing, it is a significant change.
Where vibe coding fails: everything works
Paradoxically, the danger of vibe coding is not that the application does not work. It is that it seems to work, and because it works, no alarm goes off.
When the AI’s suggestions are accepted without being reviewed, elements appear that nobody asked for: a custom-built cache that was not needed, classes full of unused variables, structures far more complicated than necessary. In the demo, everything produces the expected result. The problem comes with everything nobody raised with the AI:
- Edge cases. The customer with no tax ID number, the order for zero units, two people editing the same record at the same time. If nobody has defined them, the application decides on its own how to behave, and nobody knows what it will do.
- Database design. It is the picture of how the project will be able to grow: how the data is organized and what can be built on top of it. If the data model is generated by the AI without enough context, it will soon force a redesign and a data migration with every requested change, which is exactly what should be avoided.
- Security. Who can see what, where passwords and keys are stored, what happens if someone tampers with a request, access limits and lockouts, and data encryption. It does not show in a demo, and vibe coding does not solve it automatically: a developer with good judgment does not leave it to chance.
- Maintenance. When something fails a few months from now, someone will have to understand code that nobody has read, and it may come as a surprise that certain unhandled flows have been causing problems for a long time, problems that are potentially complicated to fix.
Interest in vibe coding is falling as its limits become known
After growing very fast in 2025, searches for the term have started to fall in 2026. With use, it has become clear that vibe coding without programming knowledge works for some tasks, such as a prototype or a personal tool, but does not solve the more complex ones: those that depend on edge cases, data design, or security.
View the data
| Month | English, worldwide |
|---|---|
| Oct 2024 | 70 |
| Nov 2024 | 90 |
| Dec 2024 | 70 |
| Jan 2025 | 110 |
| Feb 2025 | 27,100 |
| Mar 2025 | 550,000 |
| Apr 2025 | 550,000 |
| May 2025 | 550,000 |
| Jun 2025 | 450,000 |
| Jul 2025 | 550,000 |
| Aug 2025 | 450,000 |
| Sep 2025 | 550,000 |
| Oct 2025 | 550,000 |
| Nov 2025 | 550,000 |
| Dec 2025 | 550,000 |
| Jan 2026 | 673,000 |
| Feb 2026 | 673,000 |
| Mar 2026 | 823,000 |
| Apr 2026 | 673,000 |
| May 2026 | 673,000 |
| Jun 2026 | 550,000 |
| Jul 2026 | 450,000 |
| Aug 2026 | 450,000 |
Why the code that AI writes has to be understood
Jordi Gil, founder of Gilsys, explained it with an image in an interview in MetaData: it is like asking AI to write a love letter to someone from Japan and expecting them to fall in love without knowing what we are saying to them. To do it well, you have to understand what the letter says.
The same is true of code. AI can write it, but whoever delivers it and whoever maintains it have to understand it. In the coming years, much less code will be written by hand and much more will have to be read and validated. Writing is what gets delegated. Understanding is not.
Development companies that rely only on AI
Vibe coding makes it easier for new companies with little or no programming experience to sell software development. Their knowledge depends directly on the quality of the AI model they use, and they have no basis for judging whether the AI is doing a good or a bad job: if it suggests code with errors, they are unlikely to detect it.
Before commissioning a tool, it is worth asking who reviews the code generated by the AI and what experience they have.
When vibe coding is useful and when it is not enough
| Useful | Not enough |
|---|---|
| A prototype to validate an idea | A tool the team will use every day |
| A mockup to explain what is needed | An application with customer or employee data |
| A personal tool that can be discarded | Anything that handles money: invoices, payments, or orders |
| A one-off automation, without sensitive data | Anything that connects to the ERP, the CRM, or the website |
The difference comes down to a simple idea: in an exam, 9 out of 10 is an excellent grade; in a company, a tool that does 90% of what it has to do is a failure. And what is missing to reach 100% is exactly what nobody asked the AI for.
How we program with AI at Gilsys
We use AI to program every day, with three rules:
- Judgment and review. What the AI suggests is reviewed, and nothing is accepted without knowing why. Our responsibility for what we deliver is the same as before.
- Tests and documentation. With AI, the automated tests that check that everything still works after each change are no longer an extra, and neither is up-to-date functional documentation: it is what gives the AI context so that it does not break what already works.
- AI where it adds value. Not everything is solved with AI. When the result has to follow fixed rules and always be the same, we program traditional algorithms.
And a prototype made with vibe coding should not be discarded: it is a very good specification of what is wanted. We review it, decide what can be reused and what has to be redone, and turn it into a first phase with a fixed scope and price. If what is needed is to decide which company processes are worth tackling with AI, that is a job for AI consulting; and if the data cannot leave the company, for private AI.
