Trust in AI output fell to 29%. That is the correct direction.

Stack Overflow’s 2025 developer survey put developer trust in AI output at 29 percent, down from around 40 percent the year before. The number gets used in two ways, both wrong. Sceptics use it as proof the technology is oversold. Vendors and some executives treat it as a change management problem, something to be fixed with enablement sessions and internal advocacy.

My position: a falling trust number is exactly what you want to see from a workforce that has been paying attention, and any programme aimed at raising it is aimed at the wrong variable. The number that should worry you is a different one entirely, and it moved in the opposite direction.

What the number is actually measuring

Trust is not an opinion about a technology. It is a prediction about output quality, and predictions get better with exposure.

In 2024 most developers were forming that prediction from a few weeks of use on small, well-lit tasks. In 2026 they are forming it from a year of use on real systems, including the times an agent produced something plausible that referenced an API the repository does not have, or followed a convention from a different codebase entirely. Context blindness is the characteristic failure: output that is internally coherent and incompatible with the system it landed in.

A prediction that moves from 40 percent to 29 percent after that exposure is not pessimism. It is a population updating on evidence. If the number had gone up over the same period, without a corresponding change in the failure modes, that would be the finding worth investigating.

There is also a category confusion buried in the question. “Do you trust AI output” collapses several different things: do you trust it to draft a test, to write a migration, to touch the billing path. A sensible engineer holds very different answers for each, and being forced to average them produces a low number that reflects sophistication rather than resistance.

The number that should worry you

Here is the part that gets left out when the trust figure is quoted.

Over roughly the same period, LinearB’s 2026 benchmarks show pull requests merged with zero review up over 31 percent. Median review duration on agentic changes up more than 400 percent. Pickup time on those changes roughly 5.3 times longer.

Put those beside 29 percent and you have an organisation saying one thing and doing another. Stated trust fell. Revealed trust, measured by what people are willing to merge unread, rose sharply.

What the trust number suggests is happening

• Developers are sceptical
• Therefore they check the output
• Therefore quality is protected by attention
• Therefore the risk is adoption slowing

What the merge data suggests is happening

• Developers are sceptical
• And merging more of it unread
• Because checking does not scale with volume
• The risk is confidence without inspection

This is not hypocrisy. It is a capacity problem wearing the costume of a culture problem. People do not merge unread because they have decided the output is fine. They merge unread because forty changes arrived, the deadline is real, and reading all forty carefully is not a thing a person can do. Distrust with no time to act on it converts into exactly the same behaviour as trust.

Why raising trust is the wrong goal

Once you see the gap between stated and revealed trust, the standard intervention looks worse.

An enablement programme aimed at raising confidence in the tooling operates on the stated number, which is the one that is currently correct. It does nothing to the revealed number, which is the one causing harm. In the worst case it closes the gap from the wrong side: people stop being sceptical, keep merging unread, and the only remaining protection is gone.

The goal is not more trust. It is not less trust either. It is making the level of trust matter less, by making verification cheap enough that a sceptical engineer can act on their scepticism inside the time they actually have.

Make done checkableCriteria a machine can settle, written before the work. Removes the largest category of "is this what we wanted" from human review.

Separate the classesLow blast radius against covered paths does not need the same attention as anything touching money, auth or data migration. Uniform review spends the scarce input evenly on unequal risk.

Show what was checkedA reviewer who can see which criteria were mechanically settled reads the remaining question, not the whole diff.

Measure unread mergesThe rate of changes reaching production without human inspection is the honest trust metric. Nobody self-reports it.

What to do with a sceptical team

If your engineers have low trust in agent output, you have a well-calibrated team and you should say so out loud. What you should not do is treat their scepticism as the obstacle.

Ask them a narrower question than the survey does. Not “do you trust it” but “which categories of change would you merge without reading, and which would you never”. Almost everyone has a clear answer, and the aggregate of those answers is a routing policy your organisation could adopt on Monday.

Then ask the follow-up that hurts. “Of the changes in the second category, how many did you merge last month without reading anyway, and why.” The answers are about volume and deadlines, every time, and they tell you where the actual intervention goes.

Where this breaks down

Survey trust is a weak instrument. A single self-reported number, aggregated across wildly different tasks and seniorities, moving over one year, is not strong evidence of anything. It is consistent with calibration improving. It is also consistent with a shift in who answers surveys, or with a fashion in how people talk about the technology. I am reading a lot into eleven percentage points and you should discount accordingly.

Distrust does have real costs. A team that treats every generated change as suspect will inspect things that do not need inspecting and will refuse leverage that is genuinely safe. There is a level of scepticism that is expensive rather than protective, and “trust fell, good” is not a policy.

The zero-review number may not mean what I am claiming. Some of those merges are documentation, generated boilerplate, dependency bumps and revert commits, where merging unread is correct. Without knowing the composition, treating the whole increase as risk overstates it. This is the strongest objection to my argument and it is why I would rather you measured your own rate than borrowed the benchmark.

Cheap verification is not free verification. Everything in that flow diagram costs someone time upstream, usually the person writing criteria, who is measured on something else entirely. That organisational reality is why the expensive uniform review persists, and no amount of being right about the mechanism dissolves it.

We sell in this space. Fastpace builds tooling in the verification layer, so read my enthusiasm for cheap verification with that in mind. The specific claim I would still defend if we sold nothing: measure your unread merge rate before you spend anything on changing how your team feels.

The takeaway

Twenty-nine percent is a workforce that has looked closely and updated. Treating that as a problem to be managed upward misreads a good signal and leaves the actual failure untouched.

The failure is the gap between what engineers say about the output and what they are able to do about it under load. Scepticism with no time attached produces exactly the same merges as confidence.

If you take one thing into next week: find the share of last month’s merges that no human read. Put that number next to your team’s stated confidence in the tooling, and work on whichever gap is wider.