When was the last time you actually found out why your bot broke? Not “restarted it and the problem went away.” Not “reran the prompt and got a better answer.” Actually found the cause, named it, and fixed it.
If you can’t remember, you’re in good company, and that’s the problem I want to talk about. A post making the rounds right now, The Normalization of Inexplicable Failures from ihatethefuture.com, landed on Hacker News and hit a nerve for a reason. Software engineering in 2026 is full of failures nobody explains. We shrug. We retry. We move on.
A broken door can make a joke
The post uses a great image. A broken door is funny. There’s a bit in President Curtis where the president fights with two doors, and it works as comedy because a door’s failure is legible. You can see the hinge. You can see the guy pushing when he should pull.
A broken AI service isn’t funny, because it isn’t legible. When a model-backed workflow returns something wrong, you often can’t point at the hinge. As the post puts it, a broken AI service can make a business process impossible to trust. That’s the real cost. Not downtime, trust.
Bot builders feel this more sharply than most, because our systems are built out of components that fail softly. A deterministic function throws an exception. A language model returns a confident paragraph that happens to be wrong. One of those gets caught by your monitoring. The other one ships to a customer.
2026 keeps stacking layers
The pattern isn’t limited to AI. ERP and IT deployments are failing more often this year, and the reasons given are unglamorous: rising complexity and not enough skilled people to manage it. One commentator on the ERP side put it bluntly, noting that organizations can’t figure out how to deploy basic general ledger technology or accounting software, and now they’re complicating things further with digital transformations that add another layer.
That line should sting for anyone building bots on top of enterprise systems. We are frequently that extra layer. When I wire an agent into a company’s order system, I’m adding surface area to a stack that was already fragile and already understaffed. If the team underneath me can’t explain their own failures, my bot inherits that fog and adds its own.
Moderate failure is the dangerous kind
Total failures get attention. Projects that die loudly get retrospectives, budget reviews, maybe a consultant. What’s actually common is the moderate failure: the project that sort of works, eats months of time and real money, and leaves customers annoyed rather than gone.
Moderate failure is dangerous precisely because it survives. Nobody kills it. Nobody investigates it. The team learns to route around the broken part, and the broken part becomes architecture. Six months later, a new engineer asks why the retry loop runs three times with increasing temperature, and the answer is “it works better that way.” That’s not engineering. That’s superstition with a linter.
What I actually do about it
I don’t have a clean fix, because there isn’t one. But I’ve changed how I build bots over the past year, and most of it comes down to refusing to accept an unexplained pass or an unexplained failure.
- Log the inputs, not just the outputs. If I can’t reproduce a bad run from my logs, I don’t have logs. I have vibes with timestamps.
- Trace IDs through every hop. Request in, tool calls, model calls, database writes, response out. One ID. When something goes sideways I want the whole chain in one query.
- Build a replay use early. Saved real inputs, run them against the current build, diff the behavior. This is the single highest-value thing I’ve added to my own projects.
- Fail loud at the boundary. If a tool call returns something my schema doesn’t recognize, I stop. I don’t let the model improvise its way past a broken dependency.
- Write down the weird fix. Every superstitious workaround gets a comment explaining what I observed and what I don’t understand. Future me deserves the honest version.
None of that is clever. It’s just refusing the shrug. The shrug is cheap in the moment and expensive forever, because each unexplained failure you tolerate lowers the bar for the next one. Do it enough times and you’ve trained yourself out of the ability to debug your own system.
Trust is the product
Here’s what I keep coming back to as someone who ships bots for a living. Nobody buys my architecture diagram. They buy the expectation that the thing behaves the same way tomorrow as it did today. Every failure I can’t explain is a small withdrawal from that account.
Complexity is going up and experienced hands are scarce, so the pressure to shrug will only increase. The counter-move isn’t a better framework. It’s a habit: when something breaks, find out why. Even when it’s inconvenient. Especially when it’s inconvenient.
🕒 Published: