The question everyone is asking about AI-generated code is whether developers verify it before merging. It's the wrong question. The more urgent problem, visible in Sonar's 2026 State of Code survey, is that a meaningful share of AI-generated code making its way into production was written with tools no one in the organization ever approved.
Sonar surveyed over 1,100 developers globally this year. The numbers: 72% of developers who have tried AI use it daily, and AI now accounts for 42% of all committed code. Developers expect that to reach 65% by 2027.
But the finding buried in the report is the one that should be on the agenda: 35% of developers access AI coding tools through personal accounts rather than work-sanctioned ones.
Do the math. If 42% of committed code is AI-generated, and 35% of AI usage is bypassing organizational channels, then a meaningful portion of what's in your production codebase was generated by models your security team never evaluated, under terms of service your legal team never reviewed, with data handling policies your compliance team doesn't know exist.
The Review Burden Is Already Inverted
Here's the compounding problem. The same Sonar survey found that 38% of developers say reviewing AI-generated code requires more effort than reviewing code written by a human colleague. Not less. More.
That flips the standard productivity argument. The case for AI coding tools has always included a review dividend: if developers write twice as much code, the organization gets twice the output with roughly the same review capacity. But if reviewing AI-generated code is harder per PR, then more AI output doesn't reduce review load — it increases it.
Pair that with the 42% figure. Nearly half of committed code is AI-generated. Reviewing it takes more effort per line than reviewing human code. And 96% of developers don't fully trust AI-generated code, but only 48% always verify it before committing.
The math is uncomfortable. AI is generating more code. More of it requires harder review. More than half hits the repo without consistent verification. And a third of it came from tools the organization has no audit trail for.
What Provenance Actually Means
When a vulnerability shows up in human-written code, the trail is clear. The commit has an author. The PR has a reviewer. The review conversation is in the history. You can ask the developer what they were thinking, what tests they ran, what edge cases they considered.
When a vulnerability surfaces in AI-generated code written with a developer's personal account, you have none of that. You know who committed it. You don't know what prompt produced it, which model version, what context the model had, or what the developer actually read before accepting. The diff shows the change. The history doesn't show the origin or the process.
That's a new kind of accountability gap. "This code wasn't reviewed carefully enough" and "we can't reconstruct how this code was generated" are different problems with different responses. Most organizations are only equipped to handle the first.
Why Governance Can't Catch Up
The 35% shadow AI number isn't surprising when you look at the incentive structure. Developers who have internalized specific AI tools — a model they've tuned their prompting style around, a workflow built on Claude or GPT-4o or Gemini — don't abandon that setup because their employer hasn't approved it yet. They continue using what makes them faster and route around the policy gap.
IT and security approval processes for AI tools are slow. The tools move fast. By the time an enterprise security team completes an evaluation, the model the evaluation covered may already have been deprecated. The developer using the same tool on a personal account has moved to the next version. The organizational process never catches up because the tools don't stop changing.
The Info-Tech Research Group published a complementary data point in July: only 37.4% of developers describe their organization's AI maturity at the build stage as formal or better. The rest are generating code that touches production without standard review or governance frameworks. The code is shipping. The governance isn't there.
This is shadow IT all over again. In 2012, developers were using Dropbox before their employers had cloud storage policies. Same dynamic: developers adopt tools that make them faster, approval processes lag, and by the time anyone notices, the pattern is entrenched. The difference is that the code generated by shadow AI doesn't just live in a shared folder — it lives in the production codebase.
The Measurement Systems Are Blind to This
The conventional metrics for AI coding productivity — accepted suggestion rate, PR count, lines generated — were designed around tools that organizations deployed and could monitor. They assume organizational visibility into what tools are running, by whom, for what.
Shadow AI breaks that assumption. If a third of your AI coding activity is happening through personal accounts, your productivity dashboards are measuring two-thirds of the AI usage. The other third is still shaping the codebase. It's just not in the data you're using to make decisions.
This isn't a problem of individual developers doing something wrong. It's a structural gap between adoption speed and accountability infrastructure. Developers are moving faster than the organizational systems that were supposed to track what fast looks like.
At xeve, we track time at the application level — which tools are running, for how long, in what order. We can tell you whether a developer is in Cursor versus VS Code versus Claude Desktop. We can't tell you whether they're using a personal API key or a company account, and we can't reconstruct the prompts or model versions behind what they shipped. That's an honest acknowledgment of what app-level telemetry can and can't see. The gap between what's trackable and what matters for code provenance is real.
The Projection Makes This Urgent Now
Forty-two percent today, 65% by 2027. That projection isn't just a scale increase — it's a governance problem that compounds. If the shadow AI portion of that 42% is already 35%, there's no structural reason it would shrink as total AI code volume grows. The developers most deeply invested in specific AI workflows are also the ones who've spent the most time optimizing their personal setups. Those setups don't map neatly to whatever an employer managed to evaluate on an 18-month approval cycle.
At 65% AI-generated code, a majority of your codebase was written with AI assistance. If you don't have clear answers to which tools generated it, under what policies, with what model versions — that accountability gap isn't an edge case problem anymore. It's the default state of the codebase.
The Question to Ask First
"Is AI-generated code verified before it's committed?" is a question about individual developer behavior. The 48% consistent verification rate tells you: inconsistently.
"Which AI tools generated the code in your codebase, and did your organization evaluate those tools?" is a question about organizational posture. Most organizations don't have a clean answer. They know what tools they've approved. They don't know what's in use.
The verification question is worth asking. The provenance question is worth asking first.