Why do developers distrust AI-generated code?

Because they have used it and formed an opinion from experience rather than from theory. Stack Overflow's 2025 survey found 46 percent of developers actively distrust the accuracy of AI output while only 3 percent trust it highly, and the same survey found 66 percent naming output that is almost right as their biggest frustration.

Is developer distrust of AI a sign of resistance to change?

The adoption numbers argue against that reading, because the same people are using the tools heavily. Stack Overflow found 84 percent using or planning to use AI tools, so the people reporting distrust are mostly the people with hands-on experience, which makes the distrust a judgement rather than a refusal.

What does "almost right, but not quite" mean in practice?

It describes code that compiles, runs, and looks fine on a quick reading while containing a defect that only appears under a specific condition. This category is expensive because obviously broken output is deleted in seconds, while nearly correct output gets reviewed, debated, merged, and then turns out to be the cause of an incident weeks later.

Can training fix a team's distrust of AI tools?

Training helps with skill and prompt technique, and it does not address the underlying issue when the distrust is an accurate judgement of a real failure rate. If the output genuinely fails some of the time, the honest response is to build verification that catches those failures rather than to persuade people the failures are not there.

What does the Veracode research say about AI code quality?

Veracode's Spring 2026 study covered more than 150 models across 80 tasks in four languages and found over 95 percent of generated code compiled and ran correctly while roughly 55 percent passed security checks. The pass rates varied widely by defect class, with SQL injection at 82 percent and cross-site scripting at 15 percent.

Why does running code not prove the code is correct?

Because compiling and executing only show that the syntax and the immediate control flow work. Security defects, permission mistakes, and failures in unusual cases all leave code that runs without errors, which is why a high correctness rate can appear with a lower security pass rate in the same study.

How do you actually build trust in AI-assisted development?

By making verification visible and repeatable, so anyone on the team can run the check and see the result for themselves. That means automated checks written from the specification, deliberate failure tests that prove the checks work, and honest reporting of what the checks did not cover.

Should engineers be allowed to reject AI-generated changes?

Yes, and removing that option teaches a team that its judgement does not matter. A reviewer who can decline a change they cannot verify is doing the job correctly, and the useful follow-up question is what evidence would have made the change acceptable to them.

Does the DORA research support the trust concern?

The 2025 DORA report surveyed roughly 5,000 technology professionals and found 30 percent reporting little or no trust in AI-generated code, alongside more than 80 percent who believed AI increased their productivity. Those two findings together suggest people can find a tool useful and still doubt its output.

What is the difference between trust and calibrated trust?

Blanket trust treats every output as acceptable and blanket distrust treats every output as suspect, and both are wrong in the same way because they ignore the specific failure pattern. Calibrated trust means knowing which categories of output are reliable, which are not, and having a check that tells the difference on each change.

How long does it take for a team's trust to change?

It changes when the evidence builds up, which usually means a full quarter of watching the checks catch real defects before anyone reports feeling differently. Announcing a trust program changes nothing, while a test suite that visibly blocked a bad change last Tuesday changes a lot.

Why your team does not trust the AI output: Reveneau

There is a conversation that happens in most engineering organisations adopting AI tools, and it goes the same way every time. Leadership is enthusiastic. The tools are paid for. And a group of experienced engineers is quietly unconvinced, phrasing it carefully in meetings and bluntly in private.

The usual interpretation is that these people are slow to adapt. That interpretation is comfortable and it is wrong.

Distrust of AI output is generally accurate. The people expressing it have used the tools more than anyone, they have had problems of a specific and repeatable kind, and their judgement is closer to the measured results than the enthusiasm coming from leadership. Treating that as a culture problem wastes the most useful information in the company.

The numbers say this is a judgement, not a habit

Start with adoption, because it answers the question of whether people are avoiding the tools. Stack Overflow's 2025 developer survey found 84 percent of respondents using or planning to use AI tools. That is a group of people who are open to the tools.

Now the same survey's trust question. 46 percent actively distrust the accuracy of AI output, 33 percent trust it, and only 3 percent trust it highly. So the group is using the tools daily and rating them poorly at the same time. That combination only makes sense one way: they use them because the tools help, and they distrust them because the tools are also wrong often enough that people have learned to check.

The 2025 DORA report, based on around 5,000 technology professionals, reaches the same result from a different starting point. More than 80 percent believed AI increased their productivity, and 30 percent reported little or no trust in AI-generated code. Useful and untrustworthy are not contradictory findings. Most tools with a failure rate are both.

What has actually gone wrong for them

Ask an engineer why, and you will not usually hear a story about nonsense output. You will hear about something that looked fine.

Stack Overflow's survey names it directly: 66 percent cite "almost right, but not quite" as the biggest frustration, and 45.2 percent say debugging AI-generated code takes more time than writing it themselves. Almost-right is the expensive category, and it is the one that builds lasting distrust. Code that is obviously broken costs seconds. Code that is nearly correct gets read carefully, discussed, approved, merged, and then appears as an incident a month later, at which point somebody has to trace back through a change nobody remembers making a decision about.

The security data shows the same pattern. Veracode's Spring 2026 research tested more than 150 models across 80 tasks in four languages. Over 95 percent of generated code compiled and ran correctly. Roughly 55 percent passed security checks. Broken out by class, SQL injection passed 82 percent of the time and insecure cryptography 86 percent, while cross-site scripting passed 15 percent and log injection 13 percent. Language mattered too: Python at 62 percent, C# at 58, JavaScript at 57, Java at 29.

Put those two facts next to each other. The code almost always runs. It is secure a little more than half the time. Running was never the property anyone needed, and it is the property that is easiest to observe, which is exactly why a defect gets through a review that felt thorough.

There is a third finding worth thinking about. METR ran a randomised study in July 2025 with 16 experienced open-source developers working on their own repositories. The developers expected to be 24 percent faster with AI assistance. They were 19 percent slower, and afterwards still believed they had been 20 percent faster. Sixteen developers is a small sample and the authors say so. What it demonstrates is not a universal slowdown but something more uncomfortable: how fast people feel they are working and how fast they measure as working can be opposite. Which means the confident people in the meeting may be no more accurate than the sceptics, and often less.

Why persuasion does not work here

The instinct when a team is unconvinced is to run a session. Show the wins, share the good examples, explain the technique.

That approach assumes the problem is missing information. It is not. Everyone in the meeting has already run the tool, and each of them is holding a private memory of the time it produced something plausible and wrong. A slide presentation does not change that memory, and an engineer whose scepticism is overruled rather than answered does not become convinced. They stop speaking up, which looks like progress and is worse than the argument.

Persuasion also asks the wrong thing of people. You are effectively requesting that they lower their standard for evidence, on your authority. Every good reviewer's instinct will refuse, and you would not want to work with the ones who agree.

What does change it

Verification the team can see, run, and break themselves.

Write checks from the specification, not from the code. A check derived from the implementation confirms the implementation does what it does. A check derived from the specification says what the software must guarantee and fails when the guarantee breaks, whoever or whatever wrote the change. Our method for this is in how to write your first eval suite, and the harder problem of adding it to software that already exists is in adding evals to an existing codebase.

Prove the checks can fail. This is the step teams skip and it is the one that builds trust. Break something deliberately, in front of people, and confirm the suite catches it. A report where every check passes means nothing until someone has watched a check fail for a real reason. The ways this goes wrong are listed in when evals give false confidence.

Report the failures out loud. Teams build trust from seeing what got caught, not from a summary saying everything passed. Publish the defects the checks blocked this month. That record is the argument, and nobody has to simply believe it.

Keep the right to say no. A reviewer who declines a change they cannot verify is doing the job properly. The productive response is a question rather than an override: what evidence would make this acceptable to you? The answer is usually a specific check, which is a task you can complete, and then the objection is answered with something that lasts. More on the approach to review itself is in how to review AI-generated code.

Trust that matches the evidence is the actual goal

Blanket trust and blanket distrust fail in the same way: both ignore the pattern.

The Veracode results are the useful pattern to remember. Some categories of output are reliable enough to accept with a normal review. Others fail most of the time and need a check that runs on every change without a human deciding to look. A team that knows which is which reads faster, argues less, and catches more, because attention goes where the evidence says it should.

That is what earned trust looks like: a team that can name the specific check that covers the specific risk, and then continue with the work.

The uncomfortable part for leadership

The DORA report's summary line is the one to keep: "AI doesn't fix a team; it amplifies what's already there". If review was weak before the tools arrived, more output makes it weaker faster. If your engineers do not trust the output and there is no mechanism for them to check it, that distrust is the correct response and it will not go away on a schedule.

The distrust is data. It tells you the checks are missing before an incident does. We have written more about that pattern in AI is an amplifier, not a fix.

Thanks to the engineers who kept saying they were not sure, in meetings where that was not the popular position. Every time, the problem they could not name exactly turned out to be a check nobody had written.

Nobody starts trusting a system because of an argument. They watch it fail on purpose, and then they believe it.

Related guide: Moving a team to AI-native development.

Sources

Stack Overflow 2025 Developer Survey, AI section: 84 percent using or planning to use AI tools; 46 percent actively distrust accuracy against 33 percent who trust it and 3 percent who trust it highly; 66 percent cite "almost right, but not quite"; 45.2 percent say debugging AI code is more time-consuming.
2025 DORA report announcement, Google Cloud: roughly 5,000 respondents; more than 80 percent believe AI increased productivity while 30 percent report little or no trust in AI-generated code; AI amplifies a team's existing strengths and dysfunctions.
Veracode, Spring 2026 GenAI Code Security update: more than 150 models across 80 tasks in four languages; over 95 percent compiled and ran correctly against roughly 55 percent security pass rate; SQL injection 82 percent, insecure cryptography 86 percent, cross-site scripting 15 percent, log injection 13 percent.
METR, early 2025 AI and experienced open-source developer study: 16 experienced developers were 19 percent slower with AI assistance despite expecting 24 percent faster and believing afterwards they had been 20 percent faster.

Why your team does not trust the AI output