Run a code review with Claude before your senior engineer sees it

Code review is where senior engineers burn hours, and most of those hours go to the same four things: bugs, edge cases, unclear naming, and missing tests. Claude handles the first three well enough that my team's review rounds got shorter — but only because I stopped treating it like a magic checker and gave it a running order.

Pass one is correctness with context. Paste the diff and the task description together — the diff alone invites style notes, but 'here's the requirement and here's the change' lets it catch the mismatch between what was asked and what was built. That mismatch is the most expensive bug class in review, and it's the one humans miss most when they're skimming.

Pass two is adversarial and it's where Claude earns its keep: 'list every input this code will receive in production, including the ugly ones.' Empty strings, unicode names, negative quantities, concurrent requests. On my last review it caught a crash on timezone-boundary dates that three humans had skimmed past, because asking for 'the ugly inputs' is a direct instruction nobody thinks to give at 6pm.

Pass three is the human layer: naming, comment honesty, and dead code. Ask it specifically — 'flag any name that lies about what the thing does' — because generic review prompts produce generic praise. The one question that catches the most, in my experience: 'what would the author's most senior critic say this code forgot?' It reads like a parlor trick. It finds real gaps.

What Claude won't replace is the design argument — whether this approach should exist at all. That stays human. The checklist just clears the mechanical 70% so the review conversation starts at the interesting part, which is exactly where you want your senior engineer's expensive attention.