When was the last time you filed a bug report that ended with an actual root cause? Not a workaround. Not a retry loop. An actual explanation of why the thing broke.
If you had to think about it, you already understand the problem. A post called “The Normalization of Inexplicable Failures” went up on ihatethefuture.com in late September 2026 and climbed Hacker News, and the reason it resonated isn’t that it revealed something new. It’s that it named a habit most of us picked up quietly, one retry wrapper at a time.
A broken door versus a broken bot
The post uses an image I keep coming back to: a broken door can make a joke. A broken AI service can make a business process impossible to trust. That distinction matters more than it sounds.
When a door sticks, you know it sticks. You shoulder it, you laugh, you call maintenance. The failure is legible. You can point at the hinge. When an AI-backed feature fails, you often get something worse than an error: you get a plausible answer that happens to be wrong. Or you get the right answer four times and garbage on the fifth, with identical inputs. There’s no hinge to point at.
The author’s framing of the tragedy of software engineering today is that we are actively engineering systems where this is expected behavior. Not tolerated. Expected. Baked into the design docs.
How I ended up doing this too
I build bots. That’s the whole job. And I want to be honest about my own drift here, because it would be easy to write this as a scolding piece aimed at someone else.
Three years ago, when a bot gave a bad response, I’d pull logs, reproduce it locally, and find the broken branch. These days, my first instinct on a weird output is different. I re-run it. If it works the second time, I move on. If it doesn’t, I adjust the prompt. If that doesn’t work, I add a validation layer that catches the bad shape and asks again.
None of those steps involve understanding what happened. I built a system that recovers from failures My users are happier. My uptime graph looks great. And I have quietly lost the ability to explain my own software.
That’s the normalization the post is talking about. It doesn’t arrive as a decision. It arrives as a series of reasonable Tuesdays.
The stakes are not evenly distributed
Concerns about AI failures are loud in 2026, and they come in very different sizes. On one end you have people like Jacob Coxen, the former Anthropic researcher warning that AI and superintelligence could kill everyone within ten years. That’s the conversation that gets headlines.
On the other end you have the thing I actually work on: a support bot that misroutes a refund request, a document classifier that silently drops a category, an agent that takes an action nobody authorized because a few prompts went sideways. Small failures. Unexplainable ones.
I don’t think these are separate conversations. The reason existential warnings land at all is that everyone already has personal experience with systems that behave in ways their builders can’t account for. We’ve been training ourselves for a decade to accept “the model did something odd” as a complete incident report. A culture that accepts that at small scale has no immune system for it at large scale.
What I’m changing in my own stack
I don’t have a clean fix. I have a set of practices I’ve started treating as non-negotiable, and they’re all boring:
- Log the inputs, not just the outputs. If I can’t replay the exact request that produced a weird result, I’ve given up on debugging before I started.
- Count the retries. A retry that silently succeeds is a bug you decided not to look at. I now track retry rates per endpoint as a first-class metric, and a rising number gets treated as an outage in slow motion.
- Write down the failure modes I’ve accepted. Literally a file in the repo. “This classifier confuses these two categories roughly this often, and here’s why we shipped anyway.” Accepted risk is fine. Forgotten risk is not.
- Keep a deterministic path for anything that touches money, identity, or permissions. If a model is in the loop there, it advises. It doesn’t decide.
- Separate “unreliable” from “unexplainable.” Unreliable is a tradeoff you can measure and budget for. Unexplainable is a hole in your understanding, and it grows.
Legibility is a feature
The useful takeaway from that post isn’t that AI is bad or that we should stop building with it. I’m not going to stop. It’s that explainability is a product requirement we’ve been treating as a research topic.
Users don’t need our systems to be perfect. They need them to be legible enough that when something goes wrong, someone can say what happened. A door that sticks is a joke. A system nobody can account for is a liability, and shipping more of them faster is not the flex we’ve been pretending it is.
Ask yourself the opening question again about whatever you shipped last week. If the answer makes you uncomfortable, good. That discomfort is the only thing standing between engineering and shrugging.
🕒 Published: