Two numbers that do not reconcile. Adoption of AI coding agents is at a record in 2026 and teams are not willing to give them up. Meanwhile the share of developers who say they trust the output has collapsed to almost nothing.
People use a tool daily that they do not believe. Here is why that is reasonable and how to live with it.
Why trust fell
Not because models got worse. They got better, and because of that they were handed bigger jobs.
A model used to complete a line, and a mistake was visible immediately. Now it edits ten files and the mistake hides in the relationship between them. Checking became more expensive than writing.
The second reason is that the confident tone never changed. A model delivers a right answer and a wrong one with equal composure, and code carries no "I am unsure here" signal.
What to do instead of trusting blindly
Treat AI code as someone else's pull request. Not because it is worse, but because you did not watch it being written. You already have habits for someone else's PR: read it, ask, run the tests.
Require a failing test before the fix. If an agent is fixing a bug, have it write the test that catches the bug first. A test that failed before and passes after proves the work better than any explanation.
Cap the step size. A ten-file task reviews worse than five two-file tasks. Splitting costs time in framing and saves time in review.
Do not accept explanation as proof. Models explain what they did very well. That is not the same as verification. Run it.
What this means for spend
Distrust has a price. A substantial share of industry token spend goes into fixing what the model itself produced.
That draws a direct line between how sharply you frame a task and what you pay at month end. Sharper input, fewer iterations, smaller bill.
How it looks in a team
Three rules that remove most of the pain:
- The author of a change is the human who submitted it, not the model. They answer for it.
- Agents do not merge on their own. Under any configuration.
- Spend is visible per key and per project, so you can see where iterations eat the budget.
That last one is configurable here: per-key usage stats, and sub-organisations with their own budget per team.
In short
You do not need to trust generated code. You need a process where trust is not required: small steps, a failing test before the fix, ordinary review, and visible spend.