How I Run Code Review

I've reviewed code on teams with review boards and as the only engineer on a project, where the reviewer and the author were the same tired person. Reviewing well is a skill separate from writing code, and it's the one that scales a team past its most senior person. Here is how I actually run it.

AI takes the first pass, a human takes the last

Every change gets an AI review before I read it: unhandled promise rejections, missing null checks, inconsistent error shapes, the forgotten await. That pass clears the mechanical noise so my attention goes where a machine can't help, which is whether this is the right design, whether it matches how the rest of the system already works, and whether it does what the product actually needs.

The order is deliberate: AI first, human final, a human's name on the merge. The model is fast and tireless and occasionally confidently wrong. It proposes; a person still decides.

Comments should show, not scold

The least useful review comment is "this looks wrong." The most useful one describes what the code actually does, then points at the gap. When I review, I try to write the comment I would want to receive:

This handler only does A, B, and C. The behavior you expected (D)
isn't in this path at all, so it has to be coming from one of two
other places: X or Y. Check X first, it's the likelier one.

A comment like that does three things. It proves I actually read the code, it teaches the author how to trace the system themselves, and it turns a vague worry into a concrete next step. Reviews that only ask "are you sure about this?" make people defensive. Reviews that show your reasoning make people better.

What I am actually looking for

Mechanical bugs are the AI's job. Mine is the part that only breaks in production.

• Config and environment drift. The most common non-obvious bug I catch is a value that's right in staging and wrong in production, or a hard-coded thing that should read from config. I check that staging and production stay independent and that nothing test-only leaks forward.
• Consistency with the codebase. One new error convention, one new data shape, one clever pattern nobody else uses. Each is a small tax every future reader pays, so I flag drift from how the code already works even when the new way is arguably nicer.
• What happens when it fails. Retries, timeouts, the empty state, the partial failure. Happy-path code is easy. I review for the unhappy path.

Review doesn't end at merge

A green review is not a shipped feature. My release discipline is that changes land in staging first, on the same providers and config shape as production, and I see them working there before they're promoted. Plenty of "it passed review" bugs are really "staging and production disagreed" bugs, and no amount of reading the diff catches those. The review and the release are one process, not two.