← all posts

Code Review Isn't Dying. It's Moving Upstream.

The old review happened at the pull request. The questions that matter now can't be caught in a diff, so the review didn't disappear. It moved earlier, to the whiteboard and the hard question asked before a line got written.

People keep saying AI is killing code review.

It isn't. It's moving it upstream.

The "code review is dead" take is half right, which is what makes it misleading. One specific layer of review really is getting automated away. But review as an activity didn't vanish. It relocated to a place that was always more important and is now impossible to skip.

The old review lived at the pull request

For a long time, "review" meant the pull request. You opened the diff. You read the logic line by line. You checked the edge cases, flagged the messy bits, and left comments on the parts that smelled wrong.

That layer is getting automated, and honestly, it should be. The machine is genuinely good at "is this line correct." It catches the off-by-one. It notices the unhandled error. It flags the test that doesn't assert anything. It does the mechanical pass faster and more consistently than a tired human at 5pm, and it never gets bored on the four hundredth file.

If your definition of code review was that mechanical pass, then yes, from where you're standing, review is dying. But that pass was never where the expensive mistakes lived. It was just the most visible place to look for them.

The review didn't disappear, it moved earlier

Here's what actually happened. The questions that matter most can't be answered by looking at a diff, so as the diff-level pass got automated, the real review slid upstream to where those questions live.

The cheap part of review got automated. The expensive part got pushed up to where it always mattered most.

It moved to the design doc.

It moved to the boundary.

It moved to the conversation before anyone opened an editor.

Because the questions that decide whether a project succeeds were never "is this line correct." They're:

  • is this the right thing to build at all
  • does this belong in this service, or did we just put it where it was easy
  • what happens to this under load, six months from now
  • who owns it when it breaks, and can they recover it

You cannot catch any of those in a pull request. By the time there's a diff, the decision is already made and the code is just the receipt. You catch them earlier or you don't catch them, and "don't catch them" is how a clean implementation of a bad idea sails through every automated check you own.

Why this is the same review, not a new one

It's tempting to call upstream review a different discipline. It isn't. It's the same instinct, applied before the cost of being wrong gets baked in.

Reviewing a diff asks "did we build this right." Reviewing a design asks "are we building the right thing." The second question dominates the first, because a flawless implementation of the wrong boundary is still wrong, and now it's wrong with tests and a green pipeline. This is exactly why the review moved up the stack: when the implementation is clean by default, the only mistakes left worth catching are the structural ones, and those were decided upstream.

It's also why architecture review beats code review in raw leverage. Same force, viewed from the calendar instead of the org chart. The valuable review keeps migrating toward the moment the decision gets made, because that's the last cheap moment to change it.

What this means for how you work

If review is moving upstream, then a few habits stop being optional:

  • Write the thing down before you build it. A design doc isn't bureaucracy, it's the artifact the most valuable review now operates on. No doc, no upstream review, just an expensive surprise later.
  • Ask the hard question early, out loud. The cheapest moment to kill a bad boundary is in a conversation, before it has data in it and teams depending on it.
  • Stop measuring review by diff comments. If your team's review culture only rewards line-level nitpicks, you've automated away the part you reward and ignored the part that matters.
  • Treat the design review as the real gate. Architecture is what happens after success, and the only place to influence that is before the code exists.

Not dead. Promoted.

So when someone tells you AI killed code review, the accurate response is that AI automated the cheap layer and promoted the expensive one. The mechanical pass got handed to a machine that's better at it than we were. The judgment pass got pushed up to the design, the boundary, and the conversation, where it was always going to be the part that actually decided the outcome.

Code review isn't dying. It's finally being done where it counts.

The one-line version

AI didn't kill code review. It automated the cheap part and pushed the expensive part upstream, to the design and the boundary and the conversation before a single line got written.