How to do effective code reviews

I talked about this a couple of years ago in a video. Back then I thought the points were obvious. Break your PRs down. Don’t argue in comments. Review your own code before asking others to. Be kind. If you have been on enough teams, none of this should surprise you.

Lately I keep reading the same take online: PRs are the new bottleneck. People can generate so much code with AI now that reviews can’t keep up. The process is holding us back.

I don’t buy it. The bottleneck was never how fast you could write code. It was always how you worked. PR size, task breakdown, how you communicate, how you treat each other in reviews. That was true before AI and it is true now. The only thing that changed is that it’s easier to produce a huge mess faster.

I have been doing code reviews for a long time. I have seen reviews that made people better and reviews that made people dread opening a pull request. I have seen a lot of reviews that were just noise pretending to be rigor.

Most of the problems are not technical. They are human. That part has not changed.

Myth versus reality

A lot of developers treat code reviews as a performance. They leave comments to show how much they know, how many edge cases they can spot. That’s not reviewing code. That’s showing off.

You are there to understand what your colleague has been working on. To learn the domain. To catch things they might have missed because they have been staring at the same code for three days. Not to prove anything about yourself.

If you are good at what you do, you uplift others. You help them. You do not put them down. Even when seniority requires you to push back, you do it with kindness, because we never know how our words affect others.

Set up your team before you review anything

Code reviews do not work well out of the box. You have to set up your team for them.

The biggest waste of time in reviews is arguing about style. Formatting. Naming conventions. Bracket placement. None of that belongs in a pull request discussion. It belongs in your tooling.

Set up pre-commit hooks. Run linters, formatters, and whatever static analysis your language supports before code even leaves someone’s machine. Then run them again in CI. If something would fail in your continuous integration pipeline, it should never leave a developer’s local environment. If it does, the setup is wrong.

Once you remove style from the equation, reviews become about what actually matters: functionality.

The other thing that saves enormous time is agreeing on code principles as a team and writing them down. How do you structure modules? How do you write tests? Where do utility functions go? Do you use classes or plain functions? Every team answers these differently, and there are dozens of decisions like this.

Document them. Then when a discussion comes up during review, you point to the document. That is where the discussion ends. You do not relitigate the same thing every two weeks.

This also helps when onboarding new people. They read the conventions, understand how the team works, and can start contributing without guessing.

Focus on functionality, not style

Once the tooling handles formatting and the team has agreed on principles, your job as a reviewer is to focus on the feature itself.

Does it work? Does it deliver what the ticket described? Are there regressions? Are there edge cases the author might have missed?

Use the review as a chance to learn what your colleagues are building and why. Stay in context. Know what features are being worked on across the team. If someone adds you as a reviewer and you have no idea what the feature is, that is partly on you.

You can still leave comments about small things. But frame them as opinions, not demands. “I would probably do this differently” is very different from requesting a change on something that is a matter of taste.

Stop arguing in GitHub comments

This one I catch myself doing almost every month, and I have to actively pull myself out of it.

If a PR discussion goes past five messages back and forth, stop. Close the laptop. Call your colleague. Get on a video call. Sit together if you are in the same office.

Arguing in GitHub comments for two hours does not increase anyone’s productivity. It widens the disagreement because text strips out tone and intention. One of you gets triggered, and from that point on you are not even discussing the code anymore. You are defending positions.

It also sets a bad example for the rest of the team. Other people read those threads. Long comment wars feel divisive. They make the process feel adversarial. And the resolution of a two-hour thread is almost never worth the combined time that went into it.

If something needs a discussion, have it in real time.

Use the right medium

Not all reviews are the same, and not all of them should happen the same way.

For simple changes, comments work fine. For anything more complex, give the reviewer something to look at. Screenshots, videos, whatever helps them understand the change without having to pull the branch and run it locally.

If you did UI work, drop a screenshot of before and after right in the PR description. We do this on every visual change. A screenshot of how it looks now and a screenshot of how it looks with the change. The reviewer can instantly see what changed without reading a single line of code first. It takes thirty seconds to do and saves minutes of context-building on the other end.

Videos help too, even for non-visual work. Record your screen for two minutes, walk through what you built, explain why you made certain decisions. Paste the link in the PR. It brings clarity that text never will.

For the big changes that could not be broken down further, pair programming is the way to go. Sit together, go through it, even if it takes a couple of hours. If the feature is big enough to justify two thousand lines of code, it is big enough to justify a focused review session.

Large PRs are the enemy

There is a well-known paradox in code reviews. You push a twenty-line commit, someone leaves ten comments. You push two thousand lines, you get one comment: “looks good.”

Large PRs are overwhelming. People open the diff, see two hundred files, and give up. They rubber-stamp it because the alternative is spending half a day trying to understand something they do not have context for.

Breaking tasks down into smaller chunks is the fix, and it is one of the skills developers are worst at. It matters more than most technical skills. Good task breakdown leads to small PRs. Small PRs lead to reviews that actually catch things.

This is exactly why the “PRs are the new bottleneck” take is wrong. People see AI generating code faster and conclude that reviews are what’s slowing them down. But that was never the hard part. The hard part was always making sure the code is correct, that it fits the system, that somebody else on the team can look at it and understand what happened. None of that got faster because a machine typed it. If anything, it got harder, because now you can produce a three-thousand-line diff in an afternoon without even thinking about how to break it down.

Ship incrementally, review incrementally

Feature flags make this practical. Hide the work behind a flag, push to production from day one, and build the feature in slices.

Say you are building a dashboard with a handful of widgets. Do not build the whole thing and open one massive PR at the end. Push an empty dashboard page. Review it. Merge it behind the flag. Then add the first widget. Review, merge. Then the next. Each PR is small, focused, and easy to review. The feature grows in production, and anyone who needs to follow the progress can just toggle the flag and see where things stand.

Same thing on the backend. You are building an API. First PR: a single endpoint that returns hello world. Merge it. Next: add authentication. Next: hook up the database and define the schema. Next: the actual business logic. Each step is reviewable in isolation, each step works on its own, and at no point does someone open a diff with forty files and give up.

This keeps PRs small without artificial splitting. It gives stakeholders visibility into progress without you having to schedule a demo or write a status update. The work is always there, always accessible, always moving forward.

It also changes how the team thinks about task breakdown. When you know every slice has to be deployable on its own, you start breaking work down differently. You stop thinking in terms of “the feature” and start thinking in terms of the smallest useful increment you can ship next. That skill transfers to everything else.

When there is nothing to say

Code reviews are not a requirement to leave a comment. If you look at a PR and everything looks good, approve it. You do not have to agree with every line. You do not have to find something to nitpick.

If there are no problems, approve and move on.

Review your own code first

Before you open a pull request, review your own code.

Push your branch. Create a draft PR. Open the diff view. Read through it yourself. Remove the debug statements, the commented-out code, the things you forgot to clean up. Do not make your colleagues spend their time catching things that you should have caught in thirty seconds.

This goes double when AI wrote some of the code. If you didn’t write every line yourself, you owe it to your colleagues to at least read and understand the diff before you ask them to. You can’t push code you don’t fully understand and then expect someone else to make sense of it for you.

Once you have reviewed it yourself, run it through whatever AI code review tools you have access to. There are plenty of them now. Let them catch the obvious stuff before a human ever looks at it. Unused imports, potential bugs, missing edge cases, inconsistent naming. If a machine can flag it in seconds, there is no reason a colleague should be spending their time on it.

Your colleagues’ time is the most expensive resource on the team. By the time someone opens your PR, it should have already passed your own eyes and whatever automated reviewers are available. What is left for the human review is the stuff that actually needs a human: architecture decisions, business logic, whether this fits the broader system.

Hierarchy does not make you right

If you are a senior developer, a tech lead, a CTO, your title does not make your point stronger. Having a role does not mean other people cannot have a better argument.

I say this as a tech lead myself. Build a culture where the best idea wins, not the highest title. If a junior developer has a valid point, that point stands on its own. If you use your seniority to shut down discussion, people will stop bringing ideas to you. They will stop pushing back. And your team will get worse.

Exceptions will happen

Everything I have said here applies most of the time. Not all of the time.

There will be Fridays when something breaks and you have to push a fix without a proper review. There will be emergencies where someone has to approve their own PR. There will be large changes that could not be broken down further.

That is fine. Especially in startups. But the goal is to make those exceptions rare. The baseline matters. The habits matter.

Be kind

If I had to reduce everything about code reviews to one sentence, it would be this: be kind.

Be kind in how you phrase your comments and how you talk about someone else’s work. Code was written in a specific context, under specific constraints, with whatever information was available at the time. Do not trash it. Do not call it bad.

Because if you do, nobody will want to talk to you. People will be reluctant to ask you questions. They will dread your reviews.

Code reviews exist to make your team better. To catch mistakes before they reach users. They are not a competition.

Show up with humility. Remove your ego.