Build systems around trust

If your team relies on code review for safety, your system is already broken.

That sounds extreme. It should. Most engineers still believe that reading code is how you get better, and that taste is what keeps systems coherent.

I used to believe that too.

One of those things was true. The other one is still true, but not in the way you think.

The honest case for code review

Before tearing it down, it is worth saying what code review actually did well.

It caught bugs. It enforced patterns. It built shared understanding.

That last one is the real reason people defend it.

When a senior engineer reviewed your pull request, you learned. You absorbed judgment. You saw how the system was supposed to hang together. Over time, that compounded. The people who read the most code developed the strongest intuition, and their intuition became the glue holding everything together.

That was real value. It shaped a generation of engineers.

But it only worked under a specific constraint.

The constraint is gone

Code review made sense when code was expensive to produce and expensive to change.

A pull request was a meaningful artifact. You read it carefully because it mattered. You might see a hundred diffs in a year, and each one was a chance to learn something nontrivial.

That world is gone.

Now a diff can be generated, thrown away, and regenerated in minutes. Sometimes seconds. The artifact is no longer scarce.

What used to be an investment has turned into a tax.

An engineer spending two hours reviewing code that was generated in four minutes is not compounding their judgment. They are doing archaeology on something that was never meant to last. While they do it, more diffs pile up behind them.

You have sat in a review in the last month where you knew, halfway through, that nothing being said was going to change the outcome. And you kept going anyway. Because that is the ceremony.

You can either keep up with the flow or you can inspect every detail. You do not get to do both.

From gatekeeper of the diff to architect of the constraints

For a long time, the highest status engineer was the one with the best taste in code. The one who could read anything, critique everything, and make it cleaner.

That is changing.

The job of a tenured engineer is shifting from gatekeeper of the diff to architect of the constraints.

Gatekeepers inspect what is in front of them. One diff at a time. One decision at a time. Their leverage is bounded by how much code they can read in a week.

Architects design the rails the code runs on. The linters, the harnesses, the test suites, the deployment patterns, the failure modes. Their leverage is unbounded, because every diff that flows through the system inherits their judgment without them being in the room.

That shift is uncomfortable if your identity was built on the former. It should be. A practice that shaped who you are is losing its returns, and no amount of rigor on your part is going to bring them back.

Taste is not dead, it needs a new medium

This is where I disagree with most people writing about AI and code.

They tend to argue that taste is irrelevant now. That clean structure, good naming, and thoughtful abstractions are nostalgic. That we should let the machine produce whatever it produces and move on.

I do not buy it.

Taste is not dead. It is just that the medium for expressing it has to change.

Taste used to live in pull request comments. In the way a senior engineer would suggest a better abstraction, rename a variable, or push back on a design. That was a slow, artisanal channel. It worked at one-diff-at-a-time throughput.

At current throughput, that channel cannot carry the load. If you want your taste to shape the system, you have to codify it.

Your taste belongs in:

linters that enforce it automatically
prompts and instructions that shape how agents generate code
test harnesses that reject things that violate it
architectural constraints that make the wrong thing hard to do
deployment patterns that surface bad decisions quickly

This is harder work than leaving a review comment. It requires you to articulate what you actually believe, precisely enough that a machine can enforce it. A lot of taste, when you try to codify it, turns out to be vibes. That is useful information. The parts that survive codification are the parts that were real all along.

The gatekeeper leaves a comment on one diff. The architect encodes the rule once, and it applies to every diff forever.

"AI writes bad code" is not a defense

This is usually where the argument retreats.

The claim becomes that generated code is messy, inconsistent, or naive.

All of that can be true.

It is also irrelevant.

The question is not whether any individual diff is good. The question is whether the system as a whole behaves correctly and can be changed safely.

If your tests, checks, and monitoring catch bad behavior, then the quality of a single diff matters less than you think.

If they do not catch it, then your system is fragile regardless of who wrote the code.

Reading the diff was never a reliable safety net. It was one layer among many, and it was the slowest one.

Most engineers have missed critical issues in review before. They just remember the times they caught something and felt useful.

The part I do not have a clean answer for

There is one objection I cannot wave away.

If nobody reads each other's code, how do people learn how each other think? How do teams stay coherent as more than a group of strangers shipping black boxes to one another?

Code review was never just about the code. It was a coordination ritual. It was where engineers absorbed each other's judgment, where taste got transferred, where juniors became seniors. Losing that is not a small thing. It is maybe the biggest thing.

I do not have a neat answer. I am not going to pretend I do.

What I can say is this. The mentorship that happened in pull request comments was a side effect of a practice we did for other reasons. When the other reasons go away, the side effect goes with them. Saying "but we need the side effect" does not bring back the conditions that produced it.

Something has to replace it. Maybe it is pairing on architecture instead of implementation. Maybe it is design reviews that actually get time and attention. Maybe it is something we have not invented yet.

I do not know. But I am pretty sure that keeping the ceremony alive for the sake of the side effect is not the answer. You cannot preserve mentorship by reviewing code an agent wrote in four minutes. The learning moment is not there anymore.

This is the open problem. Anyone telling you they have solved it is selling something.

The honest state of verification

I need to acknowledge something before this post gets accused of living in a fantasy.

Most organizations do not have the automated verification loops this argument assumes. Their tests are flaky. Their monitoring covers the happy path and not much else. Their alerts either do not fire or fire constantly and get ignored. Rollback is a multi-hour operation involving a Slack thread and a nervous person with sudo access.

If that is your reality, then yes, removing code review would be genuinely dangerous. The ceremony is doing load-bearing work because nothing else is doing it.

This is not a reason to keep the ceremony. It is a reason to build the thing the ceremony is substituting for.

The opportunity here is enormous. The teams that invest in real verification loops in the next few years are going to look, to the teams that did not, like they are operating on a different planet. They will ship faster, with fewer incidents, with smaller teams. Not because their engineers are better, but because their engineers are spending their time on the right layer.

If you are a tenured engineer reading this, this is the work. Not guarding the diff. Building the rails.

What replaces code review

You do not remove safety. You move it.

Instead of asking humans to inspect every change, you build systems that verify behavior continuously.

You invest in:

tests that actually reflect real usage
monitoring that surfaces anomalies quickly
alerts that fire on meaningful signals
tooling that makes rollback cheap and safe
linters and harnesses that encode your team's taste

You put experienced engineers on designing these guardrails, not on reading every pull request.

Human review does not disappear. It moves up the stack.

You review product decisions. You review architecture. You review user experience. You review whether the system is solving the right problem.

You stop reviewing every line of implementation as if it were the critical path.

The uncomfortable question

Imagine you removed code review from your process tomorrow.

Would your system become meaningfully more dangerous?

If the answer is yes, then the problem is not the absence of review. The problem is that your system depends on humans catching what machines should enforce.

If the answer is no, then you have already done the work. You just have not admitted it yet.

Build systems around trust

Trust is not the absence of control. It is the result of systems that verify continuously.

Code review was a solution to a world where code was slow to produce and humans were the best available validators.

That is no longer true.

Your taste still matters. It just has to live somewhere other than a comment on a pull request. Your judgment still matters. It just has to encode itself in the rails instead of the diffs.

You can keep the ceremony, or you can build systems that scale with reality.

The ceremony is not the work.

The outcome is the work.

– Ismael.