Why 45% of AI-Generated Code Fails Security (And Why Vibe Coding Doesn’t Work)

Last Updated on May 3, 2026 by Eytan Bijaoui

Last Tuesday, a founder DM’d me on LinkedIn. He’d built an entire SaaS product in a weekend using Lovable. Full UI, database, auth, payment processing. He was genuinely proud. Forty-eight hours from idea to deployed app.

Founders trying to validate startup idea assumptions against this kind of market shift can start with our complete framework.

I asked him one question: “How many customers have you talked to?”

Silence. Then: “I figured I’d build it first and see if people want it.”

He’d spent 48 hours building. He’d spent zero hours validating. And because building was basically free, he didn’t feel the pain that usually forces founders to stop and ask whether anyone actually needs what they’re making.

This is the vibe coding trap. And it’s spreading fast.

The Numbers Are Genuinely Insane

Let me be clear about something: the vibe coding market is not a hype bubble without substance. These companies have real revenue, real users, and real momentum.

Replit just closed a $400 million Series D at a $9 billion valuation. They tripled their valuation in six months. Eighty-five percent of Fortune 500 companies use the platform. They’re projecting $1 billion in annual recurring revenue by the end of 2026.

Lovable, the Swedish startup founded by Anton Osika, hit $400 million in ARR and is now valued at $6.6 billion. Two hundred thousand new projects are created on their platform every single day. They’ve started hunting for acquisition targets because they have so much cash they don’t know what to do with it.

Cursor, the AI code editor that developers actually love, is reportedly in talks for a funding round that would value it at $50 billion. Up from $29 billion last December. In three months.

Add up Replit, Lovable, Cursor, Bolt, and the dozens of smaller players and you’re looking at somewhere north of $70 billion in combined valuation for companies that essentially let you build software by describing what you want in plain English.

And the user demographics tell the real story. Sixty-three percent of people using vibe coding tools aren’t developers. They’re founders, product managers, designers, marketers, and random people with ideas who never learned to code. We’ve been tracking the rise of one-person startups building products that compete with 500-person companies. Vibe coding is the engine that makes that possible.

So why am I worried?

The Part Nobody Wants to Hear

Here’s where it gets uncomfortable.

Checkmarx, a company that does application security testing, analyzed thousands of AI-generated codebases. What they found should scare every founder who just shipped a vibe-coded MVP: 45% of AI-generated code samples fail security tests. Not minor issues. Critical vulnerabilities from the OWASP Top 10. Cross-site scripting. SQL injection. Authentication bypasses. Nearly half of all vibe-coded applications have exploitable security holes right out of the box.

It gets worse. Code co-authored by generative AI contains approximately 1.7 times more major issues compared to human-written code. Security vulnerabilities specifically are 2.74 times higher. Misconfigurations are 75% more common.

And the maintainability problem is maybe the bigger long-term threat. When you vibe code an app, nobody on your team actually understands what the code is doing. There’s no architecture. There’s no documentation. There’s no consistent naming conventions. There’s just a blob of generated code that works (mostly) and that nobody can debug when it breaks.

Simon Willison, a veteran software developer, compared the risk to the Challenger disaster. Not because every vibe-coded app will explode. But because when you ship code that nobody has reviewed into production, you’re essentially launching a shuttle while ignoring the warning signs because the schedule matters more than the process.

A paper titled “Vibe Coding Kills Open Source,” authored by researchers from several universities in January 2026, argued that the flood of AI-generated code is actively degrading the open-source ecosystem. Repositories filling up with low-quality AI contributions that nobody maintains.

I’m not a technical person. I’ve said many times that I’m probably the least technical person you’ll meet. But I know enough to understand that building something fast and building something right are two completely different skills. And vibe coding is optimized entirely for speed.

The Real Problem Isn’t the Code

But actually, the security stuff isn’t what keeps me up at night about vibe coding. Here’s what does.

Vibe coding removed the last natural friction point in the startup building process. And friction, it turns out, was doing something useful.

When building an MVP took three months and $50,000, founders were forced to think carefully before committing. They’d do customer discovery. They’d validate demand. They’d talk to 20 people and find out whether anyone actually had the problem they were solving. Not because they were disciplined. Because spending $50K on something nobody wants hurts enough to make you pause.

Now building an MVP takes a weekend and costs basically nothing. The economic pain signal is gone. So founders are skipping straight to building. And they’re building at a pace we’ve never seen before.

Two hundred thousand new projects created on Lovable every day. Most of them will never find a single paying customer. Not because the code is bad (although it might be). Because nobody validated whether the problem was real before they started building.

We covered the AI wrapper epidemic a few weeks ago, where 70% of AI startup applications were rejected as wrappers with no real innovation. Vibe coding is turbocharging that exact problem. It’s never been easier to build a thin layer on top of an existing API and call it a startup. And it’s never been easier to fool yourself into thinking you have a product because you have a deployed URL.

The irony is thick. The tool that was supposed to democratize software creation is actually making the oldest startup mistake in the book, building something nobody wants, easier to make than ever before.

Where Vibe Coding Actually Works

OK. I’ve been pretty critical. Let me balance this out because I actually think vibe coding is one of the most important developments in the startup ecosystem in years. The technology isn’t the problem. How founders use it is the problem.

Here’s where vibe coding is genuinely transformative.

Validation prototyping. This is the killer use case that almost nobody talks about. Instead of building one product over three months, a founder can now prototype ten different approaches in ten days. Build a landing page with real functionality. Put it in front of potential customers. See which version gets the most signups or the most engagement. Throw away the nine that don’t work and invest real engineering time into the one that does. That’s not building in the dark. That’s using vibe coding as a search algorithm for product-market fit.

Internal tools and workflows. If you need a dashboard that tracks your sales pipeline, or a tool that lets your team manage customer onboarding, or a simple app that automates a repetitive internal process, vibe coding is perfect. The security requirements are lower (internal use only). The maintenance burden is manageable (small scope). And the cost savings are real.

Smoke tests and demand testing. Build a functional prototype, charge real money for it, see if anyone pays. If 50 people pay $50 in the first week, you’ve validated demand with real revenue. Now go hire an engineer and build it properly. The vibe-coded version was never meant to be the product. It was meant to be the test.

The founders who are using vibe coding well are treating it like a research tool, not a production tool. They’re prototyping, testing, learning, and then building the real thing with proper engineering when they know what “the real thing” actually is.

The Coming Shakeout

I think we’re about 12 to 18 months away from a reckoning in the vibe coding startup space.

Here’s what I expect to happen. A wave of vibe-coded startups that raised seed funding based on impressive demos and fast growth will hit a wall when they try to scale. The code won’t handle 10,000 concurrent users. The security audit required by their first enterprise customer will come back with 47 critical findings. The new engineer they hired will spend three months just understanding the codebase before they can add a single feature.

And some of those startups will fail. Not because the idea was bad. Because the foundation was built to demo, not to scale.

The vibe coding platforms themselves will be fine. Replit at $9 billion, Lovable at $6.6 billion, these are real businesses with real revenue. They make money whether the startups built on their platforms succeed or fail. In the gold rush, the shovel sellers always win.

But founders need to understand something that the vibe coding platforms have no incentive to tell them: the hardest part of building a successful startup was never the code. It was figuring out what to build. And vibe coding doesn’t help with that at all.

What I’d Actually Do

If I were starting a company today (and believe me, the temptation has never been stronger because building has never been easier), here’s how I’d use vibe coding.

Week one: talk to 20 potential customers. No building. No prototyping. Just conversations. Find out what hurts. Find out what they’re currently paying to solve the problem. Find out what language they use to describe the pain.

Week two: vibe code three different solutions. Not one. Three. Based on the three most common pain points from the conversations. Deploy all three. Send them to the people you talked to. See which one gets traction.

Week three: kill two, invest in one. The one that got the most engagement, the most signups, the first paying customer, that’s the one worth building properly. Hire an engineer or a technical co-founder who can rebuild the core with real architecture, real security, and real scalability.

Week four onwards: build the real thing. Use the vibe-coded prototype as a specification, not a foundation. The prototype tells the engineer what the product should do. The engineer builds it in a way that won’t fall over when it scales.

Total time from idea to validated, properly-built MVP: about two months. That’s faster than the old way. But it’s grounded in customer evidence, not in the dopamine hit of watching an AI generate your dream app in 48 hours.

The Fork in the Road

We’re at a fascinating moment. Vibe coding has genuinely changed what’s possible for non-technical founders. A person with an idea and zero coding knowledge can now build a working product in days. That’s real. That matters. That’s going to create companies that couldn’t have existed five years ago.

But it’s also going to destroy companies that mistake speed-of-building for proof-of-value. The founder who DM’d me on Tuesday? He had a beautiful app. Great UI. Smooth onboarding. Integrated payments. Everything a demo investor wants to see.

What he didn’t have was a single conversation with a potential customer. And no amount of AI-generated code can fix that.