Here is an unpopular opinion: the most damaging thing AI has done to us so far has nothing to do with superintelligence, job losses, or killer robots. It’s that we’ve quietly learned to accept “it just did that” as an acceptable answer. And we learned it so gradually that most of us never noticed the lesson.
That’s the argument at the heart of a post called “The Normalization of Inexplicable Failures,” published in late September 2026 on a blog with the wonderfully grumpy name i hate the future. It hit the front page of Hacker News, which tells you the frustration resonated with people who build this stuff for a living, not just the people who have to use it.
A tale of two broken things
The post opens with a comparison I haven’t been able to shake. It points to a scene from the show President Curtis, where the president struggles with two doors. A broken door, the author observes, can make a joke. A broken AI service can make a business process impossible to trust.
Sit with that distinction for a second, because it explains a lot about why AI failures feel different from normal tech failures.
When a door doesn’t open, you can see the problem. The hinge is bent, the latch is stuck, someone locked it. The failure is visible, physical, and bounded. You know what broke, you know roughly how to fix it, and in the meantime you know exactly what you can’t do: go through that door. It’s annoying. It’s also comprehensible, and sometimes funny.
When an AI agent fails, none of that holds. You don’t get a bent hinge. You get a confident-sounding answer that happens to be wrong, or a task that silently completed halfway, or a workflow that worked perfectly on Tuesday and produced nonsense on Wednesday with the same inputs. The failure isn’t bounded. You can’t tell which parts of the output to trust, which means you can’t fully trust any of it. That’s the difference between a nuisance and a credibility problem.
The part that should bother us
The blog’s sharpest line is about engineering, not doom. The author calls it the tragedy of software engineering today: that we are actively engineering systems this way. Not stumbling into it. Choosing it.
For non-technical readers, that’s the piece worth understanding. Traditional software was built around determinism, a fancy word for “same input, same output.” If it broke, an engineer could trace the path and find where things went sideways. AI systems built on large models don’t offer that guarantee by design. They’re probabilistic. Variation isn’t a bug to be squashed; it’s a feature of how they generate anything at all.
That tradeoff can be completely worth it. Those same systems do things older software couldn’t. But the tradeoff is real, and it’s being passed along to users who were never told it existed. Nobody put a label on the box saying “this tool will occasionally fail in ways no one can explain, including us.”
Normalization is the actual risk
2026 has not been short on AI warnings. Jacob Coxen, a young former Anthropic researcher, has been making the case that AI and superintelligence could kill everyone within ten years. That’s a serious claim from someone with relevant experience, and it gets the headlines, understandably.
But notice how the two concerns connect. A society that has already been trained to shrug at unexplained machine behavior is a society with weaker reflexes for noticing when something is genuinely wrong. Normalization doesn’t announce itself. It shows up as small daily surrenders:
- Retrying the prompt instead of asking why the first one failed
- Treating “the model was having a weird day” as a diagnosis
- Accepting that support can’t tell you what happened to your data
- Building business processes on top of tools nobody can fully audit
Each one is individually reasonable. Collectively, they add up to a lowered standard for what we expect from the systems running our work and money and records.
What you can actually do about it
You don’t need to be an engineer to push back on this. A few habits go a long way.
Keep asking why
When an AI tool fails you, ask the vendor what happened. Not to be difficult, but because the demand for explanations is what creates pressure to build explainable systems. Silence reads as acceptance.
Match the tool to the stakes
Unpredictable output is fine for brainstorming and bad for payroll. Ask what happens when the tool is wrong, not just what happens when it’s right.
Insist on a paper trail
Logs, version history, records of what an agent did and when. It’s the difference between a mystery and an investigation.
Broken doors are funny because we understand them. The goal isn’t AI that never fails. It’s AI that fails in ways we can see, name, and reason about. Our willingness to keep asking why is the only thing that gets us there.
🕒 Published: