Short answer
Developers distrust AI code because it is often almost right: in Stack Overflow's 2025 survey 46% distrusted AI accuracy and only 33% trusted it. That distrust is rational. Trust should come from evidence the pipeline produces (builds, tests, independent review, a track record), not from the model's confidence.
You use an AI assistant every day, and you still read every line it writes. Sometimes twice. A teammate says the agent “just works” for them, and you wonder whether they are braver than you or simply not looking.
You are not being paranoid. The people who measure this find the same thing you feel: usage keeps going up and trust keeps going down. The interesting question is not whether to trust AI code. It is what would have to be true for trust to be the reasonable position.
Trust in AI coding tools is falling while use rises
Stack Overflow has asked developers about AI tools for three years running. In 2025, 84% of respondents were using or planning to use them, up from 76% the year before, and 51% of professional developers used them daily. Over the same period, the share who view the tools favourably fell from 77% in 2023 to 72% in 2024 and 60% in 2025.
The accuracy question is sharper. In 2024, 43% said they trusted the accuracy of AI output and 30% distrusted it. In 2025 the lines crossed: 33% trusted, 46% distrusted.
More developers use AI tools, fewer trust what they produce
Share of all respondents, Stack Overflow Developer Survey
- Favourable towards AI tools
- Trust accuracy
- Distrust accuracy
Data as a table
| Favourable towards AI tools | Trust accuracy | Distrust accuracy | |
|---|---|---|---|
| 2023 | 77% | — | — |
| 2024 | 72% | 43% | 30% |
| 2025 | 60% | 33% | 46% |
Google’s DORA 2025 survey of nearly 5,000 technology professionals found the same split from a different angle. Adoption reached 90%, and over 80% said AI had made them more productive. Yet only 24% reported a great deal or a lot of trust in it, while 30% trusted it a little or not at all. Google called it a trust paradox. I don’t think it is a paradox at all. People use tools they don’t trust all the time. They just check the output.
“Almost right” is the real complaint
When Stack Overflow asked what frustrates developers about AI tools, the top answer was not “it’s wrong”. It was “AI solutions that are almost right, but not quite”, picked by 66%. Next came “debugging AI-generated code is more time-consuming”, at 45%.
Almost right is the worst kind of wrong. Code that fails to compile costs you ten seconds. Code that compiles, passes the happy path and quietly mishandles an edge case costs you an afternoon, or a production incident. And it looks exactly like code that is correct. The fluency that makes AI output pleasant to read is the same thing that makes its mistakes hard to see.
That is why only 3.1% highly trust AI accuracy. Experienced developers have been burned by plausible code, and they now treat everything from the model as plausible until shown otherwise.
The evidence says the distrust is earned
Three findings make the case that sceptics are calibrated, not stubborn.
First, security. Veracode tested more than 100 models on 80 coding tasks and found that 45% of the generated samples introduced an OWASP Top 10 vulnerability. Newer models got better at producing code that works, but security performance stayed flat. I cover that in more depth in Is AI-generated code safe?.
Second, people overrate their AI-assisted work. A Stanford user study (Perry et al.) found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. The confidence went up while the quality went down.
Third, speed perception. In METR’s randomised trial, 16 experienced open-source developers worked on 246 real tasks. With AI allowed, they were 19% slower. Before starting they expected to be 24% faster, and afterwards they still felt about 20% faster. If people misjudge their own speed that badly, they can misjudge correctness too.
Put together: the tools produce plausible code that is wrong often enough to matter, and the people using them are not good at noticing. Distrust is the correct prior.
Trusting the model is the wrong frame
Most advice on this topic asks you to trust the model more, as it gets better. I think that misses the point. You don’t trust a junior developer because their typing is fluent. You trust the process around them: the build, the tests, the review, the fact that their last forty changes didn’t break anything.
AI code needs the same thing, made explicit. Trust stops being a feeling about the model and becomes a property of the pipeline that the code went through. The question changes from “do I trust Claude?” to “what evidence came with this change, and who checked it?”
Here is how I sort the signals people use.
| Signal | Why it is weak or strong |
|---|---|
| The agent says “all tests pass” | Weak. It is a claim. The agent may have run a subset, or none. |
| The diff reads cleanly | Weak. Fluency is what the model is best at, correct or not. |
| A newer, bigger model wrote it | Weak. Veracode found larger models were not significantly more secure. |
| The engine ran the build and tests and logged the exit codes | Strong. Evidence nobody can talk around. |
| A different model reviewed the diff against criteria | Strong. Different blind spots, no stake in the plan. |
| This kind of change has shipped 50 times without a revert | Strong. A track record, measured per task type. |
The weak signals are all things the model can produce by itself. The strong ones come from outside the model. That is the whole trick.
How to build trust you can defend
You can’t argue a sceptical team into trusting AI code, and you shouldn’t try. You can give them evidence until the scepticism has nothing to hold on to. This is the order I would do it in.
- Make every claim checkable. “Tests pass” becomes a command the pipeline runs, with the exit code attached to the change. Evidence over claims goes through how to set this up.
- Separate writer and reviewer. The model that wrote the code is the worst one to judge it, because it already believes its plan is right. A second model, ideally from a different vendor, reads the diff cold. In my pipelines, the reviewer is always a different model from the writer.
- Keep changes small. Trust scales badly with diff size. A 150-line change can be checked properly. A 2,000-line change gets skimmed, by people and by models.
- Write the acceptance criteria before the code. Then review is a comparison against something fixed, not a vibe.
- Record outcomes per task type. Dependency bumps, copy changes, new endpoints and migrations have different failure rates. Keep a simple log of which changes were reverted or caused incidents. Trust gets earned by category, not globally.
- Lower the human gate only where the record supports it. When a category has a long clean history with automated checks, a person stops reviewing every instance and samples instead.
Where trust comes from in an AI change
- Person
- Agent
- Automated check
Steps as text
| Step | What happens |
|---|---|
| 1. Criteria | Person — written before code |
| 2. Writer agent | Agent — makes the change |
| 3. Evidence | Automated check — build, tests, exit codes |
| 4. Reviewer agent | Agent — a different model |
| 5. Track record | Automated check — outcome logged by task type |
| Loop | findings go back: back from step 4 to step 2 |
The public benchmark on Bulava is one data point for the second step. On the same task, Claude Code alone finished with about 13 bugs I counted by hand. Adding one reviewer at the end brought that to about 7. Having two models write independent positions before any code existed produced no broken mechanics. One task proves nothing general, but it matches what I see daily: a second, independent opinion is the cheapest trust you can buy.
Bad ways to handle distrust
Two approaches look reasonable and make things worse.
The first is banning AI tools. The DORA and Stack Overflow numbers say your developers are using them anyway, so a ban mostly means the code arrives without disclosure and without any of the checks above.
The second is asking people to “review AI code carefully”. Faros AI’s data on about 10,000 developers shows what happens: on high-AI teams, PRs got 154% bigger and review time per PR rose 91%. Telling tired reviewers to look harder at bigger diffs is not a control. It is a hope. If review is already your bottleneck, code review is the new bottleneck covers why.
The good approach is boring: automate the checks a machine can run, put a second model on the reasoning a machine can do, and save human attention for the decisions that actually need a person.
Where this goes next
Here is the bold part. I expect most teams to stop asking whether they trust AI code within a couple of years, the same way nobody asks whether they trust the compiler. Not because models become perfect. Because the evidence around each change becomes so complete that a person reading the diff adds little. On some change types that is already true.
The assumption behind that forecast is simple: verification gets cheaper faster than generation gets more reliable. Builds, tests, type checks and model reviews cost cents and minutes. Each one removes a class of “almost right”. Stack enough of them and the residual risk on routine changes falls below what a skimming human reviewer catches anyway.
Distrust is the right starting point. The mistake is to stop there. Treat it as a requirements list for your pipeline, and trust becomes something you can measure.
Questions
Why don’t developers trust AI-generated code?
Mostly because it is often almost right, which is harder to catch than obviously wrong. In Stack Overflow’s 2025 survey, 66% named “almost right, but not quite” as their top frustration, and 46% distrusted the accuracy of AI output.
Is trust in AI coding tools going down?
Yes. Stack Overflow found favourability fell from 77% in 2023 to 72% in 2024 and 60% in 2025, while the share distrusting AI accuracy rose from 30% to 46% between 2024 and 2025. Usage rose over the same period.
How can a team trust AI code without reviewing every line?
By trusting the process instead of the output: criteria written before the code, builds and tests run by the pipeline with recorded results, an independent reviewer model, and a track record per type of change. Human review can then move to sampling on categories with a clean history.
Does a better model make AI code trustworthy?
Not on its own. Veracode found that newer and larger models got better at writing working code but not at writing secure code. Trust comes from checks outside the model.
