What John Carmack's Quake Regrets Teach Us About Shipping Products

A rare admission from a legend

John Carmack doesn't spend much time looking backward. So when he posts a thread reflecting on the mistakes made around Quake, the decisions he thinks ultimately hurt id Software, it's worth paying attention. This is the engineer who built the technology behind Doom and Quake, games that defined an era and seeded an entire industry.

The interesting part isn't the nostalgia. It's that the mistakes he names are the same ones I watch companies make today when they build software and AI products. The technology changes. The decision-making traps don't.

The ambition trap

Quake was supposed to be everything at once: a new engine, a new genre, a new design. The team had built something remarkable with Doom, and the natural instinct was to make the next thing bigger in every dimension simultaneously.

That's where projects get into trouble. When you try to push the technical frontier, the design frontier, and the schedule all at the same time, you don't get one great product. You get a stretched team and a series of compromises nobody planned for.

I see the same pattern in AI projects right now. A company wants a custom model, a novel agent architecture, a polished UI, and a launch date, all on the first build. Each piece is reasonable on its own. Stacked together, they multiply risk.

The hardest discipline in product building is deciding what you're not going to do in version one.

Where the lessons apply to AI products

Carmack's reflections translate cleanly into how I approach agentic AI and automation work. A few principles I hold onto:

• Separate the bets. If you're proving out a new technical capability, don't also bet the company on an untested business model in the same release. Take one frontier at a time.
• Protect the core. id's strength was its engine technology. When attention gets pulled in too many directions, the thing you're actually best at can quietly degrade. Know what your core advantage is and defend it.
• Ship to learn. Quake's troubles came partly from long stretches of building without shipping. With AI agents, the feedback loop matters even more, because real user behavior reveals failure modes no internal test will. Get something usable in front of people early.
• Watch the team, not just the tech. Many of Carmack's regrets are about people and process, not code. Burnout, misalignment, and unclear ownership sink more projects than any technical limitation.

Why this matters for AI development specifically

AI projects are unusually prone to the Quake trap because the technology itself is moving fast and the temptation to chase every capability is constant. New models ship monthly. There's always a more ambitious architecture you could attempt.

The teams that succeed treat AI as a tool in service of a concrete outcome, not a frontier to conquer for its own sake. They scope tightly. They build a working slice, put it in front of real users, and expand from there. The model choice and the clever orchestration come second to a clear answer about what problem you're solving and for whom.

That's not a knock on ambition. Carmack is one of the most ambitious engineers alive. The point is that ambition needs structure, or it turns into a pile of half-finished bets.

How I approach it

After 22 years of building web, mobile, and now AI products, my bias is toward shipping focused systems that earn their complexity. When I build an AI agent or an automation system for a client, the first question isn't "how advanced can we make this." It's "what's the smallest version that delivers real value, and how fast can we get it running."

The ambitious version still gets built. It just gets built on top of something that already works, with real usage telling us where to invest next. That's the difference between a product that compounds and one that collapses under its own scope.

Carmack had to learn some of this the hard way, decades ago, on one of the most influential games ever made. The good news is the rest of us get to learn it from him.

If you're weighing an AI or product build and trying to figure out where to focus first, that scoping conversation is exactly the kind of work I do. Sometimes the most valuable thing I can offer a founder is help deciding what to leave out.