A Farewell to Code Reviews

Code reviews are dead and only now do we begin to notice. Hardly the only or most important casualty of the great AI leap, but an important one nonetheless.

For quite some time we had a good thing going and I will remember it. Maybe you remember it too or maybe you never experienced the tech industry before 2025 and want to know what it was like. Let me tell you how it was.

The Author

Code review is many things. On its mechanical, bodily level, it is an act of reading through a diff. A pull request. A unit of change that is asking for permission to enter the repository. It is a shared space and it must be kept in order. So you need to show respect.

A pull request should be presentable. You have to think about it long before you push your branch. It can't be too big – nobody likes that. It should have a description – this is where you provide additional context and explain anything that can't be easily inferred from the code. This is also the final destination for future code archeologists who will smell your blood in git blame and judge if your decisions stood the test of time.

So make it nice. Some pre-emptive comments are always appreciated, although they might be used against you as evidence of code not being clear enough. "I see you felt the need to clarify this piece of code, interesting," some reviewers might say.

Usually, there is also CI. A set of automated checks that run against your PR. Compile, lint, test. The first line of defense. You'd better make sure the build is green before assigning reviewers or you'll have to come up with sorry excuses. "Huh, CI is failing, I'll look into it later." Sloppy job and an easy way to part ways with some street cred. Unless the tests are flaky, of course, in which case you have a choice to rise to the occasion and fix them, or meld into collective inaction. Some people might remember what you chose.

When all rituals are complete, it's time to assign reviewers. This, too, can be delegated to a machine! Can be a single very important person, somebody with authority. You can bet they are too busy these days to write code themselves. Alternatively, a reviewer can be selected at random. Roll a die and let fate decide. Might even add some round robin rules on top, to spread the burden more evenly. What a terrible way to pick a reviewer!

My personal favorite is selecting reviewers myself. Some people assign the whole team! Rookie mistake. A sure way to never get a review. No, you need to pick a single person. One victim. Once you lock eyes, they will feel the burden and the honor in its entirety. No escape from the duel.

The Reviewer

For the reviewer, the diff is a net loss. A nuisance. A necessary, but fundamentally secondary activity. Congratulations, you're on gatekeeping duty! Time to put off your actual work and load a bunch of completely new context into your head. What torture! I just hope there is at least a description.

To be a reviewer is to be tempted. "Cut corners, skim through, LGTM" – you hear a voice inside. Hm... No, no, you can't. It's your job. And there might be consequences! If the code is bad, it poisons everything around it. One broken window will lead to another. Toxins accumulate in the body. You need to be strong. And that would be disrespectful, wouldn't it? The author put in the effort, after all. Let's see.

A good reviewer starts from the top. What is this change for? What is it trying to achieve? Is this the right thing? If so, is this the right approach? First comments can land before a single line of code is even read. Those are brutal, but most valuable.

Then, if everything looks good, time to look at the code. Don't look too closely though, we're not quite there yet. Just the big picture. This is what it is now, but what could it be? Maybe there's a better way to compose functions? A simpler model? How would you do this? A costly mental exercise, but a good author will appreciate it.

Finally, the trivial part. Just read the code, poke holes in the solution. This is a mixed bag of cute little TILs and nits, variable names and code golf. A token effort, but most common.

The Ritual

Code review is many things. It is a form of asynchronous communication. An avenue for knowledge sharing. A learning opportunity. A safety net.

It is also a battleground. And an asymmetric one! One side is defending, another attacking. Things can get heated. You need to be careful with that. Wrap comments in questions. Assume good faith and make self-deprecating jokes. Attach GIFs. Use objective measures when possible – it's often hard to agree on what is "simpler" or "more declarative". And never invoke your authority directly. That's in very bad taste.

At times, code reviews were proving grounds for people who just joined the team and are going through the inevitable period of friction. A "storming" phase, if you will. Code reviews turn into a ritual dance of testing the new guy and explaining to them our unspoken rules. A fresh pair of eyes is often quick to spot weaknesses, but you'd be foolish to point at them right away. A newcomer needs to be respectful and first demonstrate that they can learn existing ways and contribute on par with the rest of the team. Only then can you voice your concerns and propose changes. A lot of teams are aware of this, of course, and do their best to hold an egalitarian stance and not be defensive. But there's only so much success you can have against a primal force like this, so it's wise to always respect those who came before you.

For me, personally, code reviews were a place of exchange. As an author, I bring the product of my labor for other people to witness, hoping that all the effort and love I put into it will be seen and appreciated. As a reviewer, I am looking for the signs of this effort and in return, pay my respects to the author through thoughtful comments. Tomorrow, we will switch roles and the exchange will repeat.

No going back

Nothing about code reviews survived the AI transition. The code is not the product of human labor anymore, not in the same sense at least. The diffs aren't read with the same scrutiny. Some even argue the code isn't for human eyes at all, and thus readability doesn't matter. No point in sophisticated arguments and thoughtful comments: a coding agent will agree with anything you say and will not learn a thing. And even if you choose to code by hand, you will likely be met by an AI reviewer.

I know there is no going back. Even if some teams still review code the old ways, those are merely uncontacted tribes of the AI age. LLMs invaded the spaces previously inhabited exclusively by humans. They are omnipresent in every PR, every comment and every diagram. Even a team of devoted tradcoders won't feel the same, because they know what they are running from.

I don't know what will replace code reviews or how they will evolve, but I feel like we lost something valuable. I know I have. And I'm mourning.