In a 2023 study presented at ACM CCS, Stanford researchers Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh gave developers a set of security-relevant programming tasks, split them into a group using an AI coding assistant and a control group without one, and found the AI-assisted group wrote less secure code on four of five tasks — while also reporting higher confidence that their code was safe. That gap between actual and perceived security is the core problem this post examines. A separate, earlier line of research by Pearce et al. ("Asleep at the Keyboard," 2021) scanned GitHub Copilot completions against 89 CWE scenarios and found roughly 40% of the generated programs contained a vulnerability, with C completions faring worse (about 50%) than Python (about 39%). A 2023 follow-on analysis of real-world Copilot completions found roughly 27% contained at least one security flaw. None of this makes AI coding assistants unusable — it makes the code they produce a distinct risk category that needs its own code quality scanning and review gate, not a rubber stamp because "the linter passed." Below, we walk through what the research actually shows about how quality erosion in AI-generated code compounds over time into exploitable risk, and close with a concrete pre-merge checklist.
Why are developers more confident in AI-generated code than they should be?
Developers are more confident in AI-generated code than they should be because the code looks syntactically fluent and idiomatic even when it's semantically wrong or insecure, and fluency is what humans use as a proxy for correctness. The Stanford CCS '23 study measured this directly: participants using the AI assistant were significantly more likely to believe their solutions were secure, even on the specific tasks where the AI group's code was objectively less secure than the control group's. This isn't a one-off artifact — it maps onto a well-documented cognitive bias where well-formatted, confident-sounding output gets less scrutiny than something that looks rough or unfinished. In a code review workflow, that means AI-generated pull requests are statistically more likely to sail through review with less pushback than a junior engineer's obviously-in-progress diff, precisely because they read as more polished. The practical consequence is that teams need review gates that don't rely on human intuition about which PRs "look risky" — the code most likely to hide a vulnerability is often the code that looks the most finished.
How often does AI-generated code actually contain exploitable vulnerabilities?
AI-generated code contains exploitable vulnerabilities often enough that treating it as pre-vetted is not defensible. Pearce et al.'s 2021 analysis of Copilot completions against MITRE's top CWE scenarios found about 40% of generated programs were vulnerable overall, with SQL injection and hardcoded credential patterns among the recurring failure modes, and the C-language completions (roughly 50% vulnerable) notably worse than Python (roughly 39%). A separate 2023 study of Copilot completions in real repositories found approximately 27% contained at least one security vulnerability — lower than the synthetic-benchmark number, but still meaning roughly one in four AI-suggested completions merits a second look before merge. Neither study claims AI assistants are worse than the average human-written line of code across the board; both establish that the rate is high enough, and structurally different enough (concentrated in specific CWE classes like injection and improper input validation), that it needs a dedicated detection layer rather than the general code-review process alone.
Why does code quality erode across successive rounds of AI-assisted edits?
Code quality erodes across successive AI-assisted edits because each iteration tends to patch a symptom rather than restructure the underlying logic, and errors introduced early get baked into the context the model uses for the next edit. A June 2025 arXiv paper, "Security Degradation in Iterative AI Code Generation," documented this directly: as researchers ran repeated rounds of AI-assisted modification on the same codebase, measured security quality declined across iterations rather than holding steady or improving. This matters operationally because AI-assisted development rarely means one clean generation — it means dozens of follow-up prompts ("now add error handling," "now support this edge case") stacked on top of each other, each one operating on an already-imperfect base. A single-point-in-time code review at PR open, if it happens before the fifth or tenth iteration, misses the compounding drift; a gate that only fires once per feature branch misses the fact that the fifteenth commit on that branch may be measurably less secure than the first.
What does large-scale commit data show about AI-era code health?
Large-scale commit data shows a measurable shift toward code that is written once and rarely revisited, which is the opposite of the refactoring discipline that catches latent bugs before they ship. GitClear's 2025 report, based on an analysis of 211 million changed lines of code from January 2020 through December 2024, found that refactoring — the "moved" or restructured category of changed lines — fell from roughly 25% of changes in 2021 to under 10% by 2024, while copy-pasted code rose from 8.3% to 12.3% of changes and, for the first time in the dataset's history, exceeded the volume of refactored code. The same report found code revised within two weeks of being written rose from 5.5% (2020) to 7.9% (2024) — more freshly added code getting reworked almost immediately, consistent with AI-assisted code arriving fast but needing correction shortly after. Duplicated code blocks rose roughly eightfold over the study period. None of this proves a given vulnerability came from an AI assistant, but it documents a structural trend: less consolidation, more duplication, and faster churn are exactly the conditions under which a security flaw copied into ten places is ten times harder to find and fix than one written once.
What belongs in a pre-merge review gate for AI-generated code?
A pre-merge gate for AI-generated code should assume the code is unvetted by default and check for the specific failure modes the research above identifies, rather than relying on general-purpose lint rules. At minimum: (1) run a static analysis and code quality scan on every PR, not just ones flagged as "AI-assisted," since attribution is unreliable and the failure modes overlap with human-written bugs anyway; (2) flag PRs with unusually low diff-to-review-time ratios, since fast, confident-looking submissions are exactly what the Stanford study shows reviewers under-scrutinize; (3) run duplication detection to catch the copy-paste pattern GitClear documented, since a vulnerability duplicated across a codebase is a multiplier, not a single fix; (4) require dependency and CVE checks on every AI-suggested import, since assistants frequently suggest packages by name pattern rather than verified provenance; and (5) gate on iteration count for long-lived feature branches, re-running full scans rather than trusting the branch's original PR-open scan, given the iterative-degradation finding. None of these checks require knowing which lines a human wrote versus which an assistant suggested — they require treating "looks finished" as a non-signal.
How Safeguard helps
Safeguard's guardrails run exactly this kind of gate as policy-as-code rather than manual checklist discipline. The safeguard gate CLI step evaluates every pull request against rules with BLOCK, WARN, or AUTO_FIX effects — so a CWE-89 injection pattern or a newly introduced CVE in a suggested dependency can block a merge automatically, regardless of whether a human or an assistant wrote the line. When a dependency change does introduce a known vulnerability, Griffin AI can open an auto-fix pull request that pins the safe version and updates the lockfile, closing the loop the Stanford study shows human reviewers are prone to miss: the gate doesn't get more confident just because the original diff looked polished. Every guardrail decision — block, warn, or auto-fix — is logged to a signed audit record, so a team can measure, over time, whether their AI-assisted PRs are actually converging toward safer code or quietly accumulating the duplication and churn GitClear's data describes at the industry level.