Trust is rising. So are the incidents.
Checksum surveyed 105 engineering leaders about the AI code their teams ship, and what happens after it merges. The findings point to one conclusion: confidence in AI code has run ahead of the ability to verify it.
78.1% of engineering leaders trust AI-generated code more than they did a year ago.
But in just the past 90 days, 61% of them shipped a production incident that originated in AI-generated code. 74.3% rolled back an AI change that broke in a way their unit tests didn't catch. 64.8% say AI code takes more review time than human code, not less.
These aren't two different groups. With 78.1% trusting more and 61% shipping incidents, at least four in ten leaders in this study are doing both: trusting AI code more while tasking their teams to clean up after it. Confidence has run ahead of verification. This report is about that gap: where it comes from, what it costs, and why the standard fixes don't reach it.
The trust paradox
Trust in AI-generated code is climbing. So is trust in the tests that are supposed to catch it when it fails: 81.9% of leaders trust their test suite more than they did 12 months ago.
Leaders aren't just more confident in the AI. They're more confident in their verification layer, while at the same time 74.3% of them rolled back changes that layer didn't catch. The trust is real, but it isn't translating into incident-free releases.
This pattern runs through the study. Teams aren't reckless. They're verifying with unit tests, code reviews, and even senior engineers reading diffs line by line. The problem is that the perimeter they trust can't always see the failures they're shipping.
And trust isn't rising over a fixed amount of code. Faros AI's telemetry across more than 10,000 developers found that teams with high AI adoption merge 98% more pull requests. Nearly double the code, trusted more, verified the same way as before. Every point of misplaced confidence now covers twice the surface area.
The failure record
In the 90 days before the study was conducted, 61% of engineering leaders shipped a production incident that originated in AI-generated code. That's not over the lifetime of their AI adoption. That's in one quarter.
Those changes passed the checks teams already had: the unit tests, the review, the CI pipeline. Green builds, but shipped incidents.
A smaller group, 4.8%, isn't sure whether their incidents trace back to AI code at all. It's a footnote in the numbers, but a telling one: if you can't tell whether AI wrote the broken code, you can't measure the gap you're operating with, let alone close it.
Zoom out past 90 days and the picture sharpens. 74.3% have rolled back an AI-generated change because it broke in a way their unit tests didn't catch. 32.4% have done it more than once. Only one team in four has avoided the experience entirely. Rollback isn't the edge case. It's the median.
The review tax
The cost of that trust paradox doesn't land in production first. It lands in review.
64.8% of leaders say AI-generated code needs more review time than human-written code before they'd merge it. Only 21.9% say it needs less. The productivity gain on the writing side is being paid back on the review side, with interest: 50.5% report their code review cycles have grown by 25% or more since adopting AI coding tools.
This isn't just how leaders feel, it's what the telemetry shows. The same Faros AI study that measured 98% more pull requests found review time on those PRs grew 91%. More often than not, the time AI saves writing code is being spent re-verifying it.
And the cost concentrates exactly where it hurts most. 28.6% of leaders say their most senior engineers now spend more time reviewing other people's code (including AI output) than building anything themselves. The people you hired to architect systems are reading diffs.
One fix would be more reviewers. But most leaders don't believe that's the answer. Only 28.6% think they could hire their way out of the review burden; 21.9% call it a structural problem that headcount can't solve at all.
They're right. Adding reviewers to a process that can't see real system behavior wastes time and increases the mental burden on engineers. One respondent named the human cost directly:
"The underlying problem is 'Reviewer Fatigue' and trust symmetry. Reviewing AI code takes longer because humans must meticulously hunt for subtle, confident hallucinations and edge-case bugs, turning peer reviews into an exhausting, high-cognitive-load debugging session rather than a standard logic check."
That's not a process problem. That's a team burning out compensating, by hand, for verification that isn't there.
The adoption-verification gap
So why is this happening? Because teams wired AI into one half of the engineering loop and not the other.
Every team in this study uses AI to write code, and most now use AI to check it too: 69.5% verify against production-like conditions, 67.6% run AI security scanning, and 61.9% use AI code review.
But while adoption is widespread, what's uneven is the mix. AI unit-test generation, the most direct counterweight to AI-written code, sits at just 48.6%, below both code review and security scanning. And none of these layers, however widely adopted, can see what production sees.
Generation is the cheap half of the loop. Real verification, the kind that catches runtime failures, is the expensive half. Teams automated the cheap half and filled the expensive half with a patchwork of AI checks and human review that still can't see production. This is exactly why the cost shows up as review time, senior-engineer hours, and rollbacks.
It's the same gap CI/CD left behind a decade ago. CI/CD automated how code moves to production, not what that code does when it gets there. AI generation poured volume into one end of that pipeline; nothing was added at the other.
The trust paradox isn't irrational exuberance. It's what happens when the tools that promise confidence arrive years before the tools that earn it.
The Context Void
The last question is why the existing verification layer, the unit tests and the reviews, keeps missing these failures. The study's root-cause data answers it.
Among the 78 leaders who had rolled back an AI change and could name a root cause, no single cause dominates. Performance and scale issues that only surface under production load lead at 23.1%. Logic errors the AI wrote follow at 21.8%. And 17.9% trace back to something more specific: the AI couldn't see how its code would interact with the rest of the system.
These problems arise when the AI writes code without seeing the environment that code will run in: the database, the third-party APIs, the production load, the data shapes, or the unwritten business logic the developer had in their head.
That blindness doesn't produce one kind of failure. It produces all of them at once, which is why no root cause dominates. The code looks right in isolation, but it breaks the moment it meets the rest of the stack.
One respondent's incident describes it better than any definition:
"Because the AI failed to take into consideration the rate constraints of a legacy inventory API, it produced a discount calculation function that functioned in unit testing but failed in production. this resulted in checkout tiimeouts lasting 20 minutes until we rolled back and manually rewrote the integration layer."
And while the root causes are spread, they share one trait: pre-merge testing can't reach any of them. From production load and cross-system interactions to real data shapes, none of these things exist at the unit-test layer. Which is why another respondent, asked what they'd fix with a magic wand, didn't ask for better tests:
"If I could wave a wand, I would fix the lack of true intent verification, meaning how we ensure AI code actually matches a developer's nuanced goals. Current tools check if code runs and passes basic tests, but they cannot verify if it aligns with complex, unwritten business logic."
What this means
AI isn't just writing the code anymore, it's checking it too. 69.5% of the teams in this study use AI to verify code in production-like conditions. But when that verification misses, and the rollback numbers say it misses often, humans pick up the pieces by hand.
The business impact is real. Review time is up for 64.8% of teams, half have lost a quarter or more of their PR cycle, and senior engineers spend their days reading diffs instead of building. The bill isn't only review time: in the last 12 months, 45.7% of teams saw AI-code issues drive up their support load and 42.9% lost engineering hours to rework.
Verification exists. But when it can't see what production sees, the cost lands on people, and most leaders know hiring alone won't fix it.
And the window for fixing it manually is closing. Teams with high AI adoption are already merging twice the pull requests they used to, and the volume curve only points one way. Every quarter the gap stays open, there's more code, more surface area, and the same number of humans absorbing the misses. This isn't a problem that holds still while you hire for it.
Fixing this doesn't mean trusting AI code less. It means verification that operates where the failures live: against real user flows, real data, real APIs, on every change. CI/CD automated how code gets delivered. Continuous verification automates how it gets proven.
The teams that get there first won't just ship fewer incidents. They'll get their senior engineers back.
Verify AI code before it's reviewed, not after it ships.
Checksum's E2E Agent automatically generates, runs, and auto-heals a production-like test suite, so AI code is verified before anyone reviews it, not debugged after it ships.
How this study was run
Checksum surveyed 105 engineering leaders through a guided interview combining structured multiple-choice and multi-select questions with open-text follow-ups. Themes in open-text responses were identified through transcript review and pattern coding.
Single-select percentages sum to 100% within rounding. Multi-select totals exceed 100% because respondents could pick more than one option. Root-cause percentages use the base of respondents who had rolled back an AI change (n=78), since that question was asked only of them. Pull-request and review-time telemetry figures (98% and 91%) are cited from Faros AI's published developer telemetry and are external to this survey. Every quote is reproduced verbatim from respondent transcripts, including original spelling.
