In early June, Anthropic published a numberthat should make every compliance lead pause: as of May 2026, more than 80% of the code merged into Anthropic's own codebase was authored by Claude rather than typed line by line by a person. Anthropic does not claim this generalises, and it should not be read as an industry-wide statistic. But you do not need Anthropic's number to ask the question that matters. If your developers use Copilot, Cursor, Claude Code, or a vendor-built AI feature at all, this already applies to you, whether or not you have ever measured the exact proportion.
Ask it before your next audit sample does. What fraction of the code merged into your codebase last month was AI-authored, and does your code-review control know the difference? Most companies I talk to have never framed the question that way. Their SOC 2 or ISO 27001 control narrative says something like “code changes are reviewed and approved prior to merge,” a sentence written when that meant a person reading code that another person wrote. Nobody rewrote it when the authorship changed. That is the gap this article is about, and it is now a live audit-readiness question, not a future risk.
Your control was designed to catch a person, not a pattern
Every code-review control, whatever standard evidences it, exists to catch a specific kind of failure. A developer under deadline pressure skips a null check. A contractor with less context on the codebase introduces a subtle bug. Rarer, someone with bad intent slips something in deliberately. The control narrative assumes these failures are randomly distributed: sloppiness and malice do not follow a pattern, so the fix is a second set of eyes on every change, calibrated to catch whatever a first pass missed.
That assumption held for as long as humans wrote the code being reviewed. It does not hold for AI-generated code, because AI failure is not randomly distributed. It is the same category of mistake, at a measurable rate, across an enormous number of generations. A human reviewer who has seen a colleague make a particular mistake once assumes it will not recur identically next week. An AI system offers no equivalent assurance: the same category of mistake shows up again and again across models and tasks at a measured, non-trivial rate, because the failure is a property of how the model generates code, not a one-off lapse in judgement. Whether your model, on your codebase, recurs at exactly that population rate is not something this data measures, but “it probably won't happen again” is not a claim anyone can make about AI-generated code the way a manager might make it about a chastened engineer.
To be clear about what is not the claim here: mature code-review programmes are not a pure human vigilance exercise that AI quietly broke. Good programmes already run automated tests, static analysis, secure-coding standards, and reviewer specialisation on top of human sign-off. The problem is narrower than “code review stopped working.” It is that many control narratives, the actual sentence written down for an auditor, still describe review as a human-approval event on a diff of unspecified size and unspecified origin. That description is what is untested against AI-generated volume, not the whole discipline of code review.
The volume broke the cadence before anyone noticed
Review cadence and reviewer attention were calibrated to a human authorship rate. A senior engineer reviewing a colleague's 150-line pull request reads every line, understands the intent, and can reasonably catch a logic error or a missed edge case. That cadence assumes the volume a human can produce in a day and the depth a human reviewer can sustain across that volume are roughly matched.
AI-assisted generation breaks that match. A developer using an AI coding assistant can produce, review-ready in their own mind, several times the volume of a pre-assistant day. The reviewer on the other end of that pull request is still one person, with the same attention budget they had before. “We reviewed it” can now mean a careful line-by-line pass on a hundred lines, or it can mean a fast skim across a few thousand, approved because the tests passed and nothing looked obviously wrong. Both get logged identically in your pull-request history as “reviewed and approved.” Your control document does not distinguish between them, because it was never written to.
This is not a hypothetical drift. It is the specific mechanism by which a technically-satisfied control produces an unsafe outcome: the approval event fires every time, the review depth behind that event varies enormously, and nothing in the control narrative, and usually nothing in the tooling either, captures which one happened on a given merge.
The failure mode is the same failure, repeated
Here is what makes this a rate problem rather than an occasional-miss problem. Veracode has run the same test across more than 150 large language models, and its March 2026 update found that 45% of the AI-generated samples still introduced at least one OWASP Top 10vulnerability (the industry's standard list of the most critical web-application security risks) -- a pass rate that has barely moved in two years of newer, larger models. That is not evenly spread across languages either: Java-generated code failed 71% of the time. A separate, more specific finding from the same body of testing: 85% of the samples relevant to cross-site scripting failed to defend against it. These are two distinct figures measuring two different things, an overall introduction rate and a category-specific defence-failure rate, and they should not be collapsed into one number when you are explaining this to your own team.
Georgia Tech researchers tracked the downstream effect with a tool they call the Vibe Security Radar: it flagged about 18 AI-linked vulnerability cases across the second half of 2025, then 56 in the first quarter of 2026 alone, with March 2026 by itself accounting for more than all of 2025 combined. The trend line is not just climbing, it is steepening, in a category that barely existed as a distinct line item two years ago.
None of this says AI-generated code is uniquely bad in some categorical sense, or that human-written code is clean. Humans introduce vulnerabilities too. What is different is the shape of the failure. A human team's vulnerability rate is a mix of individual habits, team norms, and how tired everyone is that sprint, genuinely hard to predict merge to merge. An AI system's vulnerability rate is measurable by task type and model family, and far steadier than that. That is precisely what makes it tractable to control for, and precisely what most current controls do not attempt to control for at all.
What does a “meaningful” code review actually mean under SOC 2?
Most SOC 2 and ISO 27001 control implementations evidence change management the same way: a code change is reviewed and approved before it merges, and that approval is logged. ISO 27001's Annex A control A.8.32names change management directly; SOC 2 tests it through change-management criteria mapped to the Trust Services Criteria rather than one named control. Neither standard's text literally mandates a specific review method or depth. In practice, most software companies evidence this through their documented pull-request and approval workflow, however thin that documentation is. That flexibility is the point of the standards. It is also exactly where the gap hides.
“Code changes are reviewed prior to merge” was an easier control statement to defend when review meant a human reading code a human wrote, at a pace both parties implicitly understood. It says nothing about what fraction of a given merge was AI-authored, and nothing about whether the review depth applied matched that fraction. An auditor sampling your pull requests today is checking that the approval box is ticked, largely a mechanical check. They are not yet asking, on the whole, what proportion of the diff was AI-generated or whether the reviewer spent five minutes or fifty on it.
I have watched this play out at both ends of company size, and it breaks differently at each. At a forty-person startup, there is usually no formal review-depth control yet at all, informal norms stand in for policy, and the gap is invisible because nobody has looked for it. I have also watched a company mid-way through SOC 2 certification treat “code changes are reviewed prior to merge” as sufficient right up until an auditor asked the one question the control narrative did not answer: what does “reviewed” mean when a large share of the diff was not written by a person. Nobody in the room had an answer, because nobody had been asked to measure it yet.
This gap is easy to miss when AI governance and security-compliance control design sit in different rooms. I have built and tested the actual control libraries companies run for SOC 2 and ISO 27001, and I was advising on AI governance back when it meant model-risk committees, not code review. The AI-governance side sees the authorship shift happening in real time; the compliance side is the one that has to write a control narrative an auditor will actually accept. Sitting across both, watching the same pattern repeat from the forty-person startup to the company mid-way through certification, is what makes this particular gap visible early instead of after the fact. The ISO 27001 guide for growing SaaS companies covers in more depth what an auditor typically samples and how to prepare for it; this specific gap rarely shows up on that sampling checklist yet, which is exactly the problem.
What the better control looks like
The core of a better control is simple to state. Capture the AI-authorship proportion of material merges, and tie a required review depth to that proportion. A pull request that is 90% AI-generated does not get the same five-minute skim as one that is a genuine 20-line human fix. The control narrative should say so explicitly, not leave it to whatever the reviewer happens to do that day.
Simple to state is not the same as simple to operationalise. In practice this touches control-narrative language (the sentence your auditor reads has to actually say this), engineering workflow changes (something has to measure or estimate the AI-authorship fraction, whether that is a tool-reported flag, a commit convention, or a manual tag, none of which will be perfectly precise once a human edits or regenerates part of what a model produced, which is normal developer behaviour, not an edge case), named ownership (someone has to be accountable for the policy existing and being followed, not a committee), and an exception-handling path (what happens when a high-AI-authorship merge gets a shallow review anyway, and who signs off on that exception). The piece on who owns AI governance goes into the ownership question directly; a control like this fails quietly if it belongs to everyone and specifically to no one.
None of that is exotic engineering. All of it requires someone to decide it matters enough to build, before an auditor or an incident forces the decision. The diagnosis here is genuinely simple: measure the proportion, tie depth to it, write it down. Building the version of that which survives contact with a real audit or a real customer questionnaire is the part that takes actual work, and this article is not attempting to hand you a finished implementation, only the shape of what a defensible one has to include.
What to check before your next audit cycle
A concrete gut-check you can run this week. Pull your last ten merged pull requests. For each one, estimate what fraction was AI-authored, even roughly. Then ask what review depth actually applied: a genuine line-by-line read, a structural skim, or an approval driven mostly by passing tests. If you cannot answer that second question for most of the ten, you have found the gap, and you have found it before an auditor does.
Name the moment this actually bites. It is the sample your auditor pulls for your next SOC 2 Type II review, or the moment a customer asks, in a call or in writing, how AI-authored code gets reviewed differently from human-authored code. Most auditors have not started asking that question yet, which means the companies that can already answer it cleanly are ahead of the current bar, not just compliant with it.
The audit finding is the easy version of this problem
An auditor asking “walk me through how you review AI-authored code differently” is the easy version of this problem to have. The hard version is finding out the gap exists from an incident instead. You do not need me to tell you which one you are closer to: run the ten-pull-request check from earlier, read your own control narrative back against it, and you will have your honest answer within an afternoon.