We spent 2025 celebrating how fast AI could write code. We’re spending 2026 discovering how fast AI can create attack surfaces.

Veracode’s latest State of Software Security report landed this week and the numbers are brutal: 82% of organizations now carry security debt, up significantly from last year. High-risk vulnerabilities jumped from 8.3% to 11.3%. And the throughline connecting all of it? AI-generated code being shipped to production by teams moving too fast to review what they’re deploying.

This isn’t a hypothetical risk anymore. One in five organizations have already suffered a serious security incident directly tied to AI-generated code. The reckoning isn’t coming — it’s here.

The Numbers That Should Scare You

Let’s stop dancing around this:

• 45% of AI-generated code contains security vulnerabilities. Not edge cases. Not theoretical flaws. Actual, exploitable vulnerabilities.
• 86% of the time, AI models fail to generate secure code for Cross-Site Scripting prevention. Eighty-six percent.
• 88% of the time, AI produces code vulnerable to Log Injection attacks.
• By year two of unmanaged AI-generated code, maintenance costs hit 4x traditional levels as technical debt compounds exponentially.
• Teams using AI-heavy workflows report 41% higher code churn — meaning they’re writing more code that gets rewritten or reverted.

These aren’t numbers from AI skeptics. These are from organizations measuring what happens when you ship AI-generated code at scale.

Why AI Code Is Uniquely Dangerous

Traditional technical debt is bad. AI-generated technical debt is worse, for a specific reason: nobody understands it.

When a human writes bad code, at least one person — the author — has a mental model of what it does and why. They might have made poor decisions, but they can explain those decisions. They can trace the logic. They can debug it.

AI-generated code has no author with a mental model. It was produced by a statistical process that optimizes for “looks correct” rather than “is correct.” The code works on the happy path because training data is full of happy paths. The code fails on edge cases because edge cases are, by definition, underrepresented in training data.

And here’s the kicker: the code looks right. It follows conventions. It uses proper naming. It structures things reasonably. So it passes code review — especially the increasingly perfunctory code reviews happening at teams shipping at AI speed.

The Three Failure Modes

1. The Confident Vulnerability

AI models are trained on millions of code examples, including millions of insecure code examples. When you ask for a login form, you get a login form. It probably works. It probably also has XSS vectors, doesn’t properly sanitize inputs, and stores things it shouldn’t in client-accessible state.

The model doesn’t know this is wrong because “wrong” isn’t a concept it operates on. It operates on “statistically likely given the prompt.” Insecure patterns are extremely common in training data, so they’re extremely common in output.

2. The Dependency Hallucination

AI will confidently import packages that don’t exist. This used to be a funny quirk. Now it’s a supply chain attack vector. Malicious actors are registering package names that AI models commonly hallucinate, filling them with malware, and waiting. It’s happening right now. It works because developers trust the AI’s import statements the same way they trust its logic — which is to say, too much.

3. The Compounding Abstraction

AI-generated code tends to be verbose and over-abstracted. Not because it’s trying to be — because training data rewards patterns that look “professional.” So you get factory patterns where a function would do. Service layers that add indirection without value. Abstractions that make the code harder to audit without making it easier to maintain.

Each layer of unnecessary abstraction is another place for vulnerabilities to hide. And when you stack AI-generated abstractions on top of AI-generated abstractions, you get a system that nobody — human or AI — can fully reason about.

What Actually Works

The teams getting this right aren’t avoiding AI-generated code. They’re treating it like what it is: untrusted input.

Treat AI Output Like a Junior Developer’s First PR

Read every line. Question every dependency. Check every input boundary. This sounds obvious. It’s not happening. Gartner says 60% of new code will be AI-generated by end of 2026 — there simply aren’t enough senior engineers to review all of it with the scrutiny it requires.

So you need automation.

Static Analysis Is Non-Negotiable

If you’re generating code with AI and not running SAST on every commit, you’re gambling. Tools like Semgrep, SonarQube, and Snyk aren’t optional anymore — they’re the immune system for AI-assisted development. Run them in CI. Block merges on critical findings. No exceptions.

# This should be in every CI pipeline shipping AI-assisted code
- name: Security scan
  run: |
    semgrep --config auto --error
    npm audit --audit-level=critical
  if: always()

Pin Your Dependencies. All of Them.

Lockfiles aren’t suggestions. Every dependency an AI suggests should be verified: Does it exist? Is it the right package? Is the version current? Is it maintained? This takes thirty seconds per dependency and prevents supply chain attacks that take months to detect.

Write Security Tests Before Generating Code

Here’s a pattern that works: write the security test first, then let the AI generate the implementation. If the AI produces code that fails the security test, you catch it immediately. If you write the test after, you’re testing your assumptions about what the AI generated — which are probably wrong.

// Write this BEFORE letting AI generate the handler
describe('user input handling', () => {
  it('rejects script tags in all text fields', () => {
    const malicious = '<script>alert("xss")</script>';
    expect(sanitize(malicious)).not.toContain('<script>');
  });

  it('parameterizes all database queries', () => {
    const input = "'; DROP TABLE users; --";
    const query = buildQuery(input);
    expect(query.text).toContain('$1');
    expect(query.values).toContain(input);
  });
});

Maintain a Human-Readable Architecture

If you can’t explain your system architecture on a whiteboard in under five minutes, it’s too complex to secure. AI loves generating elaborate architectures. Resist this. Every service boundary is an attack surface. Every API endpoint is an entry point. Simpler systems are more secure systems, full stop.

The Real Problem Is Cultural

The hardest part of this isn’t technical. It’s convincing teams that were just told “AI makes you 10x faster” that they need to slow down.

Nobody wants to be the person who adds friction. Nobody wants to be the security curmudgeon blocking deployments while competitors ship features daily. But the math is straightforward: 45% vulnerability rate × increasing code volume = exponentially increasing attack surface.

The teams that figure out how to move fast and maintain security hygiene will win. The teams that choose speed over security will make the news, and not in the way they wanted.

Where This Goes

We’re at an inflection point. AI-assisted development isn’t going away — nor should it. The productivity gains are real. But so is the security debt, and it’s compounding faster than most organizations realize.

The next twelve months will separate the industry into two camps: teams that built security into their AI-assisted workflows from the start, and teams that are now paying consultants six figures to audit codebases they don’t understand because no human ever wrote them.

The tools exist. The practices are known. The only thing missing is the discipline to use them. And discipline has never been the tech industry’s strongest trait.