AI-Generated Code in 2026: Trust, Vulnerability Rates, and the Governance Gap

Ask an engineering director whether AI-generated code is safe to ship, and the honest answer is "it depends on whether your review process scaled with the volume." That is not a comfortable answer, but it is the one the 2025-2026 data supports. Adoption is no longer the question - AI-assisted coding is now the default across most engineering organizations. The question that actually determines outcomes is what happens between generation and merge, and on that question the evidence is specific enough to act on.

Close-up of source code displayed on a computer screen, representing AI-generated code awaiting human review — Photo: Sai Kiran Anagani, CC0, via Wikimedia Commons

Is AI-generated code actually safe to ship?

Not by default. Veracode's 2025 GenAI Code Security Report, published July 30, 2025, tested more than 100 large language models against 80 curated coding tasks and found that generated code introduced a security vulnerability 45% of the time - meaning that when a model had a choice between a secure and an insecure way to write something, it picked the insecure path close to half the time. The failure rate was not uniform: Java code failed security checks in 72% of tasks, the highest of any language tested, while cross-site scripting defenses failed in 86% of relevant samples. Model size and recency did not fix this - newer, larger models showed no meaningful security improvement over older ones despite writing more functional code. The takeaway for a platform or security lead is blunt: functional correctness and secure-by-default behavior are separate properties, and AI models are optimized for the former.

Why don't engineers trust AI-generated code, even as adoption climbs?

Because the trust gap is rational, not cultural resistance. DORA's 2025 research, summarized in "Balancing AI tensions" and drawn from roughly 1,110 open-ended responses gathered from engineers in Q3 2025, found that 90% of professionals now use AI at work and over 80% report a productivity gain - yet 30% still report little to no trust in the code AI produces for them. DORA frames this as a structural asymmetry rather than a generational skill issue: the author of an AI-generated change gets to accept or reject suggestions interactively as they write, but the reviewer inherits a finished diff with none of that context and has to reconstruct intent from scratch. One engineer quoted in the research put it plainly: "Reviewing another's code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed." The report's now widely cited framing is that AI is "the great amplifier" - it does not fix a team's engineering discipline, it magnifies whatever discipline already exists, good or bad.

Is code review actually keeping up with AI-generated pull request volume?

The clearest evidence says no. GitHub's Octoverse 2025 report (published October 28, 2025) recorded the Copilot coding agent alone authoring more than 1 million pull requests between May and September 2025, against a platform-wide average of 43.2 million pull requests merged per month, up 23% year over year. Review activity did not scale with it: comments on pull requests and issues stayed essentially flat (+0.35%), while comments on commits - the more granular, line-level feedback that catches subtle bugs - fell 27%. GitHub is careful to call these "observational signals rather than causal claims," which is the right caveat, but the direction is consistent with what DORA and Veracode independently describe: more code is moving through the pipeline, and the depth of human scrutiny per change is not moving with it. That combination - a 45% baseline vulnerability rate in generated code, a reviewer trust deficit, and declining per-commit review depth - is exactly the setup that produces the "high throughput, falling stability" pattern DORA has now tracked across two consecutive annual reports.

What does AI code governance actually require in 2026?

Not a ban, and not a shrug. Three things that are already showing up in mature engineering organizations:

Risk-scaled review, not uniform review. Treat AI-authored diffs the way you would treat a pull request from a capable but unvetted junior engineer: inspect the diff, run the tests, check edge cases, and require a second sign-off on anything that touches auth, payments, data access, or infrastructure-as-code. Low-risk, well-tested internal tooling does not need the same bar as a change to a customer-facing API.
Security scanning in the loop, not after it. Given a 45% baseline vulnerability rate and a 72% failure rate in one of the most common enterprise languages, static analysis and dependency scanning need to run on every AI-assisted change before merge, not as a periodic audit. Treat AI output as untrusted input to your existing supply chain controls, the same posture regulated teams already apply to third-party dependencies.
An inventory of where AI is actually used. You cannot govern what you cannot see. Knowing which repositories, which agents, and which secrets and code paths are exposed to AI tooling is the precondition for any policy that follows - approved tools, restricted use cases, and rules for what an agent is permitted to touch unsupervised.

None of this is exotic. It is the same discipline DORA has documented for a decade - fast feedback, small batches, automated checks before merge - applied to a new source of change. The organizations DORA classifies as strong performers are not the ones avoiding AI; they are the ones whose existing review and testing discipline was strong enough to absorb a 20-fold increase in the rate at which code shows up asking to be reviewed.

The practical bar for 2026

If your team has adopted AI coding assistants or agents without also re-examining who reviews their output, at what depth, and with what security tooling in front of the merge button, you are running the exact configuration the data says produces more throughput and less stability. The fix is not slowing AI adoption down. It is making sure code review capacity, security scanning, and an accurate inventory of where AI touches your codebase scale at the same rate the pull requests do.