Write code however you like. Use AI, use 10 parallel agents, write it by hand. I don't care. But this idea that because we can write code faster, we should lower the bar for merging it? That doesn't make any sense.
I guarantee you, spending 10-15 minutes actually reviewing your co-worker's PR is worth it. Not just in the context of that single change, but more so for your rapidly evolving codebase that's adding tens of thousands of lines of code each day. Hear me out:
Don't say LGTM if you didn't look
We've all seen it. A 500-line PR getting a LGTM within 2 mins. Nobody actually read it, but it's now a part of your codebase. Which means the next time you use an AI tool, this is the code that it is going to refer to.
This leads to the classic "Broken Windows Problem": poor quality code keeps piling up, AI tools refer to the same mess (which makes the newly written code, you guessed it, also s**t)
AI is very much capable of writing good code, but it all depends on:
- the context you give
- the references the codebase provides
Let's talk about the second one: how to ensure the quality of your references.
Step 1: The first time you are doing something new, slow down, spend some time and do it the right way. Once you feel that it's solid, ask your team for thoughts and suggestions. Keep iterating till the team's happy with the PR. You don't need to be perfect, "almost there" works as well.
Step 2: The next time when you or a teammate is doing something similar, the pattern already exists and your AI tools have a good reference. Hitting that same quality bar would take a fraction of the time. And the PR reviews? A breeze.
Congratulations 🎉 ! Your PR turnaround time (the time between opening a PR and getting it approved) is roughly the same even with a thorough review.
Code reviews are the cheapest KT
With AI making us more productive, teams are getting smaller. A project that previously needed 5-6 engineers now only needs 2 — one who owns the backend and one who owns the frontend. This is great, but leads to a concentration of knowledge and creates a dependency on these devs.
What happens if they leave the company? Get sick? (the classic "bus factor")
This is where good PR reviews come in. They help distribute knowledge of the codebase among the team. Reviews ensure that a few more folks have at least a basic idea of the person's code, which makes it easier to either assign a new owner or hire a new replacement.
This is just one of the "obvious" benefits of having a shared understanding. There's more:
-
If you're a new team member, PR reviews are a godsend (full disclosure — I am an atheist, so I don't say that lightly!). Along with helping you understand the code, reviews help you figure out how the team thinks, what "good enough" looks like here, what tradeoffs they're comfortable with, and a lot more.
And it works both ways — a fresh pair of eyes on existing patterns often helps spot things that a team has gone blind to.
You'll never get to work with every talented developer on your team. But discussion with them in PR reviews (be it their code or yours) is an extremely good way to learn how they think and benefit from it. You may see some pattern that they use or an ideology that they follow, which you too end up adopting.
Your best idea might not be the best idea
I read a lot of blogs, and sometimes while reviewing a PR, one of them suddenly comes to mind and the approach it suggested is almost always better than what we originally had.
That's the thing about reviews. You (and your AI agent) may only have considered a few before picking the best. But a reviewer, looking at it from a different perspective, may end up suggesting a completely different approach that turns out to be simpler.
The benefit is two-fold: the code is better and your teammate knows you actually read the PR :)
It's funny how reviews improve your thinking even before you make the PR. Knowing that someone will review the code automatically makes you double-check your decisions.
Make it work. Make it right. Make it fast. In that order.
Don't just stop at the first one.
