So, there is a fairly significant body of research that has been building on this topic over the past year or so, and I think it’s worth actually putting some of it in front of founders who are building with AI tools right now, because most of it never seems to make it past the security community.

Here is what the research is actually saying about AI-generated code, in plain terms, because I genuinely think these points matter a lot more than most people realize.

1. It learned security from the internet, which is not exactly a great teacher

This one is worth understanding properly because it explains most of what follows. AI coding tools generate code by learning from publicly available code repositories, Stack Overflow answers, tutorials, blog posts and so on. The problem is that a significant portion of that training data contains insecure code, and the model learns both the secure and insecure patterns equally well without any meaningful way to distinguish between them.

Veracode tested over 100 large language models on security-sensitive coding tasks and found that 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities, and that pass rate has not meaningfully improved across multiple testing cycles from 2025 through early 2026, despite what vendors tend to claim. Newer model releases from Anthropic, Google, and others between July and October 2025 showed no meaningful security improvements either. The training data problem just doesn’t go away by scaling the model up.

And beyond that, there’s also the scale problem: a human developer might copy a vulnerable pattern once. An AI tool can reproduce that same flawed pattern across dozens of files in a single session.

2. It makes you more confident while quietly making things less secure

This is the one I find most interesting from a psychological standpoint, honestly. Stanford researchers found that developers who used AI coding assistants produced significantly less secure code than those who wrote it by hand, which on its own is concerning enough. But the more important finding was that the AI-assisted developers were also considerably more confident in the security of their code, despite it being measurably worse. The tools essentially created a false sense of safety.

This tracks with what I see in practice consistently. The code looks complete, it’s well-structured, it passes basic tests, it runs without errors, and so the assumption tends to be that it’s fine all around. That assumption is where a lot of the damage gets done, because 58% of developers report trusting AI-generated outputs without any security testing at all.

The confidence the tool gives you is not calibrated to the actual security of what it built. That gap is worth being very aware of.

3. It ships you 4x the velocity and 10x the security debt simultaneously

Research across Fortune 50 enterprises found that AI-assisted developers produce commits at three to four times the rate of their peers, which is the part that gets marketed heavily. The part that gets talked about considerably less is that those same developers introduce security findings at ten times the rate, creating a security debt that accumulates faster than most organizations can realistically remediate.

To put some numbers to this: CVSS 7.0+ vulnerabilities (so, the serious ones) show up 2.5 times more often in AI-generated code compared to human-written code. By June 2025, AI-generated code was adding over 10,000 new security findings per month across studied repositories, which is a 10x increase from just December 2024. Georgia Tech’s Vibe Security Radar tracked 35 CVEs in March 2026 alone directly attributable to AI coding tools, up from 6 in January of the same year, and researchers there estimate the true count is five to ten times higher across the broader open source ecosystem.

So yes, you shipped faster. The question is what you shipped alongside it.

4. Its vulnerabilities are structural, not accidental

This is a genuinely important distinction that I think gets lost in a lot of the conversation around this. Most people assume that security vulnerabilities in AI-generated code are one-off mistakes, the same kind of thing any developer might produce on a bad day. But a meaningful portion of them are structural, meaning they are baked into the template or pattern the AI defaulted to, and so they show up identically across every app that used the same tool.

CVE-2025-48757 is a good example of this. It exposed a systemic flaw in Lovable specifically where the platform had been generating Supabase database schemas without Row Level Security policies as a default output. This meant that any authenticated user could read, modify, or delete data belonging to any other user on the platform. Over 170 production applications were affected, and the vulnerability was not in any one of those apps individually. It was in the template that all of them inherited from the same generation pattern.

As one Georgia Tech researcher put it: “when an agent builds something without authentication, that’s not a typo. It’s a design flaw baked in from the start.” That’s a meaningfully different kind of problem to the ones most founders are thinking about.

5. Its dependency choices are expanding your attack surface without telling you

When AI tools generate your codebase they pull in third party packages and dependencies to make things work, and 62% of developers report relying on AI suggestions for dependency selection without independently verifying them. The problem here is that AI tools rarely validate package authenticity, which increases exposure to typosquatting attacks (where a malicious package is named almost identically to a legitimate one), and they frequently recommend packages with unpatched CVEs in them.

Supply chain attacks grew by 40% year over year in 2025, and insecure dependencies now account for over 70% of application vulnerabilities in modern apps according to the same research. AI-assisted development also tends to increase what researchers call dependency sprawl, meaning the total number of third party packages in your codebase, by somewhere between 20 and 30% compared to human-written equivalents. More dependencies means more surface area that needs to be tracked, updated, and audited, and most founders are not doing any of that.

The AI picked those packages on your behalf. It did not vet them, and it did not tell you that it hadn’t.

None of this is an argument against building with AI tools, by the way. The productivity gains are real and the barrier to entry being lower is genuinely a good thing for a lot of people. But the security debt that comes alongside it is also real, and the research is pretty clear that it’s not something that is going to fix itself as models get better.

For a hands-on checklist that turns these research patterns into launch checks, use the 30-minute AI app security checklist, and compare it with the AI-built SaaS audit that exposed hardcoded backend keys.