Can You Trust AI-Generated Code? What the Data Shows

Can You Trust AI-Generated Code?

No. AI-generated code earns trust one task at a time, never by default. Veracode measured a 56% average security pass rate across models in 2026, so roughly two in five tasks ship a real flaw.^[1]

What matters is whether a specific change can be checked before it reaches users. The expensive failure mode is a model that answers confidently and wrongly, in code that compiles and reads well.

Sonar surveyed over 1,100 developers and found 96% do not fully trust AI-generated code to be functionally correct, while only 48% always check it before committing.^[2] That gap between stated distrust and actual checking is the practical risk.

How Reliable Is AI-Generated Code?

Reliability tracks the task, not the model. Sonar reports AI now writes 42% of committed code, and 38% of developers say reviewing that code costs more effort than reviewing a colleague's work.^[2]

Four independent measurements from 2025 and 2026 point the same way. Each one uses a different method, which is what makes the pattern worth acting on.

Stack Overflow's 2025 Developer Survey adds the sentiment reading. 84% of developers use or plan to use AI tools, up from 76% a year earlier.^[3] Distrust in the accuracy of that output reached 46%.^[4] Adoption and confidence are moving in opposite directions.

Why Does AI-Generated Code Look Correct When It Is Not?

A model reproduces the surface of correct code better than the reasoning behind it. Naming, structure, and idiom are learned patterns, so plausibility arrives first and correctness is not guaranteed.

This is why review misfires. A human reviewer scans for the signals that usually indicate care: consistent naming, sensible decomposition, handled error branches. Generated code produces those signals cheaply, so the strongest heuristic a reviewer relies on is exactly the one the model satisfies best.

In the Reddit thread "Today I announced that I won't be reviewing AI generated PRs at company meeting" on r/ExperiencedDevs, an engineer stopped reviewing Claude Code changes sent to a Rails and Vue service, because the code looked plausible and its authors could not explain it. He concluded that review breaks down when the reviewer is the only person reasoning about the system.

The same asymmetry shows up in repository data. A study of 22,953 pull requests from 1,719 developers using AI assistance found that lower-experience authors submitted 2.15 times more commits per pull request and drew 4.52 times more review comments than higher-experience authors.^[5] Generation got cheaper; verification did not.

The practical consequence is that reading a diff is no longer sufficient evidence. For a deeper split between the two activities, see ai code review vs verification, which separates judging how code looks from proving what it does.

What Are the Security Risks in AI-Generated Code?

Injection flaws and invented dependencies. Veracode measured 15% and 12% pass rates on cross-site scripting and log injection in 2026, against 83% on SQL injection and 87% on cryptography.^[1]

That spread is the useful detail. Models handle the vulnerability classes that are heavily documented and heavily linted, and fail on the classes that depend on context the model does not have, such as which string reaches a template and which reaches a log.

• Cross-site scripting: Passed 15% of Veracode's 2026 tasks, because escaping depends on the output context rather than on the line being written.
• Log injection: Passed 12%, the weakest category measured, and the one least likely to be caught by a reviewer reading for logic.
• Package hallucination: A USENIX Security 2025 study of 576,000 generated samples across 16 models found invented package names in at least 5.2% of commercial-model outputs and 21.7% of open-source-model outputs, producing 205,474 unique fake names.^[6]
• Missing authorization defaults: CVE-2025-48757 scored 9.3 and let unauthenticated attackers read or write arbitrary database tables of sites generated by Lovable, through an insufficient row-level security policy.^[7]

Package hallucination is the one that scales into a supply-chain attack. The invented names repeat across runs, so an attacker can register a hallucinated package and wait for the next developer to install it. A dependency allowlist and a lockfile review close this route; a code reviewer reading for logic will not.

Does AI-Generated Code Make Developers Faster?

Not reliably. METR's randomised controlled trial found 16 experienced developers took 19% longer to close issues on their own repositories, while estimating they had gone 20% faster.^[8]

The design is what gives the result its weight. Each of 246 real issues was randomly assigned to allow or forbid AI, on repositories the developers already maintained, averaging over 22,000 stars and a million lines of code.^[8] These were experts working in code they knew well, which is the condition where AI assistance should look best.

Google's 2025 DORA report surveyed nearly 5,000 technology professionals and records 90% AI adoption. Trust splits underneath that number: 24% report a great deal or a lot of trust in AI, and 30% trust it a little or not at all.^[9] Adoption is nearly universal; confidence is not.

Stop treating perceived speed as a measurement. Baseline your team's cycle time and escaped-defect rate before adopting an agent, then compare the same two numbers afterwards. Self-reported velocity was wrong by 39 percentage points in a controlled trial.

Note: Verify AI-written changes in a real browser before they merge with TestMu AI. Try free!

What Does AI-Generated Code Do to Maintainability?

AI-generated code trades refactoring for duplication. GitClear's analysis of 211 million lines found blocks of five or more duplicated lines rose eightfold in 2024, while moved lines fell 39.9%.^[10]

2024 was also the first year on record where copied lines outnumbered moved lines.^[10] That inversion is the maintainability signal, because moving code means a developer understood two call sites well enough to unify them, and copying means nobody did.

The mechanism is straightforward. An agent given a narrow instruction produces a local solution, and duplicating an existing block is the lowest-risk way to satisfy that instruction. Refactoring requires reasoning about code the agent was never asked to change, so it does not happen unless somebody asks for it.

This debt is invisible at merge time and expensive at change time. A duplicated validation rule passes every test until the rule changes and only three of its five copies get updated.

When Can You Trust AI-Generated Code in Production?

Trust AI-generated code where the task is narrow, the correct answer is already known, and a cheap check can prove it. Withhold trust on authentication, payments, data deletion, and schema migrations.

Two properties decide the call: whether you can state the correct outcome in advance, and whether verifying it costs less than writing the code yourself. When both hold, accepting generated code is rational. When either fails, you are approving something you cannot evaluate.

• Reasonable to accept: Boilerplate, data-shape conversions, test scaffolding, and framework glue where the expected output is unambiguous and a unit test settles it.
• Accept after behavioural checks: User-facing flows, form validation, and routing changes, where the code can be correct and the rendered result still wrong.
• Do not accept on review alone: Authorization rules, payment paths, migrations, and deletion logic, where a plausible-looking error is both silent and unrecoverable.
• Never accept: Any change the submitter cannot explain, which is the line the r/ExperiencedDevs thread settled on independently of tooling.

Blast radius is the tiebreaker. A wrong colour token is cheap to discover and cheap to fix, so generated code is a good trade there. A wrong row-level security policy is neither, which is precisely the shape of CVE-2025-48757. Controls that run before the agent acts are covered in pre action checks ai coding agents.

How to Verify AI-Generated Code Before It Ships?

Run the application and observe it. Unit tests, type checks, and linters read the same text the model wrote, so they miss broken redirects, dead buttons, and forms that never validate.

This is a structural limit rather than a tooling gap. An AI coding agent reads source, writes source, and reasons about source, and every verification primitive it reaches for operates on that same closed surface. When the agent reports "passed", it is reporting on the code, not on the rendered result a user would meet.

• Assert user-visible outcomes: Check that the page loaded, the redirect landed on the right URL, and the modal closed, rather than that a function returned a value.
• Derive checks from the specification: A test written from the same interpretation that produced the code inherits its misreading, so at least one check should come from the requirement.
• Scope to the changed flows: Gate the merge on the journeys the diff touches and run the wider suite after merge, or verification becomes the slowest step and gets disabled.
• Keep an auditable artifact: Store the observed end state and the console errors with the pull request, so a reviewer can judge the run without repeating it.

Teams hitting this gap need a verifier that does not share the agent's blind spot. TestMu AI's Kane CLI drives a real Chrome browser from a natural-language objective and reports what it observed, so the check runs on the rendered application rather than on the source. Capabilities that matter for reviewing generated changes:

• Vision-based dynamic waiting: Kane CLI watches the rendered viewport instead of network or DOM signals, which is what keeps it working on canvas elements, shadow DOM, and frameworks that lazy-render or stream the UI.
• Confidence-scored matching: Every element match reports a confidence score, and low-confidence matches are rejected up front rather than clicking the wrong element and quietly passing.
• Stable CI exit codes: Runs return 0 for passed, 1 for failed, 2 for error, and 3 for timeout, so a pipeline can branch on the result without a human reading logs.

The kane cli getting started guide covers installation, authentication, and a first run.

The demo below shows the pattern end to end: Lovable generates a live waitlist landing page, and Kane CLI verifies it in a browser with no test script written by hand.

Kane CLI does not review code and does not replace unit tests, which stay the cheapest way to pin logic at function level. It covers the layer those tests structurally cannot reach. For wiring this into a merge gate, see continuous verification ai code, and for the limits of agent self-checking, can coding agents test their own code.

Conclusion

Start by picking one user-facing flow your team changed with an agent last week and running it in a browser to confirm it still behaves. The answer to whether you can trust AI-generated code is decided by that check, not by the model on the other end of the prompt.

The measurements agree across methods. Security has stayed flat at a 56% pass rate while capability climbed.^[1] Duplication rose as refactoring fell, and a controlled trial found experienced developers slower even as they felt faster. None of that argues for abandoning AI assistance, and all of it argues for a verification step that does not depend on the same interpretation that wrote the code.

Teams comparing assistants on how checkable their output is will find that in ai code assistants for testing, and the review practices themselves in code review.

Sources and References Used

• [1] 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn't Caught Up - Veracode (July 2026)
• [2] Sonar Data Reveals Critical "Verification Gap" in AI Coding: 96% Don't Fully Trust Output, Yet Only 48% Verify It - Sonar (2026)
• [3] 2025 Developer Survey: AI - Stack Overflow (2025)
• [4] Stack Overflow's 2025 Developer Survey Reveals Trust in AI at an All Time Low - Stack Overflow press release (2025)
• [5] Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding - Asdaque, Haider, Malik, Ghafoor and Bangash, MSR 2026 Mining Challenge, arXiv (February 2026)
• [6] We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs - Spracklen et al., USENIX Security Symposium (2025)
• [7] CVE-2025-48757: Lovable Insufficient Row-Level Security Policy - GitHub Advisory Database (2025)
• [8] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (July 2025)
• [9] How are developers using AI? Inside Google's 2025 DORA report - Google (2025)
• [10] AI is eroding code quality states new in-depth report, covering GitClear's AI Copilot Code Quality research - DevClass (February 2025)