Software Is Not A Single-Player Game

When I wrote a few months ago that code review is not about catching bugs, the most common pushback I got was a variation of the same thing:

“If you’re only getting to that decision at the code review stage, you skipped a step. The basic call about whether to build this should have come much, much earlier – at the design doc stage, before code was written.”

I find that argument partly right. The earlier steps it points to – thinking through what to build, why, with what shape, at what cost – are real and important. They don’t disappear in a faster cycle. If anything, they matter more.

Here is something this pushback concedes without quite meaning to. By saying “you skipped a step,” it acknowledges that the SDLC has multiple stages where judgment matters. It doesn’t claim the only judgment left happens in production, or that pull requests are a relic. On that, I agree.

What it gets wrong is the shape of those stages. It treats them as fixed, sequential, and largely complete before code is written. They never were. AI is making the rigidity less tenable by the day.

Underneath all of that is a deeper assumption: that the multiplayer part of software ends before the code exists. People hash things out in documents and meetings, and then development itself is a single-player game. Get the upstream call right and the rest is execution. Code review becomes a checkpoint to verify individual work, and the optimization is to make the checkpoint smaller and earlier.

Much of the current AI development discourse goes further and assumes there was never much of a multiplayer part at all. Either way, the assumption has a ceiling.

What I actually want to argue is that building software that lasts, grows, and that people can depend on is and will remain a multiplayer game. The earlier stages this pushback points to are part of that game, not separate from it. Code review is one of the primary places where the game gets played, and the artifact the game is played on is shifting in a way that makes review more central, not less.

A Brief History Of Looking At Real Things

Before GitHub, before Gerrit, before any of the modern code review tooling, Linus Torvalds was reviewing Linux contributions as patches sent to a mailing list. People wrote code. They mailed it to him. He read it. He had opinions. Sometimes he had loud opinions.

That was the review. That was the place where the decision about whether a change belonged in Linux actually got made. There were no PRDs preceding those patches. There was no architecture committee signing off in advance. There were arguments on a mailing list, and then patches, and then more arguments about the patches.

The lineage is right there in the name. When git arrived, maintainers started emailing Linus requests to pull from their trees – git still ships a command called git request-pull that writes the email for you. The pull request button you click today is named after a message asking Linus to take your changes.

I’m not arguing this was the right model for every team or every product. I am arguing that the act of bringing a real, concrete change to a community for judgment is not a recent invention, and it is not subordinate to a separate planning phase. It has always been one of the moments where consequential engineering decisions actually get made.

PRDs As Workaround

The argument that judgment should happen “before the PR” comes from a real place. For most of software history, writing code was the most expensive step in the process. If you got to a working implementation and realized it was wrong, you’d burned weeks. So we invented a lot of upstream infrastructure to reduce the cost of being wrong: PRDs, design docs, architecture reviews, RFCs.

I ran an API council at Firebase for over five years, reviewing somewhere around 850 proposals before any code shipped. That is about as upstream as engineering judgment gets. I’m not knocking the practice. We caught things that would have been much more painful to walk back.

But I think it’s worth being honest about what was happening. We were reviewing words about code we couldn’t yet afford to produce speculatively. The document was a proxy for the artifact. We were doing our best to apply judgment to an abstraction because the real thing was too expensive to make twice.

When the artifact is cheap, the balance shifts. The document might survive, or it might not. The judgment we were applying through it still has to happen somewhere – and more and more often, it’s cheap enough to just discuss the actual implementation.

The Artifact Moved

Engineering collaboration tends to gather around the cheapest meaningful artifact. For decades, the cheapest meaningful artifact for serious discussion was a design doc. Producing one was much faster than producing the code it described. So that’s where teams pushed and pulled on each other.

The cost curve has bent. Producing a working change, or at...