It’s 4:12 on a Tuesday afternoon. The agent that has summarized your support tickets flawlessly for six weeks returns an empty object. No error. No stack trace. No rate limit warning. Just {}. You run it again. It works. You run it a third time. Empty object. You stare at it for ninety seconds, then you type the message that has become the defining artifact of software engineering in 2026: “weird, seems fine now.” You close the tab. Nobody files a ticket.
That message is the problem. Not the empty object.
We stopped asking why
I test AI tools for a living, which means I spend most of my week watching things fail in ways nobody can account for. What has changed over the last couple of years isn’t the failure rate. It’s the reaction. Engineers used to treat an unexplained failure as an open wound. You didn’t ship until you knew what happened. Now the unexplained failure is a weather event. It rained. You waited. It stopped raining. Back to the sprint board.
Software engineering in 2026 is full of these frequent inexplicable failures, and the dominant response is a shrug. Not because engineers got lazy. Because the systems got complicated enough that “I don’t know” became a defensible answer, and once “I don’t know” is defensible, it becomes the default.
The economics reinforce it. AI and ERP deployments are hitting more trouble as complexity stacks up and labor shortages bite. Fewer people who understand the whole system, more layers in the system, more surface area nobody owns. When the person who could explain the failure doesn’t exist on your team, the failure stops being explicable by definition. And then it stops being worth investigating.
The moderate failure is the killer
Everybody remembers the catastrophic project. The nine-figure ERP rollout that eats a company’s fiscal year. Those get written up, post-mortemed, turned into conference talks.
The real damage is the moderate failure, and moderate failures are common. The project that ships eight months late and does two-thirds of what it promised. The integration that mostly works. These burn real time, real money, and real customer patience, and they never produce a reckoning because no single moment was bad enough to demand one. Death by a thousand “weird, seems fine now.”
There’s a reason this pattern found a home in AI tooling specifically. A broken door is honest. It sticks, you push harder, you learn something about the door. A broken AI service gives you a plausible-looking answer and lets you find out three weeks later that the answer was wrong. The failure mode isn’t a stop. It’s a soft, confident wrongness that passes every smoke test you wrote.
What this does to trust
Once a system fails in ways you can’t explain, you can’t reason about it. You can only develop superstitions. Run it twice. Don’t run it on Mondays. Clear the cache first. I have watched teams build elaborate ritual around tools they pay for, and every ritual is an admission that they gave up on understanding the thing.
That’s the cost nobody puts on the invoice. Not the outage. The quiet erosion of your team’s ability to make claims about their own software.
What I’d actually do about it
I’m not going to pretend there’s a clean fix for complexity and a thin labor market. But the shrug is a choice, and you can stop making it.
Log the weird thing. Even when it resolves itself. Especially when it resolves itself. A one-line note in a shared doc with a timestamp costs you thirty seconds and turns three isolated mysteries into a pattern you can chase. Most inexplicable failures are only inexplicable because nobody wrote down the other four times it happened.
Refuse to count intermittent as fixed. If it worked on retry and you don’t know why, the bug is open. Say so out loud in standup. It feels pedantic for about a week and then it changes how your team talks.
Ask vendors the uncomfortable question before you sign. Not “what’s your uptime.” Ask what a silent partial failure looks like on their platform and how you’d detect one. The answer, or the discomfort in the answer, tells you more than the status page ever will.
Budget for the moderate failure. Not as a contingency line you’ll quietly spend anyway, but as an explicit assumption: this will land late and incomplete, and here’s what we do when it does. Teams that plan for the moderate failure catch it early. Teams that plan for success discover it at the customer.
The tools we review are getting more capable and less legible at the same time. That trade is going to keep getting worse before it gets better. The one thing still under your control is whether your team treats “I don’t know” as an answer or as the start of a question.
🕒 Published: