The hidden risks of vibe coding

Most of the conversation about AI and security runs in one direction: the barrier to entry for attackers is collapsing. A teenager with a chatbot can now scan, probe, and exploit at a level that used to require years of practice. That's a real problem, and it deserves the attention it gets.

But there's a quieter risk that almost nobody is talking about. One that doesn't come from the attacker's side of the keyboard at all. It comes from ours.

Because everyone thinks they're a programmer now.

The English-language programmer

In February 2025, Andrej Karpathy gave a name to something a lot of people were already doing. He called it "vibe coding", describing what you want in plain English and letting the model write the code, leaning on the output and follow-up prompts rather than reading the code yourself. He was honest about the scope: it's great for "throwaway weekend projects" and prototypes.

The term went viral. Merriam-Webster picked it up. Collins named it Word of the Year for 2025. And somewhere along the way, the "throwaway weekend project" caveat got lost.

Now the founder sketches the MVP. The product manager ships the internal tool. And yes, the over-enthusiastic CTO spins up the demo that ends up in front of customers. The code works. It looks real. It feels like engineering. The problem is that "feels like engineering" and "is engineering" are not the same thing, and the gap between them is exactly where the vulnerabilities live.

What we found when we tested our own AI Defender

We ran into this firsthand. While testing our AI-defender, Iceland's first fully automated AI hackbot, we needed demo applications to show it in action. So we built three of them using pure vibe coding. No hand-written code, no manual review. Just prompts.

App #1 - the deliberate one

For the first app, we asked the AI to introduce specific, known vulnerabilities so we'd have something concrete for the defender to catch. Interestingly, the model fought us. It kept refusing on security grounds, over and over, until we framed the request as educational. Then it complied. (Worth noting: that guardrail is doing its job for outright "write me something malicious" prompts. Keep that in mind for what comes next.)

App #2 - the honest one

Then we got curious. What if we didn't ask for vulnerabilities at all? What if we just vibe-coded the way an excited, non-security-minded CTO would "build me an app that does X," ship it, move on? So we did exactly that, in a fresh session with zero shared context with the first app.

The result was the part that actually unsettled us. The "honest" app shipped with just as many serious vulnerabilities as the one where we had explicitly asked for them. Same class of problems. Same severity. The only difference was that with App #1 we had to talk the model into it, and with App #2 we got it for free, simply by not thinking about security, exactly the way most people don't.

App #3 - the confirmation

Skeptical that we'd gotten unlucky, we repeated the experiment on a different platform. Again, no request for vulnerabilities. Just "build the thing." And again it handed us a security hole, this time a NoSQL injection sitting in production-shaped code that looked perfectly fine on the surface.

Three apps, three confirmations. The model that refused to be insecure when asked directly was perfectly happy to be insecure when nobody mentioned security at all.

This isn't just our anecdote

We went looking to see whether our three little experiments were a fluke. They weren't.

• Roughly 45% of AI-generated code introduces an OWASP Top 10 vulnerability, according to Veracode's testing across more than 100 models. The Cloud Security Alliance's own testing landed on a security pass rate of only about 55%, pointing to a similar failure rate.
• Look at whole applications rather than individual snippets and it gets worse: one Q1 2026 analysis found 91.5% of complete vibe-coded apps contained at least one flaw across their components.
• Georgetown's CSET found that 86% of AI-generated code failed to defend against cross-site scripting. A separate CodeRabbit analysis found that AI-written code is roughly 2.74x more likely to introduce an XSS vulnerability than human-written code.
• A large scan by Escape.tech of 5,600 vibe-coded apps surfaced over 2,000 vulnerabilities! including 400+ exposed secrets and 175 instances of leaked personal data.

The pattern is consistent. The model isn't malicious. It's doing what you asked. The trouble is that "what you asked" almost never includes "...and make it secure," because the person prompting doesn't know what to ask for. The guardrail that blocks "write me a SQL injection" does nothing about the SQL injection that simply falls out of "build me a login page", because nobody framed it as a security request. The vulnerability arrives uninvited.

And even if you were to ask for "secure" code. There are no guarantees that secure code is what is delivered.

AI lets us make mistakes faster

Here's the reframe worth holding onto. Vibe coding doesn't make you a worse engineer, it makes you a faster one. And speed is neutral. It accelerates good decisions and bad ones equally.

For an experienced engineer who reads every line, that acceleration is a superpower. For someone who treats the output as a finished product because it compiles and the demo runs, it's a superpower pointed in the wrong direction. AI gives us the ability to make mistakes faster, and it's dangerously easy to lose yourself in the joy of how quickly it all comes together.

There's a grim symmetry to the whole situation. Attackers are using AI to turbocharge how fast they find vulnerabilities. The last thing we should be doing is turbocharging how fast we ship them, handing the other side a bigger, softer target and, in effect, helping them along. The barrier to entry didn't just drop for hackers. It dropped for the people writing the code they'll attack.

So what should the enthusiastic CTO actually do?

Not stop. To be clear: vibe coding is genuinely fantastic. For rapid prototyping, for getting an idea in front of stakeholders, for letting a non-engineer founder demonstrate a vision instead of just describing it. It's one of the best tools we've ever had. Our own demo apps existed because of it.

The line isn't "AI bad." The line is where the prototype stops and the product begins. Before anything touches real users or real data:

• Have experienced engineers vet the final product. Not skim it... read it! The vulnerabilities we found were invisible from the demo and obvious from the code.
• Run rigorous security testing. Static analysis, dependency scanning, secrets detection, and proper penetration testing, the same bar you'd hold human-written code to, because the code doesn't care who, or what, wrote it.
• Treat "the AI wrote it" as a reason for more scrutiny, not less. The model's confidence is not evidence of correctness.

The bright side

None of this is an argument against AI. Quite the opposite. The same technology that quietly slips a NoSQL injection into your demo is also extraordinary at finding that injection when you point it in that direction. AI is an astonishing tool. But it's still a tool, and like every powerful tool before it, it delivers excellent results in the right hands and expensive ones in the wrong grip.

So, is your CTO vibe-coding? Probably. Honestly, they should be. It's a wonderful way to think out loud in code. Just make sure that somewhere between the vibe and the launch, someone who knows exactly what to look for reads the thing.

That's not a limitation of AI. That's how you get the best out of it.

This article was written by Guðmundur Karl Karlsson with AI assistance 

Sources:

Cloud Security Alliance Labs. (2026). AI-generated code vulnerability surge 2026. Cloud Security Alliance Labs. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/

Getautonoma. (2026). Vibe coding security risks. https://getautonoma.com/blog/vibe-coding-security-risks

OX Security. (2026). Vibe coding security. https://www.ox.security/blog/vibe-coding-security/

Simon Willison. (2025, March 19). Vibe coding. Simon Willison’s Weblog. https://simonwillison.net/2025/Mar/19/vibe-coding/

SoftwareSeni. (2026). 91.5% of vibe-coded apps have vulnerabilities: And what the Q1 2026 research actually shows. https://www.softwareseni.com/91-5-percent-of-vibe-coded-apps-have-vulnerabilities-and-what-the-q1-2026-research-actually-shows/

Wikipedia contributors. (n.d.). Vibe coding. In Wikipedia. Retrieved June 24, 2026, from https://en.wikipedia.org/wiki/Vibe_coding