Is Code Review Dead

Hey there, it's been a while, and I apologize for the 5-month hiatus. Life got in the way and I was dealing with a lot of uncertainty between my last post and now, so thank you for still sticking around!

Between then and now, I'm pretty sure you've seen a massive proliferation of AI agents taking over the codebase. We cycled through what seems to be endless waves of new trends in software development, from harness engineering, to context engineering, to loop engineering, and now graph engineering.

As the amount of code produced by each engineer skyrocketed, the bottleneck in building software has now shifted to the code review phase. To keep up, there's been an explosion of experimentation with, and adoption of, dedicated AI code review tools meant to ease the burden of keeping up with all that output. Naturally, this has led many to question the value of human code review, and whether it will even be a thing in the future. Should we delegate reading and reviewing code to agents and verification systems, or should human engineers still make an effort to stay in the loop, line by line?

A Trip Down Memory Lane

For readers with a non-technical background, let me motivate the problem a bit better. Let's travel back to the summer of 2023, when I did my first internship. At the time, I was working for a fintech company based in Atlanta, where my job was to build custom software supporting daily operations of banking clients. The world was just getting giddy over the release of GPT-4, hand typing your code was still very much a thing, and I was happy someone took a chance on me when all I could offer was curiosity and a handful of CS courses under my belt.

Back then, code review was a relatively hands-on and involved process. A PR, a piece of change introduced into the codebase by any engineer on the team, was sent out for review, and a human on the other end would ideally sit with it: reading through the change line by line, leaving comments, asking clarifying questions. The process could go back and forth for days before the code change got accepted. It was slow by today's standards, but it was slow by design. As a new engineer, through this process, you would pick up conventions (or code best practices), catch your own blind spots, and absorb more context about the codebase simply by being in the review loop and on both sides of it.

Current State of Affairs

Fast forward three years, and that process barely resembles its old self. The friction I described above, the back and forth, the days-long threads of comments, is exactly what most teams have spent the last few years trying to engineer away. And perhaps for good reason too: it was slow, and slow doesn't scale when a single engineer can now produce ten times the code they could in 2023. So companies do what they do best and optimized.

Across the industry, from my own experience, I've seen much more willingness to incorporate and embrace AI tooling to help with code review. These tools catch linting issues, run automated test suites, use AI as a judge to perform a preliminary pass, and suggest improvements before a human ever looks at the PR. There's even risk assessment baked in now, scoring how likely a given PR is to cause a SEV (yikes).

Another approach that's also been widely considered is shifting the focus from reading code line by line to verifying it instead. The idea is that with good enough harnesses and verification systems in place, the code produced reaches a high enough level of trust that, as long as the verification mechanisms pass (automated, manual, or some combination of both), engineers don't need to re-read every line themselves.

Nonetheless, the general attitude around merging code changes has quietly shifted from "review carefully before you merge" to "ship it and ask for forgiveness later." It may be a more forgiving philosophy, sure, but where does that leave room to grow for human engineers? How do juniors develop technical judgment (knowing when AI is wrong) now that AI has offloaded much of the grunt work that used to force us to slow down and actually use our critical thinking skills?

If you can't read, how can you write, and vice versa.

So, Is Code Review Dead?

As software engineers, we're paid to deliver results. Management rarely cares about the engineering approach we take, as long as the product ships on time and with the quality expected in the contract. Used well, AI can help strike a balance between speed and rigor, and it can help teams better meet stakeholder expectations. But relying on it entirely, accepting suggestions as-is without much critical thought or deliberation, without slowing down and introducing the necessary friction, severely hampers one's ability to grow and mature in technical depth. I don't believe code review is dead, but I do think it's becoming a much larger personal commitment, one you have to choose to make for the sake of your own skill development. That means staying close to the code and being willing to sit with the discomfort of struggling through many revisions of it, even when a faster path is right at your fingertips.

Regardless of which camp you fall into, too much thorough code review is burning engineers out and making the job a lot less interesting. I've seen firsthand how people who used to review code with real scrutiny now blindly accept changes if the AI reviewer leaves no comments on the PR. As we each produce more and more code, that kind of quiet erosion of diligence becomes a risk, especially since there's no standard best practice yet for what "good" code review even looks like in the age of AI.

Principles I Try to Keep as a Junior Engineer

As a junior engineer myself, I've spent a lot of time thinking about what the future holds, whether traditional ways of learning on the job still work, and what I need to do to grow to the next level amid this constantly shifting landscape. There's no senior engineer I can ask who went through exactly what I'm going through, because none of them learned to code review in a world where the first draft of every PR might already be AI generated. The playbook I was handed during my internship, the one built on slow, deliberate, line by line reading, doesn't map cleanly onto a job where the volume of code has outpaced anyone's ability to read it that way.

So I've had to write my own playbook, mostly by battle-testing which shortcuts have benefitted me in the mid to long run, and which ones improved my productivity at the cost of skills atrophy. Nowadays, on the job, I try to stick to a short list of non-negotiables, small moments of friction I introduce into the code review process for the sake of my own skills development. They are as follows:

1. Understand PR intent before reading code. Read the diff and PR summary first, and summarize it in my own words: "this is supposed to do X." If I can't restate the intent clearly, I'm not ready to evaluate whether the code fulfills it.
2. Trace the most complex logic path or component in the code (AI can help flag this) to see if it matches intent. It's important to add friction back into this step for your own skill development, tracing the logic by hand rather than letting a summary do it for you and thinking you "sort-of" understood how things work.
3. Skim the other parts of the code to see if it matches user intent. Not just does it run, but does it do the thing the PR claims to do. If the author didn't explain the PR intent well enough, it's usually a good sign to leave some comments to follow up, mainly to confirm you've actually understood what the author wants to do, and whether the code reflects this or not.
4. Audit tests to see if the author missed edge cases. If I'm short on time, this is the section I'll allow myself to skim, but I try not to skip it entirely. Tests are often where the real assumptions about the system are hiding.
5. (Optional) Log one thing before you approve. If possible, before approving, I make a note of a pattern I did not know before, a technique worth learning more about, or a gap in my own knowledge when reviewing the code. Over months, these logs become my record of growth and notes I can fall back to.

With that said, I would be lying if I say I knew what code review will look like a year from now. But in the meantime, I'd rather go slower and stay a lot closer to the code than let my skills atrophy entirely. The tools will definitely keep changing. The discipline of actually understanding what you're producing, though, doesn't have to.