What Actually Breaks in Vibe-Coded Applications

People keep sending me applications built with AI coding tools and asking: “Can you take this to production?”

I’ve reviewed enough of them now to see a clear pattern.

The short answer is usually no. Vibe coding security is almost always the first problem what AI built isn’t ready for real users with real data and real consequences.”

Here’s what specifically goes wrong.

Wiz Research scanned 5,600 applications built with vibe coding tools. They found over 2,000 vulnerabilities and 400 exposed secrets API keys, database credentials, authentication tokens sitting in the code where anyone could find them.

Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code contains vulnerabilities from the OWASP Top 10. These aren’t exotic attack vectors. These are well-documented security flaws that the industry has been warning about for over a decade.

Georgia Tech’s Vibe Security Radar confirmed 74 real-world CVEs specifically from AI-generated code. Thirty-five of those appeared in March 2026 alone more than all of 2025 combined.

Tenzai tested five of the most popular vibe coding tools Claude Code, OpenAI Codex, Cursor, Replit, and Devin by building the same three applications with each. Across 15 applications, they found 69 vulnerabilities. Around half a dozen were rated critical.

These are not theoretical risks. These are measured results from real applications that real people are using right now.

This is the most common pattern I see.

AI tools are good at building a login screen. You type “add authentication” and you get a working login form with email and password. It looks correct. Users can sign up and log in.

But logging in and having the right permissions are two separate things.

Vibe-coded applications routinely check whether a user is logged in but never check whether that user should have access to the specific resource they’re requesting. A logged-in customer can access another customer’s data. A regular user can reach admin endpoints. A user who was just deactivated still has a valid session.

OWASP lists Broken Access Control as the number one web application security risk. AI tools amplify this problem because each prompt produces a slightly different implementation. There’s no consistent permission model across the application just a collection of login checks scattered across endpoints with gaps between them.

When you want to test an API integration quickly, the fastest path is to paste the API key directly into the code. AI tools do this by default because the prompt says “connect to Stripe” and the fastest way to make it work is to put the key right there.

The intention is always to clean it up later. The cleanup rarely happens.

Wiz found 400 exposed secrets across the applications they scanned. GitGuardian’s 2025 report found 23.8 million secrets leaked on public GitHub in 2024, with AI-generated code contributing to the volume.

A leaked API key is a master key. Anyone who finds it can access the service with the same privileges as the owner process payments, read customer data, delete records. Often without anyone noticing until the damage is already done.

Vibe coding treats user inputs as trusted data. A form field is just a form field the AI wires it up so the feature works and moves on.

In production, every input is an attack surface. A text field can carry a script that executes in another user’s browser. A file upload can deliver malicious code disguised as a profile image. A search field can restructure a database query.

AI-generated code is particularly prone to this because the tools optimize for making things work, not for making things safe. The difference between a working feature and a secure feature often comes down to three lines of validation code that the AI didn’t think to add.

This one is worth examining because it shows how all these patterns combine in a real product.

Quittr was a habit-tracking app built with AI coding tools. It reached $1 million in revenue within 10 days of launch. Oprah mentioned it. It had 39,000 users.

Then security researchers discovered that the entire Firebase database was publicly readable. Any user’s personal data was accessible without authentication. Not through a sophisticated attack — just by knowing where to look.

The app worked perfectly from a user’s perspective. It looked professional. People paid for it. And their data was completely exposed the entire time.

This is the pattern: functionally correct, architecturally broken.

When I review a vibe-coded application, I’m looking at five layers that are almost always missing or incomplete:

A consistent permission model not just “is this user logged in” but “what exactly is this user allowed to do, see, and modify.”

Server-side validation — every input checked, sanitized, and rejected if it doesn’t match what’s expected. Not on the client side where it can be bypassed, but on the server where it matters.

Secrets management API keys, database credentials, and tokens stored in environment variables or a secrets manager, never in the codebase. Rotated regularly. Scanned on every commit.

Error handling for real conditions what happens when the database is slow, when an external API times out, when two requests conflict. These aren’t edge cases in production. They’re Tuesday.

Testing not “I clicked through it and it seemed to work” but automated tests that verify the application behaves correctly under unexpected conditions. Without tests, every change to the codebase is a gamble.

None of this is new. These are standard engineering practices that existed long before AI. The difference is that vibe coding produces applications so quickly that these practices get skipped entirely not because developers don’t know better, but because the speed makes it feel unnecessary.

It isn’t.

I use AI in my daily work. Our entire team does. AI makes experienced developers faster at the things they already know how to do well.

But AI doesn’t understand the business context of your application. It doesn’t know that your Swiss clients require specific data residency. It doesn’t know that your payment integration needs to handle CHF, EUR, and GBP with different tax rules. It doesn’t know that your ERP sync needs to run every 15 minutes without blocking the user interface.

These decisions require someone who understands both the technology and the business. AI can write the code once the decision is made. It can’t make the decision.

The applications that work in production are the ones where experienced engineers made the architectural choices, reviewed the AI’s output, and built the safety layers that no prompt will generate automatically.

That’s not a limitation of AI. That’s just how production software works.