Debugging production incidents when 95% of the code is written by AI requires more AI, so your AI vendor is now critical infrastructure—if they're down while you have a major incident, you're screwed.

In the last year, AI agents have become indispensable tools for producing software. That also means that when things break, the code that caused it wasn't written by a human, and probably wasn't documented by one either. So, we reach for an LLM to help us debug the issue.

And the direction of travel doesn't stop there. More and more, organisations are encoding what used to be runbooks as skills. They're moving from places like Confluence or Notion to markdown files committed in git repos. This isn't necessarily a bad thing; a human could still follow a skill, as long as it doesn't immediately start referencing which MCP tools to call…

What naturally follows is the slightly uncomfortable question: what happens when the internet goes down? When a major outage like AWS us-east-1 in October 2025 happens, how are you going to respond? Have you checked that your AI provider will remain up when a major cloud region is down? For most, I'd bet the answer is probably no.

Going into 2027, your AI provider is no longer a nice-to-have that speeds up the engineering team or your business; it's a critical dependency for your operational resilience.

That means treating it like one. Put it on the list of third parties you monitor. Know which model provider and region you're running on, and whether it shares failure domains with your own stack. Have a fallback — a second provider, a locally-runnable model, or at the very least a version of your skills that a tired human can follow at 3am without an MCP server in the loop. And run drills and game days both with and without AI, and see how far engineers get in both.

Because in 2027, losing access to your LLM is almost like losing access to your IDE.