AI coding assistants are now standard tooling in most engineering environments. GitHub Copilot, OpenAI Codex, and similar tools have moved from novelty to default — embedded in editors, CI pipelines, and code review workflows. The productivity gains are real. So are the security risks, and the industry has been slower to reckon with the latter.
This isn’t a case against using AI coding tools. It’s a case for using them with your eyes open.
The hallucination problem in code
AI models generate code by predicting likely continuations based on training data. They don’t understand the security implications of what they’re producing — they’re pattern-matching against patterns that may include insecure code, deprecated APIs, and examples that were never meant to be production patterns.
The result is hallucinated code that looks correct and compiles cleanly but contains serious flaws. A classic example: generated SQL that strings values directly into a query instead of using parameterized statements. The code works. It also introduces SQL injection wherever it’s deployed.
The problem is that this kind of error is hard to spot in review. The logic looks right. The style matches the codebase. The only tell is a missing parameterization that’s easy to overlook, especially under time pressure.
Vulnerability patterns AI tends to introduce
Beyond hallucinated logic, there are categories of vulnerabilities that AI tools introduce with particular frequency:
Hardcoded credentials. AI assistants often fill in placeholder API keys, secrets, or connection strings based on patterns they’ve seen. These placeholders sometimes make it into production unchanged — especially in fast-moving codebases without secrets scanning in CI.
XSS via unsanitized output. Generated frontend code that renders user-supplied data directly into HTML, without escaping or validation. This is a well-understood class of vulnerability, but AI tools still generate it routinely.
Deprecated cryptographic methods. MD5 for hashing, RC4 for encryption — patterns that were once common in training data and continue to appear in AI suggestions despite being cryptographically broken.
Insecure authentication patterns. Session management code that doesn’t invalidate tokens correctly, permission checks applied inconsistently, or JWT validation that ignores the algorithm field.
Research from Stanford found that developers using AI-assisted coding tools were more likely to introduce security vulnerabilities — with a roughly 40% increase in insecure code submissions among AI-assisted developers compared to a control group. The tooling is fast, but fast and insecure is worse than slow and secure.
What actually helps
The answer isn’t to stop using AI coding tools — that ship has sailed. The answer is to treat AI-generated code with the same scrutiny you’d apply to code from an external contributor: reviewed, not just accepted.
Static analysis in CI. Tools like SonarQube, Semgrep, and CodeQL catch vulnerability classes that humans miss under time pressure. They’re not magic, but they’re consistent. If AI introduces a SQL injection pattern, a configured SAST scanner will flag it before it reaches production.
Secrets scanning. Tools like GitGuardian or GitHub’s built-in secret scanning should be running on every push. AI-generated code is particularly prone to containing credentials — make detection automatic rather than relying on review.
Peer review with a security lens. Reviewing AI-generated code requires a different posture than reviewing code you understand end-to-end. Reviewers should be actively looking for the specific vulnerability patterns AI tends to produce, not just checking for logic errors.
Training. Less experienced engineers are more likely to accept AI suggestions uncritically. Understanding what categories of vulnerabilities to watch for — and why AI tools produce them — should be part of onboarding for any team using these tools.
The framing that helps
AI coding assistants are tools that increase output velocity. They are not tools that increase output correctness. These are separate dimensions, and conflating them is where security failures happen.
A tool that doubles the speed at which vulnerable code is produced is not a productivity win on net. The security review overhead increases proportionally — and if the review isn’t proportionally thorough, the risk compounds.
The teams using AI coding tools most effectively are the ones that have thought through what their review process looks like for AI-generated code, specifically, and have built tooling and habits to match. That’s the configuration that captures the velocity gains without accepting the security debt.