Time to Nerf Code Reviews

This article is for the people who understand where AI is now. If you think that teams of people are needed to bring features to life, and development doesn't need to change you will not enjoy this article and should leave now. Changes are coming and they do not have to be bad, we just need to evolve to match the new challenges.

Code Reviews made sense but they were far from perfect

Code reviews were always a dogmatic part of the software development process. Try suggesting we relax, or God forbid remove, that part of the process — you will be called a heretic and a person to keep an eye on (true story, well except the "heretic" part). Code reviews always made sense when you had junior developers, or new developers joining you wanted to ease them into your ways. Make sure they are using the correct style, tools, and are not dirtying up the code. You will often hear "they catch bugs" but there are very few developers that actually run the code, and plenty of them who meticulously critique them. So I would say they sometimes catch bugs.

For me it never made sense to have two senior developers, meticulously checking each other's work. You are paying two people $200k/year and they spend hours and hours discussing things that work. "That class is the wrong name", "It is not object oriented, I would prefer to see factory pattern" and other madness some of these people write. Costing the company thousands and thousands, and yes Adam I mean you.

Sad truth is, they very often take a working solution and hold up the process. Sometimes that is ok, but sometimes it is not. Add to that the fact that we are humans and some of us love to exert power over each other, and you have countless points of contention just waiting to be born between team members.

I always saw this but it was hard for me to explain it — how can one even question the holy PR review. Well, the time has come and it is going to become painfully obvious how this little part of your business is costing you... and it is costing you a lot!

Ownership is the way

Where we needed teams we need one developer now per feature, adding more is redundancy and a possible problem down the line. Anything more than one is just a problem — it will be like two monkeys with chainsaws. You could have cut your wood with one, but with two there's a real possibility of them turning on each other. Now that code is cheap they will both have huge solutions that they bring to the table, both solving the same thing and how do they agree which is better? It was hard when there were 200 LOC but now there are thousands — discussions are going to be endless. Of course, this doesn't have to happen, they can play nice — but from time to time developers do not play nice — they like to own things. So let's give them that.

Code was always a big divider in the ownership, somebody likes simple code, somebody likes to have a factory pattern in everything he does. But should we talk about the code still? Yes, we do but not to the extent we are used to. We are not writing it anymore, why do we need to obsess over it. An LLM agent will give you a good solution, if you are really good you will figure out an even better one but the fact is that first one was good enough.

Isn't it better to give ownership to one developer and have him or her come back with the done feature? It's time to judge the product and not the code. That is the reality of this new age we are living in and software development needs to catch up. Product is the only thing that matters (it always was but now it is just painfully obvious).

Evolution of PR

Which brings me to the solution. No more little PRs and constant back and forth on the small things. Developer creates a branch, and builds a feature on a feature branch. Once ready, product and stakeholders take a look, if they like it — it's done! You create a PR, have your favorite LLM review it and call in teammates to review. For small things like bug fixes LLM review is enough unless developer needs second opinion.

Here is the trick when it comes to review of features, you use the Amazon model for this step. Other developer can stop it but they need to write 2-3 pages on why (no more blocking because you do not like that class name or feel that you need to abstract that interface because we will need it someday). That essay needs to be a strong one so when stakeholders read it they do not go berserk over why the feature they need is being held up over something stupid. Write too many stupid essays ... problem will solve itself.

There you go, simple fix for very complex problem. Needless to say there will be many, many of those who will read this and call it heresy again. But time to face some facts, you never did care about the product anyway, you were there to play your code building games and endlessly argue what is the "good code", and your time is coming to an end. Either evolve or go raise geese. Time of the builder is now, and if you love building software it is your time to shine.