I should admit that I almost missed the Microsoft outage of November 12–13. I don't rely on their tools every day anymore. But my wife mentioned offhand that one of her colleagues was unable to send a farewell email on his last day. That kind of thing is unfortunate, and presumably repeated across the world in one form or another. It just shows once again how critical certain platforms have become in all aspects of daily life.
What I find interesting is how many experienced engineers inside and outside my network immediately suspected that AI-generated code had somehow "caused" the failure, or that Microsoft's zealousness in replacing engineers with AI (see recent layoff announcements) had left teams understaffed and lacking experience with the systems they're left operating.
Microsoft has tried to get in front of these objections by explicitly stating that the outage had nothing to do with AI or agents, and reportedly ruling out job cuts as a cause. They certainly remember similar speculation after Amazon's major AWS outage in October 2025, which came amid mounting concerns about AI-driven layoffs and the loss of institutional knowledge.
I have no reason not to take them at their word, and I look forward to reading a formal postmortem.
But if every time there's a major outage, experienced engineers find it completely plausible that AI-driven management decisions have compromised system reliability, that's a problem in and of itself.
Experienced engineering leaders have always understood that software reliability depends on far more than the ability to crank out code. It's more a matter of developing and maintaining deep systems knowledge and operational experience, conducting effective reviews, and giving teams enough resources to do what's often some pretty unglamorous work.
Yet these days, we increasingly hear executives cite "AI productivity gains" (or sometimes more honestly, "AI investment needs") as justification for axing headcount, cutting non-infrastructure spending, speeding up development, and making fundamental changes to how engineering teams operate.
Perhaps some of those decisions will prove justified over time. But productivity gains are not the same thing as organizational excellence, and cranking out code faster is not the same thing as operating a complex system safely. And while the productivity gains are relatively easy to demonstrate, the institutional knowledge, operational excellence, and engineering judgment being sacrificed are considerably harder to measure.
Clearly, many of my colleagues are worried that engineering organizations are burning through hard-won expertise and institutional knowledge in pursuit of productivity gains they have yet to properly quantify, while underestimating risks until something goes off the rails in production.
And when something does go wrong, engineers seem very eager to believe that's precisely what happened.
Whether AI was involved in the Microsoft outage is ultimately a technical question. But why so many engineers suspect it was is a leadership question that we need to do a better job of answering.
