Scroll any developer feed and the pattern is unmistakable: an endless stream of "AI just solved my biggest problem" videos, AI-launched products announced with breathless certainty, and replies that were obviously written by a model. The volume of claims has exploded. The volume of verifiable evidence behind those claims has not. That gap is starting to cost the whole category its credibility.

The backlash is already here. Developers openly complain about the flood of identical "Claude Code fixed everything" content, about generated self-promotional titles, about AI-written replies in launch threads. Meanwhile the people actually shipping with these tools are quietly building the opposite of hype — verification layers that check whether the AI's work is real before a user finds out it is not.

The hallucinated endpoint is the canonical failure

The clearest example of why claims are insufficient is the fake API call. An agent confidently wires up an endpoint that does not exist, or assumes a setup that was never configured, and the code looks completely plausible. It compiles. It reads well. It is wrong. People have wasted hours chasing failures that trace back to an agent inventing an interface, which is exactly why some of them built local checkers whose only job is to catch the model's confident fabrications.

This is the heart of the trust problem. AI-generated code fails in a specific way: it fails while looking correct. You cannot tell by reading it, because the model is optimized to produce readable, plausible output. The only way to know is to check it against reality — does the endpoint exist, does the setup match, does the thing actually run — and that check is evidence, not vibes.

Vibe coders generate support tickets, not malice

Much of the damage is not from bad actors. It is from enthusiastic builders who assume the AI got it right and ship on that assumption. They create support issues downstream because a wrong assumption sailed through unchecked — the API was not set up the way the agent believed, and the user hit the wall the builder never saw. The builders who learned this lesson now wire the agent through a layer that checks the setup before the user is the one who discovers it is broken.

That is the productive response to the trust problem: not to distrust the agent, but to instrument it. Let the model do the work, and let a separate layer confirm the work matches reality before anyone depends on it.

Evidence is scope, checks, logs, and handoff

What does "evidence" actually mean in practice? It is concrete. Scope: a record of what the agent was supposed to touch. Checks: automated verification that the output does what it claims. Logs: a trail of what ran, in what order, with what result. Handoff proof: enough context that the next person — or the next session — can confirm the work without redoing it.

None of this is exotic. It is the same discipline software teams already apply to human work — review, tests, audit trails — applied to an actor that produces plausible-looking output at high speed. The faster the producer, the more the verification layer matters, because the volume of unchecked plausible code is exactly what erodes trust.

Claims do not compound; evidence does

A claim is consumed once and forgotten. An evidence trail compounds. The next time the agent touches that system, the record of what was verified last time is still there. The teammate reviewing the change can see what was checked. The user who hits a bug can be shown what passed and what did not. Over time, the team that instruments its agents builds something the hype-driven team never does: a growing base of verified work that other people can rely on.

The market is loud with claims right now, and the loudness is precisely why claims have stopped meaning anything. The teams that will still be trusted in a year are the ones building the boring layer underneath — the one that can prove the agent's work is real.