← Back to articles

Reviewing the code review

In the last year, many code review practices have shifted from manually reading every line of a merge request to relying heavily on LLM agents. Or sometimes not reviewing at all.

The tech industry has yet to find the right trade-off between human and agentic code review. Here’s how I personally review these days.

My current workflow

I have a “review the review” + “design review” approach.

I ask Claude Code to review a given GitLab merge request (MR), which the agent fetches using the glab CLI. We have an internal skill to give specific review instructions, and I also have a few personal instructions in my local CLAUDE.md file:

Display review comments in the chat, never publish them without my consent
Ask me if I want to publish 1) Must-fix and High 2) Also Medium ones 3) All
Always publish comments as inline comments, except if it's a general comment.
When publishing comments, mention it's authored by an LLM
Don't make comments on MR title or description

While Claude runs, I get a feel for the MR: reading the commit messages and attached tickets, seeing which directory trees are impacted, reading critical sections. My goal is to spot architectural problems. I cannot read everything given the large number of MRs we have to review. I specifically focus on the data part (e.g. database migrations) where there is a clear risk of data loss or decisions that are hard to revert later.

I leave my human comments, and read Claude’s, before selecting those to publish as inline comments in the MR. Most of the comments it produces are relevant, but it sometimes misses trade-offs we deliberately accept in our codebase. I sometimes reply in a thread opened by Claude to add context or nuance. For instance, I may say I’m not confident the comment is correct because I lack expertise on the topic, but a question is better than a missed bug.

I then leave the Claude session open with the review context, waiting for the MR author to add responses and fixes, and ask Claude to read and validate them.

I also handle responses to my human comments, then give my final approval.

Does it work?

To be honest, Claude often finds critical bugs I would not have been able to find, even by spending a lot of time on it. Today, I consider LLM code review mandatory.

Human reviews are still required for the context they bring, and sometimes to prevent big mistakes or out-of-scope changes.

For MRs that bring big architectural changes, it’s still great to do mob reviews where the whole team debates design issues.

As basic hygiene, everybody should self-review their MRs before asking for review (starting from a fresh LLM context). We are rolling out CI reviews, triggered by mentioning @claude in an MR.

Finally, even with the enormous help of Claude, it’s hard to scale the review work due to the number of MRs my team produces.

We are probably going toward an era where the LLM is the real author of a code change. The developer who prompted it then stands outside the code like any third party, and can genuinely review it before asking a teammate to.