The Hidden Risks of Vibe Coding: Security Holes, Leaked Keys and Code Nobody Can Fix

Let me tell you about the most common phone call of my year. It isn't "can you build this?" anymore. It's a founder, slightly sheepish, saying some version of: "So, I built this app with AI. It works. People are using it. And last week something happened that made me realise I have no idea if it's safe — or what I'd do if it broke."

Nothing about that call embarrasses me, and it shouldn't embarrass them. Vibe coding is a legitimate, powerful way to build — I use these tools daily and offer vibe coding as a service myself. But there's a gap between the marketing ("anyone can build an app!") and the engineering reality, and founders are falling into it at scale. This post is the map of that gap: the real risks of vibe coding, in plain language, roughly in the order they hurt people.

Risk 1: Security holes you can't see

Here's the number that should be printed on every AI coding tool's homepage: in Veracode's 2025 security testing across more than 100 AI models, AI-generated code failed security tests 45% of the time — and when the AI had a choice between a secure approach and an insecure one, it picked the insecure one 45% of the time too. Newer, bigger models were not meaningfully safer.

Why? Because AI is trained to make things work, and security is mostly the art of making things not work for the wrong people. Concretely, the failures I find in AI-built apps, over and over:

• Exposed secrets. API keys, payment credentials and database passwords sitting in the frontend code where any visitor can read them. Gartner's research chief called hard-coded secrets leaking through vibe-coded apps the number-one enterprise risk of the moment. Scan after scan of public vibe-coded apps finds hundreds of live secrets sitting in public repositories.

• Wide-open databases. The access rules that decide who can read what are the first thing AI builders rush. The classic result: any signed-in user can pull every other user's data with a trivially modified request. The app "works" in every demo — and is leaking the whole time.

• Missing input validation. Forms and fields that accept anything, opening the door to cross-site scripting and injection attacks — the exact categories where AI code fails most often in testing.

• Authentication theatre. Login screens that look real but have reset flows, session handling or permission checks a competent attacker walks through in an afternoon.

None of this is visible from the user's chair. That's what makes it dangerous: the app feels finished.

Risk 2: The app works until it doesn't scale

AI tools build for the demo in front of them. They fetch entire tables to display ten rows. They re-render whole pages for a one-word change. They choose the database structure that's easiest today, which becomes a wall when you add the obvious feature next month.

Performance problems are the friendly version of this. The unfriendly version is architectural: when every feature was generated in isolation, the codebase becomes three half-systems wearing a trench coat. Adding user roles, or payments, or a second language suddenly means negotiating with contradictions the AI left across forty files. This is what developers mean by technical debt, and vibe-coded apps accumulate it at AI speed.

Risk 3: Nobody can maintain it — including you

Here's the quiet one. With traditionally written code, somebody understood it once: the developer. With a vibe-coded app, potentially nobody has ever understood it — not you (you never read it) and not the AI (it doesn't retain a model of your whole system between sessions; it re-derives and sometimes contradicts itself).

The practical consequences show up fast:

• A bug appears and every fix breaks something else, because no one knows the dependencies.

• You hire a developer, and their first week is archaeology, not progress.

• The original AI tool changes its pricing or shuts a feature, and you discover how much of "your" product lived inside its platform.

I expand on what happens next — and how a rescue actually works — in how to fix a vibe-coded app and make it production-ready.

Risk 4: Compliance and trust

If your app touches personal data — and in Morocco, Europe or anywhere else, emails and phone numbers are personal data — you have legal obligations around how it's stored and protected. "The AI built it that way" is not a defence your users, partners or regulators accept. One leak from an unreviewed app can end a young company's reputation before its marketing ever gets a chance.

The checklist I run on every AI-built app

When a founder brings me a vibe-coded product, this is the first pass — and it's a decent self-audit if you're technical enough to look:

1. Search the entire codebase and its public repository for keys, tokens and passwords. Rotate anything found.

2. Test the database rules: can user A read user B's records by changing an ID? This one test catches the worst injury.

3. Check authentication properly: password reset, session expiry, and whether admin pages are protected server-side, not just hidden in the menu.

4. Look for duplicated features and dead code — the tell-tale signs the AI rebuilt instead of reused.

5. Run one real load sanity check: a few hundred records in the main tables, then actually use the app.

6. Confirm you can export everything — code and data — into accounts you own.

If you can't run that list yourself, that's normal, and it's exactly the gap my vibe coding audits exist to close: you keep the speed you built with, I find what the AI missed.

So should you stop vibe coding?

No — and I get suspicious of developers who say yes, because it usually means they're defending their rates, not your product. Vibe coding is a superb way to create prototypes, internal tools and first versions. The risk isn't the tool; it's skipping the moment where a professional looks at the result before real users, real money and real data depend on it.

Build with vibes. Launch with verification. That combination is, honestly, the fastest safe way to ship software that has ever existed. If you've built something and want that verification before you scale it, send me the link — the audit is quick, and it's much cheaper than the alternative.