0000 · 0000

Dappasol / Guides

Updated June 2026

Why Does AI Write Insecure Code?

AI models are trained to produce code that works and looks plausible, not code that is secure. They learned from public repos full of insecure patterns, they optimize for the next likely token, and they have no concept of your threat model. So roughly 45% of AI-generated code ships with a vulnerability.

This is where a lot of founders get burned. The AI writes a feature, the demo runs, it all looks professional, and shipping feels safe. But “it runs” and “it’s secure” are answers to two different questions, and the model is only answering the first one. Veracode’s 2025 GenAI Code Security Report tested AI output across languages and found that 45% of code samples failed security tests and introduced an OWASP Top 10 vulnerability. Here is exactly why that happens, and what it means before you put an AI-built app in front of real users.

The 3 reasons AI writes insecure code

Insecure AI code is not a bug you can prompt your way out of. It comes straight from how these models are built and what they are rewarded for. Three forces stack on top of each other.

  1. It was trained on insecure public code. Models learn from massive piles of public repos, tutorials, and forum answers. A huge chunk of that code was never meant to go to production: it skips validation, hardcodes secrets, and turns off protections to “just make it work.” The model soaks up those patterns as normal, because in its training data they are normal.
  2. It optimizes for plausibility, not safety. Under the hood, a language model predicts the next likely token given everything before it. The goal is output that looks right and resembles what usually comes next. Secure code and insecure code can look nearly identical on the surface, so the model has no built-in reason to pick the safe one. It goes with whatever is statistically common, and common is rarely the hardened option.
  3. It has no awareness of your threat model. Security is contextual: who is allowed to read this record, what happens if a user tampers with this ID, where untrusted input enters your system. The model does not know your data model, your users, or your attack surface. It cannot reason about an attacker it was never told exists, so the exact decisions that matter most for security are the ones it leaves unmade.

Why newer and smarter models did NOT fix it

The obvious hope is that bigger, newer models just grow out of this. They have not. Veracode’s report is blunt: as models got better at writing functional, syntactically correct code, they were no better at writing secure code. Security performance stayed flat no matter the model size or training sophistication.

That is the part to sit with. Functional accuracy and security are not the same skill, and getting better at one does not drag the other along. A newer model gives you a slicker, more complete feature that is just as likely to ship a vulnerability. In Veracode’s testing, AI tools failed to defend against cross-site scripting in 86% of relevant samples. Waiting for the next model release is not a security strategy.

The overconfidence trap

It gets worse, because AI also changes the developer’s own judgment. A Stanford study (Perry, Srivastava, Kumar, and Boneh) ran the first large-scale user study on this and found that developers who used an AI assistant wrote significantly less secure code than those without one, and yet were more likely to believe their code was secure.

That pairing is the dangerous bit. Less-secure output plus more confidence means the people most likely to skip an audit are exactly the ones who need one. The study found a tell too: developers who stayed skeptical of the AI and reworked their prompts produced fewer vulnerabilities. Treat AI output as a confident first draft, not a finished answer. That posture is what keeps you safe.

What this means for your launch

None of this makes AI coding tools useless. They are genuinely fast and great for getting to a working prototype. It just means you cannot treat “the AI built it and it works” as “it is safe to launch.” What that looks like in practice:

If you want the deeper background on the specific risks, see our guide on AI-generated code security risks. When you are ready to check your own app, follow our walkthrough on how to audit AI-generated code for security, and to see where the flaws cluster, our breakdown of the OWASP Top 10 in vibe-coded apps.

Want us to run this audit for you?

We do a free 15-minute build audit: you show us your AI-built app, we tell you the specific security and production gaps and what it takes to fix them. No obligation.

Book your free build audit

FAQ

Why does AI write insecure code?

Because models are trained to produce code that works and looks plausible, not code that is secure. They learned from public repos full of insecure patterns, they optimize for the next likely token, and they have no concept of your threat model. The result: about 45% of AI-generated code ships with a vulnerability.

Do newer or smarter AI models write more secure code?

No. Veracode's 2025 testing found that as models got better at writing functional, syntactically correct code, their security performance stayed flat regardless of model size or sophistication. A newer model gives you a more complete feature that is just as likely to contain a vulnerability.

Are developers using AI aware their code is less secure?

Usually not. A Stanford study found developers using an AI assistant wrote significantly less secure code while being more confident it was secure. That overconfidence is exactly why an AI-built app needs a deliberate security review before launch.

Can I still launch an app built with AI coding tools?

Yes, after a security audit. AI tools are great for fast prototypes, but treat the output as a confident first draft. Have a human review access control, secrets, payment logic, and input handling before you put it in front of real users.

Book a free 15-min build audit →