What vibe coding is
The term became popular in 2025 and describes a way of coding where you tell a model what you want, try the result and accept it without reading all the code it wrote. The point is speed: in an afternoon there is something working and demonstrable.
That is not a problem in itself. It becomes one when that code moves from the demo to production without anyone experienced looking at what data it touches, what it leaves open and what happens when a thousand people arrive instead of three.
Is vibe coding good or bad?
Neither: it is a tool, and it depends on the job. For a mock-up, a proof of concept or an internal tool it is about as fast as it gets. For something that stores customer data, takes payments or faces real traffic, that speed turns into risk if nobody reviews what was written.
The upsides are real: an idea is tested in hours, people who do not code can show what they want, and the engineering team starts from something that already works. So are the risks: code nobody fully understands, permissions open by default, dependencies picked at random and errors that stay silent. What happens between the demo and production makes the difference.
Where AI-written code fails
AI writes code that works on the happy path, which is the one the demo tries. What is missing is usually what you cannot see: the check on the value that arrives wrong, the permission nobody reviewed, the query that drags when the table grows and the secret left inside the repository.
It is measured. 45% of AI-generated code in a lab carried known vulnerabilities when it was given no security instructions.
Vibe coding tools and what changes between them
There are two families. Editors and assistants that work inside the code, such as Cursor, GitHub Copilot or Claude Code, and platforms that generate a whole app from a description, such as Lovable, Bolt, Replit or Google AI Studio. The first keep the code in view of an engineering team; the second hide more of it and often publish it on their own.
For a review, the tool changes where you look first, not what has to be checked. On platforms that publish on their own, keys and database permissions come first; in editors, the dependencies and routes that were added without anyone asking for them.
What to review before launch
Six things, in this order: secrets and credentials out of the code; routes and permissions, so nobody sees what is not theirs; personal data, in responses and in logs; performance with the real volume, not with three test rows; dependencies and versions; and what happens when something fails, which is where you see whether the system tells you or stays quiet.
None of the six can be checked by skimming the code: they are measured. That is why a review works and a quick read does not.
How we review it
With AI tools that adapt to your build and look first at the points where we know AI fails, and with an experienced person reviewing every finding. We never leave a tool working on its own: what we hand over carries evidence for each point, with the measurement next to it.
If the build is a website, that review is the website one; if it is an app, the mobile app one; if it is the server side, the backend and API one.