By mid-2026, AI-generated code is no longer a novelty in the software supply chain — it is the default. GitHub disclosed back in 2023 that Copilot was already responsible for close to half of the code its users wrote in supported languages, and Stack Overflow's 2024 Developer Survey found that 76% of professional developers were using or planning to use AI tools in their daily workflow. Adoption has only accelerated since. What hasn't kept pace is the security tooling meant to check that code before it ships. Most CI pipelines were built to catch familiar mistakes in human-written diffs, not to flag a hallucinated dependency, an insecure default baked into a training corpus, or subtly wrong cryptography a model produced with total confidence. The result is a widening gap between how fast AI-suggested code merges and how carefully anyone actually looks at it.
How widespread is AI-assisted coding inside the average engineering org?
Extremely — and the trend line is steep. GitHub's own 2023 research found that in organizations using Copilot, AI suggestions accounted for nearly 46% of code written in supported languages, with acceptance rates around 30% of suggestions shown. JetBrains' 2023 developer ecosystem survey put AI tool usage among respondents above 77%, and by the 2024 Stack Overflow survey, 76% of professional developers reported using or planning to use AI coding assistants — a number that has almost certainly crossed 80% by 2026 given how quickly Copilot, Cursor, and in-IDE assistants from Amazon and Google have become default-installed tooling rather than opt-in extras. For most teams shipping weekly, AI is not a tool one developer occasionally reaches for; it is now embedded in the default authoring loop for a large share of commits.
Why do so few teams actually scan AI suggestions before they merge?
Because governance adoption has lagged tool adoption by roughly a full budget cycle. Security and platform teams approved AI coding assistants the way they approved linters — as a productivity add-on — without updating the pipeline gates that decide what gets merged. Snyk's AI Code Security research has repeatedly found the same pattern: the overwhelming majority of organizations permit developers to use AI-generated code, but only a minority have a formal policy requiring that code be scanned or reviewed differently than human-written code before it reaches main. Compounding the policy gap is a confidence gap. A widely cited 2022–2023 Stanford study (Perry et al.) found that developers who used an AI coding assistant produced measurably less secure code than a control group — and were simultaneously more likely to rate their own code as secure. Teams aren't skipping scans out of negligence; they're skipping them because the code looks finished, compiles cleanly, and comes from a tool that feels authoritative.
What actually slips through when AI output goes unscanned?
Three categories consistently show up: hallucinated dependencies, reproduced insecure patterns, and embedded secrets. On the first, a 2024 academic study ("We Have a Package for You!", Spracklen et al.) tested 16 code-generating models and found hallucinated package names appeared in generated code anywhere from 5.2% to nearly 22% of samples depending on the model — packages that don't exist yet, but that an attacker can register the moment a name starts circulating in public code. This "slopsquatting" technique turns a language model's confident guess into a live attack surface, and it is invisible to a reviewer skimming a diff for logic errors. On the second, because LLMs are trained on the accumulated corpus of public code — including plenty of code with known CWE-class flaws like SQL injection, missing input validation, and hardcoded credentials — they reproduce those patterns at a non-trivial rate, exactly the kind of thing static analysis is built to catch but frequently isn't run against AI-authored diffs with the same rigor. On the third, GitClear's 2024 AI Copilot Code Quality report documented a measurable rise in code churn and copy-pasted blocks alongside a decline in refactored, moved code — a pattern consistent with code being added faster than it's being critically reworked or re-examined.
What happens once one of these issues reaches production instead of getting caught in the PR queue?
The blast radius and remediation cost both jump, and the surrounding threat landscape is already primed to exploit exactly this kind of gap. Sonatype's 2023 State of the Software Supply Chain report identified more than 245,000 malicious open-source packages in that year alone — more than double the cumulative total Sonatype had catalogued across every prior year combined. That backdrop matters because a hallucinated or typosquatted dependency introduced by an AI suggestion isn't a hypothetical risk sitting in a research paper; it is dropping into an ecosystem where malicious actors are actively registering plausible-sounding package names at record volume, waiting for exactly the kind of unverified AI suggestion a developer might accept and merge on a Friday afternoon. Once that dependency is pulled into a build, it inherits every downstream permission the build has — CI credentials, deployment tokens, production secrets — and the fix is no longer a one-line diff review but an incident response exercise.
Why doesn't "a human reviewed the pull request" close the gap?
Because review capacity hasn't scaled with the volume of AI-suggested changes, and trust in the output is quietly eroding review rigor rather than reinforcing it. Stack Overflow's 2024 survey found trust in the accuracy of AI tools had actually fallen year over year, with only 43% of developers saying they trusted AI-generated output — yet that skepticism doesn't reliably translate into slower, more careful review, because the pressure to ship at AI-assisted speed pushes in the opposite direction. GitClear's churn data points to the same mechanism from a different angle: bigger, faster-produced diffs land in review queues that were sized for a slower era of hand-written commits, so reviewers skim more and verify less per line. A pull request template checkbox that says "reviewed" is not evidence that anyone checked whether a new dependency actually exists on the registry it claims to, or whether a suggested crypto call uses a deprecated cipher mode. Manual review remains essential, but it was never designed to be the last line of defense against a category of risk — hallucinated packages, training-data-inherited vulnerabilities — that didn't exist when most review processes were designed.
How Safeguard Helps
This is precisely the gap Safeguard is built to close: the space between "a developer accepted an AI suggestion" and "that code is running in production," where almost no organization has an automated, consistent checkpoint today. Safeguard scans AI-suggested code and its dependencies before merge, not just at release time, so a hallucinated or newly-registered package gets flagged before it's woven into a build rather than after it starts pulling in production credentials. That means verifying dependency provenance and registry existence, checking for the CWE-class patterns that AI models are statistically prone to reproducing, and catching embedded secrets or insecure defaults with the same rigor applied to human-authored code — instead of assuming AI output deserves a lighter touch because it compiled cleanly.
Rather than relying on developer judgment alone to decide when a scan is warranted, Safeguard applies policy-as-code gates directly in CI/CD, so every merge — human-written or AI-suggested — passes through the same checkpoint by default, closing exactly the governance lag that let tool adoption outrun security policy in the first place. For SOC 2-minded engineering organizations, that consistency is also the audit trail: a documented, enforced control showing that AI-generated code is subject to the same scanning standard as everything else, rather than a policy that exists on paper but isn't reflected in the pipeline. As AI-assisted development becomes the default way code gets written, Safeguard's position is straightforward — the guardrail that's missing across the industry shouldn't be optional, and it shouldn't depend on a reviewer noticing what a model got wrong.