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 (I’ll cop to that 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.

The specific thing that compounds this problem

The AI tooling category has a property most infrastructure dependencies don’t: it degrades your fallback skills in proportion to how much you use it. A CDN outage doesn’t affect your ability to write the HTML that the CDN was serving. An AI assistant outage, if the team has been relying on it to decode stack traces, write tests, and debug unfamiliar code, absolutely does affect the team’s ability to do those things without it. The tool is load-bearing in a way that goes beyond availability.

This isn’t hypothetical. The Hacker News thread from this particular outage had engineers genuinely stuck, not just inconvenienced. People who couldn’t remember the regex syntax they used to know. People asking for help understanding error messages they’d normally have parsed immediately. The tool had become the memory, not an extension of it.

The mitigation is old and boring: use the hard version of the problem regularly, not just when the easy version is unavailable. Read the stack trace yourself before asking. Write the test case yourself before accepting a generated one. Not because the generated version is wrong, but because the cognitive reps are what keep the fallback available. Your muscle memory depreciates if you don’t maintain it.

Running your own local model via Ollama or a similar setup doesn’t fully substitute, but it does decouple the “AI unavailable” case from the “internet unavailable” case, which is at least an improvement. The supervision without systemd tip is adjacent here in spirit: keep the fallback operational path in working order, tested, not just documented.