Your AI pair programmer went down for four hours and so did half of Hacker News' composure

A popular AI coding assistant went dark for about four hours this week. Not “degraded performance,” not “elevated error rates” — dark. Full outage. And judging by the timeline of increasingly unhinged posts I watched scroll by, a genuinely alarming number of engineering teams discovered in real time that their ability to write code was now a hosted dependency.

I want to be clear about something before the pitchforks come out: I am not the “real programmers use ed and a soldering iron” guy. I was wrong about a lot of things for a long time — containers, mostly, which I’ll cop to elsewhere — and I’m not going to pretend the tooling doesn’t help. It does. What it doesn’t do is excuse you from understanding what happens when the thing you built your whole workflow around has a status page instead of a git log.

This is not a new problem, it’s the same problem with better marketing

Every generation gets one of these. Mine was CVS servers with a single point of failure and no distributed fallback — lose the server, lose the ability to commit, full stop. Then it was build farms. Then it was “the deploy pipeline is down so nobody can ship,” which, incredible, is still a thing teams let happen in the year of our disclosure 2026.

The pattern is always identical:

1. A tool makes something meaningfully easier.
2. Adoption goes vertical because the tool is actually good.
3. Nobody budgets for the day the tool isn’t there.
4. The tool isn’t there.
5. Twitter, or whatever we’re calling it this week, discovers everyone’s workflow was a house of cards with excellent DX.

What you should actually do about it

Not “boycott AI tools,” settle down. What you do is the same thing you should’ve been doing about your CI provider, your package registry, and your cloud vendor: know what breaks when the dependency disappears, and make sure “breaks” doesn’t mean “nobody can work.”

• Can your team still ship code without the assistant? If the honest answer is no, that’s not a tooling problem, that’s a training problem.
• Do you have the muscle memory to read a stack trace without asking something to summarize it for you? Keep that muscle. You will need it during the next outage, and you will need it worse during the incident the assistant confidently helps you make more interesting.
• Vendor status pages are marketing documents. Assume the real MTTR is longer than what’s posted, because it always is.

None of this is anti-tooling. It’s the same advice I’d give about any dependency you didn’t write and don’t control: use it, benefit from it, and never structure your ability to do your job around its uptime. rm -rf your assumptions occasionally. It’s healthier than it sounds.