I'm glad you wrote it up. Thanks! But I feel like the folks behind the HTML5 spec and the comprehensive test suite deserve the lion's share of the credit for this (very neat) achievement.

Most projects don't have a detailed spec at the outset. Decades of experience have shown that trying to build a detailed spec upfront does not work out well for a vast class of projects. And many projects don't even have a comprehensive test suite when they go into production!

I completely agree. I hope I gave them enough credit in the blog post and the GitHub repo.

Yep, and I think it is a great way to draw attention to their work!

Having a comprehensive spec and test suite is an absolute requirement, without it all you got is vibe-testing, LGTM feels. As shown by the OP, you can throw away the code and regenerate it back from tests and specs. Our old manual code is now the new machine code.

It would be very interesting to see a post-mortem for each of the design mistakes, with links to the original design discussions and docs, and analysis of how the decision-making process went astray.

That's an interesting point, but in many (most?) cases productivity doesn't depend on all services being available at the same time. If one service goes down, you can usually be productive by using an alternative (e.g. if HN is down you go to Reddit, if email isn't working you catch up with Slack).

If HN, Reddit, email, Slack and everything else is down for a day, I think my productivity would actually go up, not down.

During 1st Cloudflare outage StackOverflow was down too.

Many (I’d speculate most) workflows involve moving and referencing data across multiple applications. For example, read from a spreadsheet while writing a notion page, then send a link in Slack. If any one app is down, the task is blocked.

Software development is a rare exception to this. We’re often writing from scratch (same with designers, and some other creatives). But these are definitely the exception compared to the broader workforce.

Same concept applies for any app that’s built on top of multiple third-party vendors (increasingly common for critical dependencies of SaaS)

The system rewards people who can exploit it.

To be fair to Rust, the issue was an "unwrap" in the Rust code[0]. "unwrap" means "if the operation did not succeed then panic". Production Rust code should not use "unwrap", and should instead have logic to handle the failure case.

You don't need exotic formal verification methods to enforce this best practice. You just need a linter.

[0] https://blog.cloudflare.com/18-november-2025-outage/#memory-...

I don’t know why anyone thinks that you can’t or shouldn’t use unwrap in a production environment. If this was enforced you’d likely end up with people using something like “.expect()” and there are real world cases where you KNOW that unwrapping will never cause issues.

The reality is the code should not have used unwrap, but that doesn’t mean using unwrap is bad.

My guess is that Claude's "bad days" are due to the service becoming overloaded and failing over to use cheaper models.

Seems like a substantial fraction of the web was brought down because of a coding error that should have been caught in CI by a linter.

These folks weren't operating for charity. They were highly paid so-called professionals.

Who will be held accountable for this?

This is quite likely to be in the training data, since it's one of the projects in Wes Bos's free 30 days of Javascript course[0].

[0] https://javascript30.com/

I was under the impression for this to work like that, training data needs to be plenty. One project is not enough since it’s too "sparse".

But maybe this example was used by many other people and so it proliferated?

The repo[0] currently has been forked ~41300 times.

[0] https://github.com/wesbos/JavaScript30

It’s quite unlikely that training data will include duplicate repositories or even forks, that alone would surpass the published dataset sizes.

I love it!

CTO is usually the exec responsible for the entire tech org. The CTO reports to the CEO, and the top managers and maybe a few ICs in the tech org report to the CTO.

I was CTO of a <20 person startup. I recruited the entire tech team, collaborated with the CEO to build the product backlog and spec things out, presented to investors, but also had at least 50% time to code. Not all “CTO” roles are the same. At a small company they better be hands on.

This is very similar to my own role, but I didn't have (nor would I have accepted) that title.

On my resume, I usually list it as “Lead Engineer” since it fits the roles I’m applying to better.

I think a founder/early gets away with "CTO" on their resume, esp. if they're the only person in the org with the role (ie: it's a PM-style CTO, and there isn't a VP/PM; or: it's a VP/E-style CTO, and there isn't a VP/E). But outside that circumstance, given the choice, I'd rather have the VP/PM or VP/E role than "CTO".

(As we get deeper into these threads I am further out on a limb.)

Yes, I was one of the first hires. My role was closer to VP/E and "CTO" was mostly vanity, a reward for being early and getting a new company through the first couple years.

It's very common to see a VP of Engineering managing the day-to-day operations while the CTO acts in a capacity like this.

I’ve seen that too, but then the VP of Engineering tends to report to the CTO, and not to- say, the CEO directly.

Dotted line reporting is very different. In these instances the VP/E is usually directly interfacing with other executives as the CTO's peer. This is even more true when the budget is managed by the VP/E and the CTO is more customer/sales facing.

You're saying "usually" about something that has definitely not been a norm in my career. It seems like there's really only two ways to interpret that arrangement: either the CTO is in fact the EVP/E (fair enough! lots of CTOs are other exec roles with a funny hat), or the CTO has a single top-level manager report, in which case what really happened is that the org hired a pro to run engineering and put the "CTO" out to pasture.