Skip to main content
New pricing: two plans, one meter, no feature walls.Read the announcement

RESEARCH · AUGUST 20, 2026 · 5 MIN READ

96% Distrust AI Code. Only 48% Actually Check It.

Sonar's 2026 survey of 1,100+ developers reveals a stark gap: 96% don't fully trust AI-generated code, yet only 48% consistently review it before committing.

By the Hyrax team


96% Distrust AI Code. Only 48% Actually Check It.

Sonar's 2026 State of Code survey asked more than 1,100 professional developers two simple questions. Do you trust AI-generated code? Do you review it before committing? The answers, read together, describe a quality control system that has already broken down. Nearly everyone distrusts the output. Barely half of them verify it.

The Numbers#

Sonar's 2026 State of Code survey put four figures on the table: 42% of committed code is now AI-generated or AI-assisted. 96% of developers do not fully trust what the tools produce. Only 48% always verify AI-assisted code before committing. And 38% say reviewing AI-generated code takes more effort than reviewing a colleague's.

That last number matters. If review is harder, and volume is higher, and discipline is the only enforcement mechanism, the math does not work. Something gives. What gives, according to Faros AI telemetry from 22,000 developers across 4,000+ teams, is the review itself: PRs merged without any review rose 31.3%, and the incidents-to-PR ratio rose 242.7% in the same period.

Why Discipline Is the Wrong Frame#

The 52% of developers who skip review on any given commit are not making an ethical mistake. They are making a throughput decision. Faros AI's data shows median time a PR sits in review rose 441.5% after AI coding adoption. Daily PR contexts per developer rose 67.4%. The queue is longer, each item in it demands more attention, and there are more of them arriving per day.

That is a structural problem, not a character flaw. Telling developers to review more carefully does not change the ratio of work to capacity. It just adds guilt to the existing overload.

The Cloud Security Alliance found that developers using AI coding assistants were producing commits at three to four times the rate of their peers, while introducing security findings at ten times the rate. If review volume scales with commit volume, and commit volume tripled, then a team that was previously reviewing 100% of commits at a sustainable pace now needs to review 300% of commits at the same quality bar. That is not a gap that individual effort closes.

What Goes Unreviewed#

The patterns that slip through without review are not exotic. They are the same findings that appear in any unreviewed codebase: hardcoded secrets that look like placeholder strings, error paths that are caught and silently dropped, loop bounds that are correct for the test data and wrong for production input. AI coding tools generate these at the same rate as any other author, possibly higher, because the model producing plausible-looking code has no stake in what happens at runtime.

Veracode's Spring 2026 study ran 80 coding tasks across four languages and found roughly 45% of AI-generated samples introduced an OWASP Top 10 flaw when no explicit security guidance was provided. Cross-site scripting was handled securely only 15% of the time. Log injection, 13%. The failure distribution is not uniform, which matters: a reviewer who spot-checks the parts that look obviously sensitive will miss the failure modes concentrated in the parts that look routine.

As covered in five AI-code failures your CI does not catch, standard continuous integration catches compilation errors and failing tests. It does not catch a function that swallows its exception before the test can observe it.

The Throughput Problem Has a Structural Answer#

The Sonar data does not describe a discipline gap. It describes a throughput problem. When the volume of code requiring review rises faster than the capacity to review it, review becomes selective by default. The selection is not principled , it follows whoever had enough time that day, on that PR, in that context.

A review layer that runs regardless of developer choice changes the problem. It does not ask whether the developer feels like reviewing; it runs on every commit and either clears or flags. Hyrax's Scan workflow does exactly this: it reads the full codebase across six domains (security, code quality, reliability, API and data, ops, UX), runs 13 verification steps, and submits a PR with fixes. The developer decides whether to merge. They do not decide whether the check happens.

That distinction matters when the underlying pressure is volume, not intent. A gate that depends on human discipline fails exactly when discipline is hardest to maintain, which is when output is highest and time is shortest. A gate that is structurally independent of that pressure does not.

What the Survey Does Not Settle#

Sonar's findings are self-reported. Developers saying they review 48% of the time could mean 30% or 60% when measured against actual commit logs. The Faros AI telemetry is instrumented workflow data, not self-report, which is why its numbers (31.3% unreviewed merges, 242.7% incident ratio increase) carry more weight than the survey percentages as a description of what is actually happening in repositories.

The combination is the point. Self-reported distrust at 96% plus instrumented unreviewed merges rising 31.3% do not need to be precisely accurate to support the same conclusion: review is failing as a quality gate at current AI coding volumes, and the failure is structural. Better models will not close that gap. The Veracode data makes this explicit , newer and larger models showed negligible improvement in security flaw rates. Waiting for the model to get better is not a remediation plan.

Hyrax is live at hyrax.dev.


Sources

  1. 01Sonar State of Code 2026 (via capitalandcompute.net)
  2. 02Faros AI Engineering Report 2026 (via dev.to)
  3. 03Softensity: The Bill for AI-Generated Code