Carmack's Quake postmortem: the bus factor that broke id

What happened

John Carmack posted a long reflection on X (the post linked from HN, scoring 533) walking through what he now considers id Software's most consequential mistakes in the years immediately after Quake shipped in 1996. It is not a nostalgia tour. Carmack is specific: the QuakeWorld networking rewrite, the half-finished Trinity engine that became Quake II, the contractor model for level design, and the decision to let a tiny group own the entire engine codebase end-to-end.

The thread reads as a senior engineer's own bus-factor postmortem, twenty-five years late. Carmack's framing is that id didn't fail technically — it failed at distributing knowledge. When Romero left, when American McGee left, when Abrash returned to Microsoft, the company did not lose features; it lost the ability to reason about its own systems. By the time Daikatana shipped and Quake III went into maintenance, the engine team was essentially Carmack plus a rotating cast trying to read his mind.

The specific numbers he cites are unflattering. id was, at peak, around 16 engineers and designers shipping engines that defined a decade of PC gaming. By 2000, headcount had grown, revenue had grown, and shipped output per engineer had collapsed. Carmack does not blame any individual — he repeatedly says the mistakes were structural and that he personally signed off on most of them.

Why it matters

This is not a games-industry story. It is the cleanest public articulation we have of how a hero-engineer culture compounds into organizational fragility, written by the hero engineer himself. Every shop that has ever rallied around one staff engineer who 'just gets it' has lived a smaller version of this arc.

The interesting part is what Carmack now thinks would have helped. He doesn't reach for the obvious answers — more docs, more tests, more onboarding. He points at three things: (1) refusing to let any system be owned by fewer than two people who could actually defend changes in code review, (2) treating tools and pipelines as products with their own roadmaps rather than as Carmack's personal scratchpad, and (3) splitting the engine into shippable layers earlier so that a second team could move without his sign-off. Those map almost exactly onto what modern platform teams call paved roads, internal SDKs, and federated ownership. id was building a monorepo platform org in 1998 and didn't know it.

Community reaction on HN is split in a useful way. The top comments are not 'Carmack is a genius, listen to him.' They are practitioners trading their own versions: a Stripe engineer noting that the early payments core had the same shape, an ex-Twitter infra person saying timeline ranking lived inside two people's heads for years, a Figma alum describing how the multiplayer CRDT layer was a single-engineer fiefdom until 2022. The pattern is consistent: the systems that win year one are almost always the systems that strangle the org by year three, and nobody notices until the owner takes a sabbatical.

There's a 2026-specific wrinkle worth naming. The current AI-assisted development cycle is actively making this worse, not better. When a senior engineer can ship a feature in a weekend that used to take a pod a quarter, the organizational pressure to write it down, review it properly, and onboard a second owner evaporates. Copilot-grade tooling lets one person carry more code than ever, which means the bus factor of a typical high-output team in 2026 is probably lower than it was in 2019. Carmack's thread is, accidentally, the best argument against the 'ten-engineer unicorn' meme that's been running through VC Twitter all spring.

What this means for your stack

Three concrete moves, all of which are unglamorous and all of which Carmack now wishes he had made in 1997.

First, audit single-owner systems on a quarterly cadence. Pull `git log` by directory, group by author, and flag anything where one person has >70% of commits over the last twelve months. That is a system, not a person, even if your org chart says otherwise. The fix is not to fire the owner — it's to require that the next non-trivial change have a co-author from outside that person's reporting line. This is the cheapest possible insurance against the QuakeWorld scenario.

Second, treat internal tools as products with users, not as personal infrastructure. Carmack's regret about the id toolchain — that it was optimized for his workflow and nobody else's — is the same regret you'll hear from anyone who's tried to onboard onto a custom build system, a bespoke deploy script, or a 'temporary' Python notebook that's been load-bearing for three years. If your platform team can't name the five users of each tool it owns, the tool has one user and a lot of bystanders. Internal tools without named users are personal infrastructure cosplaying as platform work.

Third, stop conflating throughput with health. id's headcount and revenue both grew through the late 90s while its actual ability to ship new engines collapsed. The leading indicator was not financial — it was the ratio of code review participants per PR, which would have been trivially measurable even then. In 2026 that ratio is one of the few signals that hasn't been gamed by AI tooling, because review participation requires a human to actually read the diff. Track it.

Looking ahead

Carmack ends the thread with something close to an apology: he says the people who left id during that period were right to leave, and that the structures he built were the reason. That's the rare postmortem where the author indicts themselves and the system in the same breath, and it's why this thread will outlive the news cycle. Expect it to show up in engineering-leadership reading lists for the next decade, alongside the Etsy and Stripe internal-handbook excerpts. The uncomfortable part for anyone running a team in 2026 is that the AI-coding era is rebuilding the exact failure mode Carmack just described, faster, with better dashboards hiding it.