What Is Vibe Coding, and Why Do AI-Built Apps Break in Production?
Vibe coding gets a first version built fast, but the trouble starts on launch day. The latest AI code security data, common failures, and a pre-production checklist.
- vibe coding
- AI generated code
- code security
- production readiness

Building a first version of a product used to take weeks. Now you can describe what you want to an AI tool and have something clickable by evening. This is vibe coding: you describe the goal, the model writes the code, and you mostly look at the result rather than the code itself.
For testing an idea, it is excellent. The trouble starts when real users, real money, or real data arrive.
What the security data says
Veracode regularly runs AI models through a fixed set of security tests. According to its Fall 2026 update:
- The average security pass rate rose from 56% to 62%, so about 4 in 10 tasks still contain a vulnerability.
- The best models reach 73%, which means they still fail more than one task in four.
- Most of the gain came from cross-site scripting, yet its average is still only 18%. Log injection stays near 12.6%.
- The benchmark does not cover third-party dependencies, so real risk can be higher.
Veracode sells security scanning, so read these numbers with that in mind.
Georgia Tech’s Vibe Security Radar traces published vulnerabilities back to AI tools. As reported by the Cloud Security Alliance, the count grew from 6 in January 2026 to 35 in March, and the researchers consider the real number several times higher.
Writing faster is not shipping faster
In a TechRadar opinion piece, Undo CTO Greg Law says 79% of engineering leaders report no faster release cycles. His company sells debugging tools, but the point holds: the bottleneck has moved from writing code to understanding and fixing it.
What usually breaks
- Authorization: login works, but changing an ID in the URL shows another user’s data.
- Secrets: API keys sit in client code or in the Git history.
- Payments: a bank timeout or a double click creates a duplicate order, or money with no order. In payments, the failure path matters more than the happy path.
- Rate limits: with no limits, one bot can run up your SMS or API bill.
- Concurrency: it works with one user, but stock goes negative with a hundred.
- Backups and migrations: schema changes cannot be reversed, and a restore has never been tested.
- Monitoring: the first alert is an angry customer.
A pre-production checklist
- Move all secrets out of the code and rotate anything exposed.
- Check on every API route that the current user may access that specific record.
- Run security, dependency, and secret scans on every commit.
- Confirm every suggested package really exists. Models sometimes invent package names.
- Add rate limits to login, payment, and SMS endpoints.
- Deliberately test failures: dropped networks, double clicks, and silent external services.
- Actually restore a backup once.
- Set up error reporting and alerts.
- Require human review for authentication, payments, and sensitive data.
So is vibe coding bad?
No. For prototypes, small internal tools, and testing ideas, it saves a great deal of time. But a prototype is not a product.
AI has shortened the road to a first version. Responsibility for what ships still belongs to people.
A sensible path is to build fast with AI, test with real users, and have an engineer review the code before money or sensitive data enters the system.
If you have built something with AI and want it reviewed before launch or growth, send me the code or a brief. I focus on backends and payment systems, and you can see my projects. If you are handing over a project from scratch, read the guide to outsourcing a software project.