Vibe Coding Is Eating Software — But Who Audits the Code?

By some estimates, over 10 million applications were shipped using AI coding tools in 2025 alone. Cursor, Lovable, Replit Agent, Bolt, v0 — the tools kept coming and people kept building. Founders who couldn't write a line of JavaScript six months ago now have production apps with paying users.
Here's the dirty secret nobody wants to talk about: the vast majority of that code has never been reviewed by a human who understands what it does.
We solved the building problem. We created a quality crisis.
The Vibe Coding Explosion
If you've been under a rock: "vibe coding" is the practice of describing what you want in natural language and letting an AI write the code. You type a prompt, you get a working app. Sometimes in hours. Sometimes in minutes.
The tooling has gotten absurdly good. Cursor gives you an AI-native IDE. v0 generates full React components from descriptions. Lovable and Bolt let you go from idea to deployed app without touching code at all. Replit Agent will scaffold, build, and deploy your entire project while you watch.
And who's using these tools? Everyone. Non-developers who always had ideas but no way to execute. Indie hackers who want to ship fast. Startup founders who can't afford a dev team yet. Designers who got tired of waiting for engineers. The barriers to building software have essentially collapsed.
The speed is intoxicating. I get it — I've used these tools myself. Going from concept to working prototype in an afternoon feels like a superpower. And that feeling is exactly the problem. Because speed creates confidence, and confidence without verification creates risk.
What I Found When I Looked Under the Hood
I've been writing code for over 25 years. I've worked in enterprise environments — hospitality, finance, large-scale IT operations — where code review wasn't optional and production failures had real consequences. These days I build AI-powered SaaS products. I live in this world.
So I decided to do something simple: I took five vibe-coded applications — real apps, built by real people using popular AI coding tools — and I audited them. Not a deep penetration test. Just a senior engineer spending a few hours looking at each codebase the way I'd review a pull request.
What I found was consistent and alarming.
Hardcoded API keys and secrets. In three out of five apps, I found API keys committed directly in the source code. One had a Stripe secret key sitting in a client-side JavaScript file. That's not a bug — that's an open wallet.
Zero input validation. SQL injection vectors. Cross-site scripting wide open. User input flowing straight into database queries and DOM rendering without any sanitization. The basics. The stuff we solved 20 years ago.
Auth that looks right but isn't. JWTs without expiration. Password reset flows without rate limiting. Session tokens that never rotate. The UI shows a login screen, so it feels secure. It's not.
Dependencies with known CVEs. npm packages with published vulnerabilities, pinned at old versions, never updated. The AI picked whatever version was in its training data. Nobody checked.
No error handling. Happy path only. Every function assumes success. One unexpected input, one network timeout, one malformed response — and the whole thing falls over with a stack trace exposed to the user.
Database queries that don't scale. Queries that work fine with 10 users but do full table scans that'll bring your database to its knees at 1,000. No indexing strategy. No pagination. The AI optimized for "it works on my demo data."
None of this was exotic. This was Security 101 and Performance 101. And it was everywhere.
Why the AI Gets It Wrong
This isn't about AI being stupid. It's about understanding what LLMs actually optimize for.
When you prompt an AI to build you an app, it optimizes for one thing: does it work? Does it compile? Does it render? Does it do the thing the human asked for? That's the objective function, and modern models are extremely good at hitting it.
But "works" and "works safely" are completely different things. Security is the absence of something — the absence of vulnerabilities, the absence of attack vectors. LLMs aren't trained to think about what shouldn't happen. They're trained to produce what should happen.
There's a deeper issue: training data. LLMs learned to code from millions of tutorials, Stack Overflow answers, blog posts, and open-source repos. Tutorials skip security. They skip error handling. They skip edge cases. They show you the fastest path to a working demo. That's what the AI learned, and that's what it reproduces.
The AI also has zero context about your production environment. It doesn't know your threat model. It doesn't know you're handling payment data or health records. It doesn't know your users are in the EU and you're subject to GDPR. It just writes code that does what you asked.
And critically, AI can't think adversarially. It builds for the user, not for the attacker. It doesn't ask "what if someone sends a 10MB payload to this endpoint?" or "what if someone replays this token?" That kind of thinking requires a threat model, and LLMs don't have one.
This creates what I call the "it compiles = it's done" illusion. The app runs. It looks professional. The UI is clean. Everything feels finished. But underneath, it's held together with optimistic assumptions and zero defensive coding.
The Real-World Consequences
This isn't theoretical anymore. We're already seeing the fallout.
DeFi protocols built with AI-assisted code have been exploited for millions. Data leaks from AI-built applications are showing up in breach databases. The Towards Data Science community has published detailed analyses of security debt accumulating in vibe-coded projects — and the numbers are ugly.
Your AI-built MVP just became your AI-built liability.
And here's what really keeps me up at night: the regulatory angle. GDPR doesn't care that you didn't write the code yourself. PCI-DSS doesn't give you a pass because Cursor generated your payment integration. If you're processing personal data or financial transactions, you're responsible for the security of your application. Full stop. Ignorance isn't a defense. "The AI wrote it" isn't a defense.
The first major lawsuit against a company for a breach in AI-generated code is coming. It's not a question of if, it's a question of when.
The Gap in the Market
Enterprise developers have tools for this. Snyk scans your dependencies. SonarQube analyzes code quality. Veracode does application security testing. These are mature, powerful platforms.
They also cost $500+ per month, require complex setup, and assume you have a DevSecOps team to interpret the results. They're built for engineering organizations with security expertise.
Vibe coders have... nothing.
Think about the irony here. The people who need AI code security auditing the most — non-technical builders shipping production code they don't fully understand — are the least equipped to do it. They don't know what to scan for. They don't know how to interpret results. They often don't even have a CI/CD pipeline to plug tools into.
Traditional code review assumes the developer understands their own code. That's the whole point — you wrote it, someone else checks your work. But vibe coders often can't explain what their code does at a technical level. They know what it's supposed to do. They don't know how it does it. That's a fundamentally different review problem.
The 3-Layer Fix
I'm not here to just complain. Here's what you can actually do today, broken into three layers based on effort and impact.
Layer 1 — Pre-commit: The Checklist
Before you deploy anything, run two things:
-
A secrets scanner. Gitleaks or TruffleHog. Free, open-source, takes 5 minutes to set up. These tools scan your codebase for API keys, passwords, tokens — anything that shouldn't be in source code. This alone would have caught the worst issues in my audit.
-
An OWASP Top 10 check. Go through the OWASP Top 10 list and ask your AI tool: "Does my application protect against [each item]?" It's not perfect, but it forces the AI to at least consider security, which it didn't do during initial generation.
Layer 2 — CI/CD: Automated Scanning
Set up a basic pipeline. If you're on GitHub, this is a 15-minute job:
- GitHub Actions with CodeQL for static analysis (free for public repos)
npm auditorpip auditfor dependency vulnerabilities- A basic linter with security rules enabled
This catches roughly 80% of the low-hanging fruit automatically. Every push gets scanned. You don't have to remember. You don't have to be an expert. The pipeline tells you when something's wrong.
Layer 3 — Runtime: Monitor What's Actually Happening
Your app is live. Now watch it.
- Rate limiting. If you don't have it, add it. Every API endpoint. Non-negotiable.
- Error tracking. Sentry has a free tier. You'll see every unhandled exception, every crash, every error your happy-path code didn't account for.
- Uptime and logging. Uptime Kuma is free and self-hosted. Know when your app goes down before your users tell you.
None of this is exotic. None of this requires a security team. It's the minimum viable security stack, and it's achievable for anyone shipping a vibe-coded app.
What I Think Happens Next
Here's my prediction: AI code auditing tools will explode in 2026. We're going to see a wave of products specifically designed to review AI-generated code quality — tools that understand the specific failure modes of LLM-written code and can explain issues in plain language to non-technical builders.
These are the pickaxe sellers of the vibe coding gold rush. And honestly? The market is massive and underserved.
I also think we'll see entirely new concepts emerge. Code insurance — policies that cover you if your AI-built application causes a data breach. AI liability frameworks — legal standards for who's responsible when AI-generated code fails. Maybe even a new job role: the "AI Code Auditor," someone who specializes in reviewing and hardening code they didn't write and the original "developer" can't fully explain.
The builders who learn security fundamentals win. They'll ship faster and more safely. Their products will survive their first real attack. Their companies will survive their first compliance audit.
The rest? They're building on sand. And the tide is coming in.
The Bottom Line
Vibe coding isn't going away. And it shouldn't — the democratization of software development is genuinely exciting. I've been in this industry for 25 years, and I've never seen anything that unlocks creativity and execution like this.
But shipping without auditing is the new technical debt. Except this debt doesn't just slow you down — it exposes your users, your data, and your business to real harm.
The best time to audit your vibe-coded app was before launch. The second best time is now.
Don't know where to start? Run Gitleaks on your repo today. Read the OWASP Top 10. Set up Sentry. These three things take less than an hour and will catch the worst problems.
The tools made building easy. Now we need to make building safely just as easy. Until then, the responsibility is yours.
Mats Sjödin is a software engineer and entrepreneur with 25+ years in IT. He writes about the intersection of AI, security, and pragmatic engineering at matssjodin.com. Connect with him to get a free vibe coding security checklist.