AI tools now write a significant portion of production code at most tech companies — estimates range from 30% to more than 60% depending on the team. The security research that followed is sobering: AI-generated code fails at certain vulnerability classes at rates that should change how you do code review.
The Numbers Don't Lie
A landmark 2022 study from Stanford found that GitHub Copilot-assisted code contained security bugs about 40% of the time when given security-sensitive prompts — and crucially, developers with AI assistance were more confident that their insecure code was correct than those without it. This "confidence gap" has only widened as AI tools became more capable and usage exploded. When a model writes code confidently and quickly, it's psychologically harder for a reviewer to push back.
The vulnerability patterns aren't random. Security researchers have identified a consistent fingerprint in AI-generated code: models tend to handle user-input validation inconsistently, rely on deprecated cryptographic primitives they've seen frequently in training data, and generate SQL queries or shell commands that skip parameterization in subtle edge cases. CWE-89 (SQL injection), CWE-798 (hardcoded credentials), and CWE-22 (path traversal) all appear disproportionately in AI-heavy codebases.
Why AI Code Is Different to Review
Human-written code has tells. A developer's style, their approach to abstractions, the way they name variables — these leave clues that help reviewers build a mental model of what was intended. AI-generated code is stylistically uniform but semantically noisy. It looks right. It compiles, the tests pass (especially when the AI also wrote the tests), and the logic makes surface-level sense. The subtle flaw is in the third if branch that handles an edge case the developer didn't explicitly prompt for.
This creates what some security engineers call the fluency illusion: code that reads fluently but hasn't been truly reasoned about. When a developer uses Copilot or Cursor to write a function they don't fully understand, they're no longer the author in any meaningful sense — they're an approver. And approval without comprehension is how vulnerabilities ship.
What Engineering Teams Are Doing
Forward-thinking teams are adapting their processes in three key ways:
- AI-aware static analysis. Tools like Snyk Code, Semgrep, and SonarQube have updated their rulesets to target patterns that appear more frequently in AI-generated code. Some teams run a second SAST pass specifically configured for AI code hotspots, treating it as a separate scan profile from their standard human-code rules.
- Annotation requirements. Developers add a comment indicating whether a function was AI-generated, human-written, or AI-assisted. This isn't about blame — it's about calibrating reviewer attention. AI-generated code gets a stricter review pass, especially around input validation and error handling boundaries.
- Test authorship separation. If the AI writes both the implementation and the tests, the test suite only proves the AI is internally consistent, not that the code is correct. Teams increasingly require that tests for AI-generated code be written separately by a human, ideally from the specification rather than from reading the implementation.
The Real Risk Is Organizational
The technical vulnerabilities are solvable with better tooling and process. The harder problem is organizational. When a team ships 3x faster with AI assistance, there's enormous pressure to skip the review steps that catch the 10% of cases that go wrong. Speed becomes the default setting, and rigor becomes the exception. This is compounded when the reviewers themselves are using AI — a model reviewing AI-generated code can miss exactly the blind spots the generating model had.
The industry is learning that the productivity gains from AI coding tools are real, but they require a corresponding investment in review infrastructure to be safely captured. The teams that skip this step aren't moving faster — they're taking out a loan against their future incident response capacity. When that debt comes due, it usually comes due in production.
The Bottom Line
AI-assisted development isn't going away, and it shouldn't — the productivity gains are real and compounding. But the review processes built for human-speed coding don't automatically scale to human-and-AI-speed coding. Updating your SAST configuration, your annotation conventions, and your team's mental model of what "code authorship" means in 2026 is now core infrastructure work, not an optional upgrade.