The numbers
In 2025 Stack Overflow asked tens of thousands of developers about AI. Eighty-four percent use it or plan to. Three point one percent highly trust what it produces. Forty-six percent actively distrust it.
Source: Stack Overflow Developer Survey 2025. Worth reading directly rather than through anyone's summary, including this one.
Read those together and something odd emerges: an entire profession adopting a technology it does not believe. Not refusing it — adopting it at scale, while quietly assuming it will be wrong.
That gap is not skepticism. It is experience.
The people in that survey are not AI skeptics on principle. They are the people who shipped it.
They have watched a model be confidently, articulately incorrect. They have debugged a hallucinated API call. They have had a generated test pass while testing nothing. Their distrust is calibrated, not ideological — which makes it far more durable than the enthusiasm currently being sold against it.
What breaks between the demo and month three
The demo runs on clean inputs, a cooperative user and a happy path. Production has none of those.
Production has the malformed record. The API that rate-limits harder than its documentation admits. The month-end edge case that exists twelve times a year. The user who does something nobody anticipated.
And the failure is rarely loud. Systems degrade — they skip records, or write the wrong thing, or return plausible nonsense — and somebody finds out three weeks later, usually from a customer.
Why "human in the loop" became a slogan
It is the correct answer, which is exactly why it got hollowed out.
A human in the loop means something specific: a defined decision, a defined reviewer, a defined threshold above which the system stops and asks. It does not mean a human is available somewhere. It does not mean someone glances at a dashboard.
Most implementations put a human in the loop for demos and take them out for throughput, because the loop is where the cost is.
What accountable AI actually requires
Four things, none of them glamorous:
Name what "wrong" looks like before you build. You cannot guard against a failure you have not defined.
Build the evaluation suite before the system. Otherwise quality is a feeling and every prompt change is a coin flip.
Put the human where being wrong is expensive — not everywhere, which is unaffordable, and not nowhere, which is the current default.
Instrument the failure modes, not the uptime. Uptime tells you it responded. It does not tell you the response was right.
None of that is a model problem. It is engineering, and it is the reason the 3.1% number exists.
What this means commercially
The market has already adopted. What it has not done is trust.
That gap is not closed by a better model — a better model closes some failure modes and opens others. It is closed by someone being accountable for whether the output is correct, and being willing to say so by name.
That is the whole thesis. Everything else we do follows from it.