Your app was generated in an afternoon. Here is what will break

Generating an application and running one are two different jobs. The first was democratised in two years. The second was not. That gap is the whole distance between « it works » and « it holds ».

The term vibe coding was coined by Andrej Karpathy on 2 February 2025: describing what you want in natural language, accepting the generated code without reading it closely, and fixing problems with follow-up prompts rather than by reasoning through the code. It was not meant as criticism. It became a mass practice, and the consequences are now measurable.

What the published measurements say

Veracode's 2025 GenAI Code Security Report found that 45% of AI-generated code samples contained at least one OWASP Top 10 vulnerability when reviewed without human oversight. That last condition matters: the measurement covers code accepted as-is, which is precisely the definition of vibe coding.

Research published by the Cloud Security Alliance labs on deployed applications reports exposed secrets and high-impact vulnerabilities at scale. This is not lab work. It is live code, used by real people.

The six failures we find almost every time

1. API keys in the repository. Public repositories are scanned continuously by bots, and a key pushed once stays in the history even after you delete the file. Treat it as compromised: rotate it, do not just remove it.
2. No automated tests. Without them, nobody knows what breaks when a line changes. This is what produces the application nobody dares touch.
3. No cost ceiling per request. Specific to apps calling a model. Without a cap per request, per user and per month, a runaway loop turns into an end-of-month invoice.
4. No failure recovery. What happens when the model errors, the database stops answering, the provider slows down? Usually nothing is planned. Those three are normal operating conditions, not rare events.
5. No logs, no alerts. The classic symptom: you learn about the outage from a customer. Often this brick is missing entirely.
6. Backups never restored. A backup you have never restored is a hypothesis, not a backup. Test the restore in real conditions at least once.

The order to fix them in

Fixing everything at once is the surest way to ship nothing. The order that works follows how irreversible the damage is: secrets first, because an exposed key may be in use right now. Then backups, because everything else becomes recoverable once you can roll back. Then cost ceilings, then tests on the paths that touch money and personal data, then logs and alerts, then failure recovery.

Got an application that needs to survive production?

Request an audit