A pull request lands with 400 changed lines, four new dependencies, and a commit message that just says "add retry logic." The author used an AI assistant to generate most of it in under ten minutes. The reviewer has fifteen minutes before their next meeting and a backlog of six other PRs. This is not a hypothetical — it is Tuesday morning at thousands of engineering organizations in 2026. GitHub's own telemetry has shown Copilot generating close to half of code in enabled files for years now, and internal tools at companies like Google and Microsoft report similar or higher shares for boilerplate-heavy languages. The volume of code moving through review has grown faster than the humans reviewing it. That mismatch — not any single AI failure — is the real story, and it means code review built for a world of human-paced commits needs to be rebuilt for a world where the bottleneck moved from writing code to checking it.
How much of the code being reviewed today is actually AI-generated?
A large and fast-growing share, and it is no longer a niche practice. GitHub reported in 2023 that Copilot was responsible for an average of 46% of code in files where it was active, rising to 61% for Java. Stack Overflow's 2024 Developer Survey found 76% of respondents were using or planning to use AI coding tools, up from 70% the year before. GitClear's 2024 analysis of 153 million changed lines of code found that "copy/pasted" code overtook "moved" (refactored) code for the first time in the ten years GitClear has tracked the metric — a pattern consistent with developers accepting AI suggestions wholesale rather than reshaping existing logic. None of this means half of every codebase is AI-authored, but it does mean the median pull request a reviewer opens today contains a meaningfully larger, denser block of machine-generated logic than the same PR would have in 2021 — often written in a single pass, without the incremental, self-correcting process a human author usually goes through.
Does AI-generated code actually introduce more security risk than human-written code?
Yes, on current evidence, and the gap is measurable. Veracode's 2025 GenAI Code Security Report tested 80 large language models across more than 100 coding tasks and found that generated code introduced security vulnerabilities roughly 45% of the time, with weaknesses from the OWASP Top 10 — including injection flaws and improper input validation — showing up repeatedly across models and languages. A widely cited Stanford study from 2023 (Perry et al.) found that developers using an AI coding assistant wrote significantly less secure code than a control group, and — more concerning for reviewers — were more confident their code was secure than developers who wrote it unassisted. That confidence gap matters because it changes what a reviewer is fighting: not sloppy code that looks sloppy, but plausible-looking code from an author who has already convinced themselves it's fine.
Why does traditional code review break down specifically on AI-generated code?
Because human review was designed around the assumption that whoever wrote the code understood it, and that assumption no longer reliably holds. Traditional review leans heavily on the author being able to explain intent, edge cases, and tradeoffs in the PR description or a follow-up comment — but a developer who prompted an LLM for a function often cannot explain why it chose a particular library or algorithm, only that it "worked." Reviewers also fall back on pattern recognition: code that looks idiomatic gets a faster, lighter pass. AI output is specifically optimized to look idiomatic, which means the visual cues reviewers use to flag risk are exactly the cues LLMs are best at faking. Then there's volume: if a single engineer can now produce three or four times the code per day, and review capacity per engineer hasn't changed, either review depth drops or review backlogs grow — most teams have quietly chosen the former.
Are there new failure modes review checklists don't cover yet?
Yes — package hallucination is the clearest example, and it's now a named, tracked risk. Research published in 2024 by security firm Lasso and later corroborated by academic researchers found that across 576,000 code samples generated by 16 different LLMs, roughly 440,000 package references were hallucinated — names of dependencies that don't exist — and about 43% of those hallucinated names were repeated consistently across multiple prompts, making them predictable enough to register as real packages. The Python Software Foundation's Seth Larson coined the term "slopsquatting" for the resulting attack: adversaries pre-register the fake package names LLMs are known to hallucinate, so the next developer who accepts an AI suggestion pulls down malware instead of a typo. Standard code review checklists — built around logic errors, style, and test coverage — don't ask "does this dependency exist, and did we resolve it from a trusted registry," because that question never used to need asking.
What concretely needs to change in how teams review code?
Provenance and process, more than intuition. First, code needs to carry metadata about how it was produced — AI-assisted commits flagged distinctly from human-authored ones — so reviewers can calibrate scrutiny instead of guessing. Second, automated gates need to run before a human ever opens the diff: software composition analysis to catch hallucinated or malicious dependencies, SAST tuned to the vulnerability classes Veracode and others have shown LLMs reproduce most often (injection, hardcoded secrets, missing authorization checks), and provenance verification (SLSA-style attestations) on anything pulled in as a dependency. Third, review depth should scale with blast radius, not just diff size — a 20-line change to an authentication middleware written by an AI assistant deserves more scrutiny than a 200-line AI-generated test file. Google's 2024 DORA report found that a 25% increase in AI adoption correlated with a 7.2% decrease in software delivery performance and a 1.5% decrease in delivery stability, largely attributed to exactly this kind of unscaled review process trying to absorb more change than it was built for.
Are compliance frameworks like SOC 2 keeping up with AI-written code?
Not yet, in most implementations, though auditors are starting to ask the right questions. SOC 2's change management criteria (CC8.1) require that changes to systems be authorized, tested, and reviewed before deployment — but the control was written assuming a human change author, and most organizations' documented review procedures don't yet specify how AI-assisted commits are reviewed differently. NIST's Secure Software Development Framework (SSDF, SP 800-218) update work through 2024–2025 has begun explicitly addressing AI-generated code and third-party model risk, signaling where auditors will look next. In practice, that means the artifact an auditor wants in 2026 isn't "we do code review" — it's evidence of what was reviewed, by whom, against which automated findings, and whether the code's origin (human, AI-assisted, or AI-generated) was tracked at all. Teams that can't answer that today are the ones most likely to get a finding in their next SOC 2 Type II cycle.
How Safeguard Helps
Safeguard was built for exactly this shift — a software supply chain that now includes AI as a first-class code author, not just a productivity feature. Safeguard gives engineering and security teams visibility into where code, dependencies, and build artifacts actually came from, so "was this AI-generated" stops being a question reviewers have to guess at and becomes metadata attached to the commit. On the dependency side, Safeguard screens new packages against known typosquatting and slopsquatting patterns before they land in a build, closing the exact hallucinated-dependency gap that traditional review checklists miss. Safeguard's policy engine lets teams define risk-scaled review requirements — routing AI-assisted changes to authentication, payment, or infrastructure code through stricter gates automatically, rather than relying on a reviewer to notice and escalate manually. And because SOC 2 and SSDF auditors increasingly want documented evidence of how AI-generated code is tracked and reviewed, Safeguard produces the provenance and attestation trail — who authored what, what scanned clean, what was overridden and by whom — that turns "we think our review process covers this" into an auditable answer. Code review isn't going away as AI writes more of the codebase; it's being pushed to review the pipeline that produces the code, not just the code itself, and that's the layer Safeguard is built to secure.