Not One of 300 QA Engineers Fully Trusts AI-Generated Code

Three hundred QA engineers were asked to rate their trust in AI-generated code on a five-point scale. Zero of them gave it a five.

That finding is from DeviQA's State of AI-Generated Code 2026, published in late July. The mean score was 3.16, which sounds like mild ambivalence until you look at how it's distributed: 3.2% rated their trust at 1, 6.5% at 2, 61.3% at 3, and 29.0% at 4. The average isn't the story. The story is the empty column at the top – three hundred people whose entire job is finding out whether software works, and not one of them willing to say they fully trust what the machine wrote.

Among the most experienced respondents, the ones with eight or more years in the work, not a single person said AI-generated code contains fewer bugs than human-written code. Not one.

Where the work went

The rest of the survey explains why. 52% of these engineers report that bug volume has increased since developers started using AI, against 2% who report a decrease. 58.1% say their own testing workload has grown – about a quarter of those calling the increase significant. And 65% are working with development teams that use AI to generate code actively, with another 16% seeing occasional use, so this isn't a fringe sample reporting on an experiment.

Then there's the line that makes it a management problem rather than a tooling problem. DeviQA reports that none of its respondents saw additional QA headcount added in response.

More code arriving, more defects in it, more testing required to catch them, and the same number of people to do it.

I want to be careful here, because every quantitative source in this piece has a commercial stake in its own conclusion. DeviQA sells QA services. Checksum sells test generation. New Relic sells observability. Each of them profits if you believe AI-generated code needs more checking. That's a real reason for skepticism, and it's also why the convergence matters more than any single number – three vendors with different products, different respondents, and different incentives are describing the same shape.

Checksum surveyed 105 engineering leaders and found 61% had shipped a production incident originating in AI-generated code within the previous 90 days, and 74.3% had rolled back AI-generated code because it failed in a way their unit tests didn't catch. 28.6% said their most senior engineers now spend more time reviewing code than building software.

The most interesting number in that set is the last one: only 28.6% believe hiring more reviewers would solve the review burden. The people closest to the problem have already worked out that this isn't a staffing shortfall.

The two numbers that should be impossible together

New Relic's survey of technology leaders produced a pair of findings that shouldn't coexist. 94% rate AI-generated code as higher quality than human-authored code at the moment it is reviewed. And 78% report a measurable spike in production incidents directly tied to AI code.

Read those twice. The code looks better than what humans write, right up until it runs.

That's a genuinely new failure mode and it's worth naming precisely. For most of the history of this craft, "reads clean" was a decent proxy for "is correct." Sloppy code looked sloppy. You could smell a problem in the shape of a function before you could articulate it, and code review worked as well as it did because human authorship left human fingerprints – the confusion, the shortcut, the thing written at 11pm. AI-generated code has no fingerprints. It is uniformly, confidently well-formed, and the tell that reviewers spent twenty years learning to read is simply absent.

New Relic puts the consequence at roughly 1.7 times more critical runtime issues than peer-reviewed human-authored code. SonarSource found that 96% of developers don't fully trust AI-generated code is functionally correct, and 38% say reviewing it takes more effort than reviewing a colleague's work.

So the proxy broke, and the review got harder, and nobody added capacity anywhere.

Look upstream

Here's the diagnostic instinct I'd offer, and it's the one I reach for more than any other: when everything downstream is failing, look upstream.

A few years ago I was brought into an 80-person product organization that was badly behind. The story I got on the way in was the story I am almost always handed – engineering is the bottleneck, the engineers aren't pulling their weight. On my first day I started pointing at work in progress and asking a question that sounds too simple to be useful: why are you building this?

Nobody could answer. Not the engineers, which I expected. But also not the business analyst, and not the junior PM whose entire job was to know. Both were early in their careers, both were well-meaning, and neither had the support the role required. The deep product thinking – who this is for, what problem it solves, whether it's worth building at all – had never been done at the top of the funnel. So design couldn't design against requirements that didn't exist, and engineering couldn't build against designs that kept moving. The engineers looked like the problem because they were standing at the bottom of the waterfall, up to their necks in everything that had gone wrong above them.

In my engagements, what presents as a talent or performance problem turns out to be a systems problem about 98% of the time. If people are showing up and trying to do the job and things still aren't going well, it's the system almost every time.

QA is standing in that same water right now. The function looks slow, or expensive, or like it's become the thing holding up releases – and it is downstream of a decision made somewhere else entirely, which was to multiply the volume of code entering the pipeline without touching the capacity to verify any of it.

Why your dashboard shows a gain

The uncomfortable part is that none of this shows up where leadership looks.

Developer throughput is measured. Commits, pull requests, cycle time, story points if you're still counting them – all instrumented, all trending up, all going in a deck. The testing burden that absorbed the difference is not on that deck. QA headcount didn't change, so there's no budget line that moved. The bugs that got caught never became incidents, so they never generated a number. The senior engineers now spending their days in review instead of building are still counted as engineers.

What you are looking at, in a lot of organizations, is a transfer being reported as a gain. The cost didn't disappear when the authoring got fast. It moved to a place your instrumentation doesn't reach, and the people absorbing it have no mechanism to tell you except by getting slower, which reads on your dashboard as QA being the problem.

That's the trap. The measurement system will keep telling you the AI investment is working right up until the thing it broke becomes visible as an incident, and by then the story will be that testing failed.

What to do about it

Instrument the whole path, not the fast part of it. If you can tell me your commit volume but not your defect escape rate, your testing hours per release, or how much of your senior engineers' week now goes to review, you've measured the stage AI accelerated and left the stage it loaded.

Then ask your QA people directly, because they already know. Not through a satisfaction survey – ask what's changed in the last year about the defects they're finding. The DeviQA respondents describe subtle logic errors, unhandled edge cases, and regressions surfacing in previously stable components. Those are expensive to find and they don't announce themselves.

And treat "we'll hire more reviewers" with the skepticism the practitioners already have. Only 28.6% of engineering leaders think that fixes it, and they're right, because more reviewers applied to an unchanged pipeline is more people doing a job whose central proxy stopped working.

Three hundred people who test software for a living looked at what the machine writes and not one of them signed off on it. They're not being precious. They're the ones who have to find out.