AI Is Writing Your Code. Who Is Checking Its Security?

Roughly 44% of AI code-generation tasks now introduce a risky security vulnerability, and the average security pass rate across major models sits at just 56%, barely moved from the year before. Meanwhile, 75% of developers believe AI-written code is more secure than what they'd write themselves, and nearly 4 in 10 accept AI suggestions without reviewing them at all. That gap, between how safe AI-generated code actually is and how safe developers believe it to be, is quietly becoming one of the largest unmanaged risks in software development.

AI-generated code security isn't a future problem to plan for. It's a present one, already sitting in production, and most organizations don't yet have a clear answer to the question in this post's title.

1. The "False Sense of Security" Problem

This isn't just a story about AI models writing flawed code; humans have always written flawed code too. What's different is a documented behavioral shift in how developers treat code once an AI wrote it. A widely cited Stanford-affiliated study on AI-assisted programming found that developers using AI coding assistants wrote measurably less secure code than those coding without assistance, and, more strikingly, rated their own insecure output as more secure than it actually was.

That combination is what makes AI-generated code security different from ordinary code review. It's not just that vulnerabilities slip in. It's that the people responsible for catching them are, on average, less suspicious of AI-authored code than they would be of a colleague's pull request, even though the evidence points the opposite direction.

2. Why AI-Generated Code Fails Security Reviews So Often

A few consistent patterns show up across the research on this:

• Models optimize for "it works," not "it's safe." An AI assistant is typically trained to produce code that passes tests and satisfies the prompt, not code that resists misuse. A login function that authenticates correctly can still be missing rate limiting, proper session handling, or input sanitization, and still look completely correct to both the model and a quick human skim.

• Defensive programming gets dropped first. Independent research comparing AI-generated code to human-written equivalents has found AI output consistently lacks defensive programming constructs, boundary checks, error handling, and validation that don't affect whether a demo works, but absolutely affect whether production code is safe.

• Memory-unsafe languages fare worse. Early empirical studies of AI code generation found vulnerability rates in C code roughly 50%, compared to around 39% in Python, a gap that's persisted across newer research even as models have improved.

• Iteration doesn't reliably fix this. Asking an AI model to "fix the bug" or refine its own output doesn't consistently improve security, and some research on iterative AI code generation has documented cases where repeated refinement actually degrades security over successive passes, rather than converging toward a safer result.

Why Traditional Review Processes Aren't Catching This

If this were simply "AI writes some bad code," normal code review would catch most of it. It isn't working that way because of volume and trust, not the review process itself. AI-assisted development is increasing how much code gets written and merged per developer, while the instinct to scrutinize that code hasn't kept pace. The same research showing 39% of developers accept AI suggestions without review also shows the speed of AI-assisted development is a big part of the appeal, which cuts directly against the slower, more deliberate scrutiny that security-critical code actually needs.

There's a telling secondary finding in recent application security research: developers overwhelmingly want AI to help with actual fixes and automated scanning, but trust in AI's own security judgment is low, with well under 10% rating it a "must-have" capability. In other words, developers already suspect AI isn't a reliable judge of its own code's security. The gap is that this suspicion isn't yet translating into changed review behavior.

3. Who Should Actually Be Checking AI-Generated Code

The honest answer is: the same people who should have been checking human-written code all along, but held to a higher standard of scrutiny specifically because AI-authored code is statistically more likely to contain a flaw, not less.

That means a few concrete shifts, not just a policy memo:

1. Flag AI-authored diffs distinctly in review, so reviewers apply extra scrutiny rather than treating AI-generated pull requests like routine, low-risk changes.

2. Keep automated scanning in the loop, but as a floor, not a substitute: static analysis and dependency scanning catch known patterns; they don't catch a subtly broken authorization check that "works" in every test case.

3. Verify that reviewers actually have the skill to catch what AI misses. This is the step most teams skip. A reviewer who can't independently spot a broken access control check in human-written code isn't going to catch it in AI-written code either. The model doesn't create a new category of vulnerability; it just produces the familiar ones more often, and more confidently.

4. Track vulnerability introduction rate by source, not just in aggregate. If AI-authored code is consistently producing more findings per pull request than human-authored code in your own pipeline, that's a concrete, measurable signal, not an assumption.

The Underlying Skill Gap This Exposes

Most of this comes back to a question organizations have generally underinvested in answering: can the developers reviewing code, AI-written or otherwise, actually recognize a vulnerability when they see one, under realistic conditions? Awareness training tells a developer that broken access control exists as a category. It doesn't verify whether they'd catch an actual instance of it in a real, unlabeled pull request.

That distinction matters more now than it did two years ago, precisely because the volume of code needing that judgment has grown faster than most teams' verified security skill has. Platforms like Simulations Labs approach this by putting developers into live, hands-on environments- real vulnerable applications to find and fix, not quizzes about vulnerability definitions- specifically because that's the skill AI-generated code now demands more of, not less.

This is exactly the gap Simulations Labs' Web Security challenges close, putting developers into on-demand, live environments where finding and fixing a vulnerability is the actual test, not a proxy measured by quiz completion.