GitClear's 2024 analysis of 211 million changed lines of code, spanning January 2020 through December 2024, found that copy-pasted and cloned code climbed from 8.3% of changes in 2020 to 12.3% in 2024, while refactored ("moved") code fell from roughly 24% in 2020 to under 10% by 2024 — the first time in the dataset that duplication outpaced refactoring. Code churn, defined as lines rewritten within two weeks of being committed, rose from 5.5% to 7.9% over the same period. These trends line up with the mainstream adoption of AI coding assistants, and they matter because AI code review tools were supposed to be the backstop that catches the sloppy duplication and rushed churn AI-assisted authoring produces. GitHub reports that its own Copilot code review surfaces "actionable" feedback in 71% of reviews, averaging 5.1 comments per review, but that number describes volume, not whether the right defects get caught. This post separates the two questions AppSec teams actually need answered: what does AI code review reliably catch, and what does it still miss compared to rule-based static analysis and an experienced human reviewer reading the diff.
What does AI code review actually catch well?
AI code review tools are consistently strong at the categories that require reading intent rather than tracing execution: style and readability issues, naming inconsistencies, missing docstrings, obvious off-by-one errors, and unhandled edge cases visible within a single function or file. Because large language models are trained on natural-language explanations paired with code, they're also unusually good at explaining why a change might be risky in plain English — turning a bare diff into a paragraph a junior engineer or a non-technical stakeholder can follow. GitHub's November 2024 write-up on Copilot code review leaned on exactly this framing: high review volume (5.1 comments per PR on average) and a 71% "actionable" rate, which is GitHub's own quality metric rather than an independently audited one. That volume is genuinely useful for catching the long tail of small, low-severity issues that human reviewers skip when they're skimming a large PR near a deadline — the kind of paper cuts that compound into GitClear's churn numbers if nobody flags them.
Where does AI code review fall short on security bugs specifically?
AI review models struggle most with vulnerabilities that require tracing data across files, services, or trust boundaries rather than reading a single diff hunk in isolation. A 2025 arXiv paper, "GitHub's Copilot Code Review: Can AI Spot Security Flaws Before You Commit?" (arxiv.org/abs/2509.13650), set out to test this directly by evaluating Copilot's review feature against known security-flawed code rather than relying on vendor-reported "actionable comment" rates. The gap is structural, not just a training-data problem: an LLM reviewing a pull request typically sees the changed lines plus limited surrounding context, not a full interprocedural call graph. A SQL injection where user input enters through an HTTP handler in one file and reaches a raw query three function calls and two files away is exactly the shape of bug that traditional taint-tracking static analysis (SAST) is built to trace, and that a diff-scoped AI reviewer is structurally likely to miss unless the vulnerable line and the tainted source both happen to appear in the same reviewed hunk.
How do false-positive rates compare between AI review and traditional SAST?
Reported false-positive rates for AI code review tools vary widely by vendor and are largely self-reported rather than independently benchmarked, which is itself worth noting before trusting any single number. Community discussion around general-purpose assistants in the Copilot class clusters false or low-value comments in the 15-25% range, while narrower, review-focused tools like CodeRabbit report figures closer to 8%, and DeepSource claims sub-5% — all of these are vendor or user-reported, not peer-reviewed, and should be read as directional rather than definitive. Traditional rule-based SAST has the opposite reputation problem: it's precise about what it flags but frequently over-flags at the ecosystem level, since a plain dependency or pattern match doesn't know whether the flagged code path is reachable at runtime. Multiple SCA vendor studies from 2023-2024 have found that a large majority of dependency-level CVE findings sit in code that's never actually invoked — noise that neither an AI reviewer skimming a diff nor a classic pattern-matching SAST rule is positioned to resolve on its own.
Does AI review replace human reviewers for security-sensitive changes?
No — the two remaining strongest signals for security-sensitive changes are still traditional taint/reachability-based static analysis and an experienced human reviewer who understands the business logic being changed, and AI review is best understood as a third layer rather than a replacement for either. Business-logic flaws — an authorization check that's technically present but checks the wrong field, a discount code that can be replayed because a state transition was missed — are notoriously hard for any automated tool, AI or rule-based, to catch, because they require understanding what the system is supposed to do, not just what the code says. Novel vulnerability classes outside a model's training distribution are a related blind spot: an LLM reviewer pattern-matches against code and vulnerabilities it has effectively seen before, so a genuinely new exploitation technique is unlikely to trip its judgment the way it would trip an experienced reviewer's intuition. Teams that have removed human review from security-sensitive paths in favor of AI-only gating are trading a known, bounded cost (reviewer time) for an unmeasured one (undetected logic flaws).
How Safeguard Helps
Safeguard's PR Guard runs exactly the diff-scoped AI review this post has been describing: it analyzes a pull request's diff and returns severity-ranked comments — security, bug, reliability, performance, maintainability — each tied to a specific file and line, with an optional suggested fix, posted inline in Safeguard or back onto the pull request itself. It inherits the same structural ceiling as any diff-scoped reviewer: it reasons over the changed lines and surrounding context, not a full interprocedural call graph, so it's a complement to taint-based SAST rather than a replacement for it. Where Safeguard adds a layer most AI reviewers don't have is upstream of the PR: Griffin AI reasons over reachability and exploitability signals — call-graph reachability, EPSS, KEV — across your dependency graph and SBOM, explains in plain language why a given vulnerability finding is (or isn't) something your code can actually reach, and can generate a remediation pull request for it. That combination — diff-level review plus reachability-informed triage and remediation — is closer to the three-layer picture this post has been building toward than any single tool, AI or not, gets on its own.