The Smell Is Gone. The Errors Aren't.

In software engineering, Kent Beck gave us a useful idea: code smells. Beck popularized the term on WardsWiki in the late 1990s; Martin Fowler's 1999 book Refactoring brought it to a wider audience. Fowler's definition is the canonical one: "A code smell is a surface indication that usually corresponds to a deeper problem in the system." Beck's own framing is more visceral: "If it smells bad today it is going to be poison tomorrow."

The notion is simple. When something is deeply wrong with a codebase, there's usually a surface sign — a function whose signature has grown unwieldy, duplicated logic scattered across files, a class that knows too much about everything else. The smell doesn't tell you exactly what's broken. But it tells you something is. And that's enough to stop and look.

We used to have the equivalent for bad information.

If you went to Google Translate in 2010 and got a bad translation back, you could tell. There were disfluencies. Chunks still in the original language. The rhythm was off. If you clicked a search result and landed on a sketchy page — slow to load, full of typos, images broken — you learned to treat everything on it with suspicion. These were information smells. Imperfect, sure. But they were signals, and we learned to read them. Bad information announced itself.

Large language models have erased those signals entirely.

Today, when a model gets something wrong, it doesn't look wrong. It looks exactly like when it gets something right: fluent, well-formatted, confident. The sentence structure is clean. The vocabulary is precise. The tone is assured. There is no disfluency, no broken image, no chunk left in the wrong language. The smell is gone — and so is the cue that used to prompt us to double-check.

This matters more than most people realize. The hallucinations enterprises catch are only a fraction of the real problem. A hallucination has to satisfy two conditions to be noticed: it has to be wrong, and you have to see that it's wrong. The second condition is getting harder and harder to meet. When wrong answers are indistinguishable from right ones on the surface, most errors slip through — not because users are careless, but because the signals they've been trained to look for simply aren't there anymore.

This is the iceberg problem. The visible errors are scary enough. But the dangerous ones are the plausible-but-wrong answers that nobody flags, because nothing about them suggests they should be flagged.

The instincts we built up over decades of working with imperfect technology — instincts that served us reasonably well — don't transfer. Fluency used to correlate with accuracy. Now it correlates with nothing except the fact that a model produced the output. We need new tells. Provenance. Citations that actually link to claims. Systems that know what they don't know and say so rather than filling the gap with confident-sounding tokens.

The smell isn't coming back. Which means the next challenge isn't just building models that make fewer errors — it's building systems that make their uncertainty visible again.