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.

Plans get refuted by reality the moment reality shows up.

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 least a credible prototype, is dramatically cheaper than it was even two years ago. Not free. Not perfect. But cheap enough that the calculus has shifted. Teams I talk to are increasingly skipping straight to a real change as the venue for discussion, because the real change carries information the design doc cannot.

A design doc tells you what someone thinks the system will do. A working change shows you what the approach actually looks like when it meets the real system. Those are different artifacts. They always were. We just couldn’t afford to find that out cheaply.

When the artifact moves, the collaboration moves with it. That isn’t a new pattern. It’s the pattern. It just got obscured for a few decades by how expensive the artifact was to produce.

Where Software Becomes Multiplayer

Reviews are where software development becomes a multiplayer game.

Most of the conversation about AI in development right now assumes a single-player game. One developer, one terminal. The narrative is about productivity multiplied for an individual. Sometimes about the solo founder shipping a whole product. Those stories are real, and I’m genuinely happy for the people doing this. The accessibility is great. And the solo builder isn’t really alone anymore – agents build and review alongside them as they go, and what one person can ship has grown dramatically.

But there is always a ceiling on how far a single-player game can take you, even with agents. Software that lasts, software that grows, software that people can actually depend on – that is built by groups of people exercising judgment together over time. By teams developing shared taste, shared mental models, shared sense of what their product should be. None of that happens through individual prompting, no matter how clever the prompts.

Reasonable people will disagree about whether agents are teammates or tools. I think they fall somewhere in between. But as long as people are building together for people, we’re the ones who assign value.

Code review is one of the primary places where the multiplayer game actually gets played. It is where one person’s judgment encounters another’s. Where taste gets argued. Where shared understanding gets built. Where a team becomes a team and not just a group of individuals shipping in parallel.

The discourse about AI in development is heavily skewed toward the solo experience because the solo experience is where the gains are most immediate and easiest to see. The much harder, much more interesting question is how groups of people work together with these tools and with each other. We’re still working on that.

What I am fairly certain of is that we will keep collaborating over the core deliverable unit – a change to the product. That part looks durable. And it’s the combination that makes review more central, not less: the game is multiplayer, and the artifact it’s played on is increasingly the real change itself.

Code Is Becoming The Currency

The change to the product is becoming the primary artifact engineering teams reason about. Not the only artifact. Strategy still exists. Roadmaps still exist. But the unit of work that gets debated, refined, and committed to is increasingly a concrete change in a real system, not a document describing one.

It may even be that code is becoming the currency for engineering decisions. The thing you trade in. The thing you accumulate. The thing that, if it doesn’t exist, the decision isn’t quite real yet. Anything that doesn’t eventually manifest as a change to a system risks not really mattering.

And currency gets spent. When code is cheap, trying something and throwing it away is often the fastest way to settle a question. That changes how we use the artifacts themselves: closed PRs become part of the process, not a failure end state. The prototype that showed an approach wouldn’t work did exactly what it was for. Some of the most useful changes never merge.

Some Choices Can’t Be Walked Back

There is a quieter argument for code review that gets lost in the velocity debate. Some choices, once they meet the world, can’t be undone. Even if you roll them back.

I’m watching this play out across the industry right now. Teams test new behaviors by throwing them over the wall, because the rollback feels technically cheap. Push the flag, ship it, see what happens. If it goes badly, flip the flag back. The behavior is reverted. Remove the code. Done.

Except it isn’t done. Users saw it. They formed an opinion. They wrote posts about it. They told other people. The trust that took years to build took minutes to dent. You can roll back the code. You can’t roll back what people now think about your product.

This is the category of decision that no amount of observability catches in time. The instrumentation does its job perfectly. It’s just that learning the ground truth in production requires being in production – and for these choices, by the time you’ve learned it, the damage is already done.

Pre-deployment judgment earns its keep here. Code review is one of the few places where someone can look at a change and ask, “even if this works exactly as intended, do we want our product to do this in the world?” That question doesn’t have a runtime answer. It has to be asked before the artifact meets users.

The artifact moving doesn’t change this. If anything, it sharpens it. When working changes are cheap to produce, the temptation to ship and see grows. The discipline that the cost of code used to enforce by accident now has to come from somewhere on purpose. Increasingly, that somewhere is the review.

What Doesn’t Move

Some decisions still need to happen before any code gets written. Org-scale architecture. Customer-facing commitments. Security and compliance posture. Things that cross too many systems to fit in a single change, or whose blast radius is too large to discover empirically.

That boundary is real. It is also, I notice, smaller than it used to be. Prototypes are cheap enough now that even some of those decisions are getting informed by a real artifact much earlier than they once were. The set of choices where “you can’t possibly try this before we agree on it” applies keeps shrinking. Not to zero. But the line keeps moving.

Not A New World

This is a return to form. Linus was looking at patches because that was the artifact. At Parse, we reviewed APIs inside the pull request because that was the artifact. The teams I worked with at Firebase and Google Cloud did some of their most important judgment work on real CLs, not abstract proposals.

For a while, the cost of producing the artifact pushed a lot of the judgment upstream into proxies. That made sense. But the proxies were always imperfect approximations, there to enable decisions we couldn’t yet afford to make on the real thing. The act of looking at a real change and deciding whether it should be part of a system is the engineering job. It does not happen after the important decisions have been made. It is increasingly where the important decisions get made.

If you came away from the last post thinking “yes, but the judgment should happen earlier,” I’d gently push back. It was never really earlier. We were doing our best to approximate it in a world where the real thing was too expensive to produce on demand.

That world is changing. The cost calculus is shifting. But the game is the same one it has always been: multiplayer. The difference is that now we get to play it with the real thing.