The Trust Problem in AI Test Failure

In Stack Overflow’s 2025 Developer Survey, 84% of developers said they use or plan to use AI tools in their workflow, up from 76% the year before. In the same survey, 46% said they actively distrust the accuracy of what those tools produce, against 33% who trust it.  

Adoption went up, trust went down, at the same time. 

That is not phase. It is what happens when a large population of skilled people uses a tool long enough to calibrate it. 

The trust paradox is a rational response 

Google’s 2025 DORA report found the same split from a different angle: more than 80% of developers reported that AI increased their productivity, while 30% reported little or no trust in the code it generates. Useful and unreliable are not mutually exclusive, and developers have priced both. 

The most experienced people are the most skeptical. Stack Overflow’s data shows developers with the most experience reporting the lowest rates of high trust and the highest rates of high distrust. That is worth sitting with, because those are the people who will evaluate any AI capability you put in front of an engineering organization and they are not going to be persuaded by a confident-sounding answer. 

Failure analysis is where cheap skepticism gets expensive 

A lot of the AI in a developer workflow is low stakes to verify. If a code suggestion is wrong, you find out quickly, and the cost is a few minutes. 

Test failure triage does not work that way. When something fails, the question is not only what broke but which layer broke — the application, the automation script, the device, or the environment. That answer determines who picks the work up. Get it wrong and you have not lost a few minutes; you have routed a defect to the wrong team, spent a cycle on it, and delivered the failure back where it started with a day gone. 

The signals are already there. Everything needed to explain the failure is captured with the run — script, device logs, server-side logs, whatever the app recorded on its way down. The evidence isn’t missing; the analysis is. Which is why it still falls to a person to open the artifacts, decide which few hundred lines matter, and paste those. 

If software is going to do that analysis instead, the bar is higher than “usually right.” It must be something you can trust. The question isn’t whether the model is accurate, it’s whether the system can show you its work well enough that you can decide for yourself. 

A confidence score should measure evidence 

Most confidence scores in AI products measure the wrong thing: how certain the model sounds. Language models are very good at sounding certain. That number tells you how fluent the answer is, not whether it’s right. 

A better score measures the evidence. It should go up when several separate sources point at the same failure. It should go up when there’s a real error message instead of a guess based on a timeout, and when you can follow the sequence from what set it off to what finally broke. 

And it should go down when a log source was missing, when only one source backs the conclusion, or when another explanation couldn’t be ruled out. 

 

Confidence as a measure of corroboration — what pushes the score up, what pulls it down, and how the bands read. 

The tell is whether the number ever goes down 

A scoring system that never reports low confidence is decoration. If every analysis comes back high, the score isn’t measuring anything. A real one drops when the data is thin: when a log source is missing, it says so instead of filling in the gap. 

Nobody wants to demo the screen where the tool says it isn’t sure. But that’s the screen engineers believe, because it matches how investigations actually go. A tool that admits when it doesn’t know is showing you it has a limit, and you can trust it inside that limit. 

Three questions worth asking any vendor, including us 

Every vendor in test automation now claims their AI explains failures. The claim is not a differentiator; the evidence behind it is. Three questions separate them quickly: 

• “When the analysis is wrong, how would I find out?” If the only answer is “you would investigate it yourself,” the tool has not saved the investigation, it has added a step to it. 

• “Show me a low-confidence result.” Not a curated one. If nothing in the demo environment scores low, ask what it would take to produce one. 

• “What did the analysis actually read?” This is the one that matters most, and it is why pasting logs into a general-purpose model has a ceiling. That model only sees what somebody managed to export. An analysis is bounded by its inputs, and you should know what those were. 

The shift 

The useful question about AI in testing has changed and so has the job it’s being asked to do. The point was never to take the engineer out of the decision. Naming the layer is a judgment call with real consequences, and judgment is the part that should stay human. 

What shouldn’t stay human is the reading. Opening the artifacts, working out which few hundred lines matter, reconstructing the sequence, that’s the work software should absorb, so the person deciding starts with the evidence assembled rather than spending an afternoon assembling it. 

That’s also why a score that goes down matters. A confidence number that drops when a log source was missing is the system handing the decision back: this one needs you. A tool that never does that isn’t keeping a human in the loop. It’s hoping nobody checks. 

Nobody trusts a model because it was described as trustworthy. They trust it because they were shown enough to judge for themselves.  

Where this connects to what we build. AI-Powered Root Cause Analysis in Digital.ai Testing analyzes Appium test failures across iOS and Android from the artifacts behind the run, and returns a probable cause, a confidence score built on evidence agreement, and the specific log line or step behind it. The confidence number goes down when the data is thin. That is deliberate. 

Explore Digital.ai Testing Premium.

Sources & References 

Stack Overflow, 2025 Developer Survey — AI section — 84% use or plan to use AI tools, up from 76%; 46% distrust the accuracy of AI output versus 33% who trust it; distrust highest among the most experienced developers (20.7% “highly distrust”). 

Google Cloud / DORA, State of AI-assisted Software Development 2025 — more than 80% report AI increased their productivity; 30% report little or no trust in AI-generated code.