AI-Generated Code Quality: Why It Passes Review and Fails in Production

Is AI-generated code lower quality than human code?

Direct Summary

Surveyed technology leaders rate AI-generated code higher than human code at review, yet most also report more production incidents. A vendor-commissioned survey of 200 US leaders shows the pattern. Independent studies agree on direction, not size, and none proves AI causes the incidents.

Technical Nuance & Operational Realities

The headline numbers come from a survey, so they describe what leaders believe and report, not what production systems logged. New Relic commissioned the survey from Hanover Research, and New Relic sells observability software. Treat every survey percentage on this page as a self-report.

The independent evidence measures different things. CodeRabbit counted review findings per pull request, METR timed developers on real tasks, DORA surveyed professionals about delivery performance, and Veracode and a USENIX Security paper tested what models produce in controlled tasks. Each supports a narrow conclusion. None measures, across many organizations, whether AI-written code causes more outages than human-written code.

This matters for superintelligence because the pattern is a small, observable case of the oversight problem: systems that produce work faster than people can check it. It does not show that superintelligence is near. Google's chief executive wrote that 75% of new code at Google is AI-generated and approved by engineers, so verification, not authorship, is where human effort now goes. Our analysis: the practical response (tests, telemetry, sandboxing, independent evaluation) is a working form of what alignment researchers call scalable oversight, covered in our guide to alignment theories.

What the evidence shows

What the New Relic survey measured

New Relic's 2026 State of AI Coding report, dated June 2026, surveyed 200 US-based technology decision-makers at manager level or above. Hanover Research ran the survey and New Relic commissioned it. The sample leans toward large organizations and a few industries, and the questionnaire and raw data are not public.

Read the table as perceptions. The 67% row is the share of leaders who chose a band, not the share of code that is AI-written. The 62% row comes from the report's text, which says "often"; one chart labels it "often or always". The report does not show that AI caused the incidents. Incident counts can also rise simply because teams ship more code and more services.

What independent studies add

The Stack Overflow 2025 Developer Survey adds the trust picture: 84% of respondents use or plan to use AI tools, and 46% distrust their accuracy compared with 33% who trust it. On the other side of the ledger, Google's Sundar Pichai wrote in April 2026 that 75% of new code at Google is AI-generated and approved by engineers, up from 50% the previous fall. That counts new code only, and Google has not said how it counts.

What the data does not show

• No causal link. None of these sources isolates AI as the cause of incidents.
• No production telemetry. The New Relic figures are survey answers, not logs, traces or incident records.
• No shared definition. "AI-generated" means something different in each survey, company statement and pull-request analysis.
• No benchmark-to-production bridge. Test scores do not predict your incident rate.
• Mixed direction. The GitHub study found quality gains in a controlled task, while CodeRabbit and DORA point the other way on review findings and stability.

How to govern AI-generated code

Our analysis, not a sourced finding: govern by risk tier, not by authorship. The same baseline applies to every change, and the gates tighten where failure is costly. The New Relic survey found no organization with a blanket ban, and nothing in the sources above supports one.

Measure outcomes, not suggestions accepted

METR's developers expected a speedup and believed afterwards that they had been faster, while the measured result in 2025 was slower. Self-reports are unreliable, so track delivery outcomes and split them by whether a change was AI-assisted:

1. Change failure rate: the share of deployments that need a rollback, hotfix or patch.
2. Time to recover after a failed deployment.
3. Rework rate: unplanned fixes to recently shipped changes.
4. Escaped defects: bugs found in production per release.
5. Review depth: the share of AI-assisted changes with line-by-line human review, by tier.

Verification checklist for AI-assisted changes

• The change is labelled AI-assisted and has a risk tier.
• A human has read every changed line of logic at tier 2 and above.
• New and changed paths have tests that fail without the change.
• Every new dependency exists, is on an allowlist and is pinned. Fabricated package names are a documented attack route.
• Security scanning and secret scanning pass with no suppressed findings.
• Authentication, payment, cryptography and migration changes have two approvals.
• Logs, metrics and traces exist for the new code paths.
• A rollback or feature flag can disable the change.
• Any agent credentials used were least-privilege and have expired.

At a Glance

Figures are as printed in each primary source, read on 2026-10-21. Survey rows are self-reports.

The table is a decision aid, not a verdict. Before relying on any figure, record its date, sample, definition of "AI-generated", and who paid for the research. If a number is unavailable or not comparable, say so instead of filling the gap.

Sources & Further Reading

Every source below was fetched on 2026-10-21 unless a row says otherwise.

Left out after checking sources: the Veracode "80 tasks" count (not found on any Veracode page we could fetch); a New Relic product launch (neither the blog nor the report announces one); a critical-only 1.4 times figure for CodeRabbit (the page gives a combined critical and major range); and OpenAI's February 2026 note on SWE-bench Verified (the page blocked automated access, so we could not read it).