How do I make code review useful instead of a style debate?
A useful review answers two questions: can this change break something, and would we notice if it did. Everything else is secondary.
How to do it
The author reviews the diff first
Before opening the PR, paste the diff into 'Code review'. Keep only bugs, security issues, and performance problems, ordered by severity, each with the condition that triggers it and a concrete fix. Fixing those before asking a colleague saves a round trip. Leave style to the linter so it does not consume review attention.
Add the tests that prove the change is correct
Give the implementation and current tests to 'Find the gaps in your tests'. List the uncovered branches, add the top five cases by production impact, and remove duplicates and tests that assert internals. The reviewer then sees which failing scenario each test covers, which makes the discussion concrete.
The reviewer looks at impact before code
Give the diff, dependency map, and traffic volume to 'Map the Blast Radius of a Change'. List affected callers, data, and scheduled jobs, rank the top three by people affected and recovery difficulty, and set rollback thresholds. For a high-impact change, the review should focus on the rollback plan and rollout order, not variable names.
Follow the failure paths
Give the error-handling parts of the diff to 'Review error handling'. Look for swallowed exceptions, error messages that cannot be traced, unsafe duplicate writes, and places that should fail but keep running. Tests rarely cover these; someone has to read the code.
Walk the concurrent parts separately
If the change touches shared state, give the relevant code to 'Concurrency and race condition review'. Assume two requests arrive in the same millisecond; list shared mutable state, the gap between check and use, the load at which it breaks, and the cheapest fix with its cost. If there is no shared state, skip this step rather than forcing it.
Prompts used
FAQ
Can AI code review replace a human reviewer?
No. AI usually catches pattern-level issues like injection, null dereferences, and N+1 queries, but it does not know your business constraints, past incidents, or release schedule. A colleague's value is judging whether this change should happen now and whether it conflicts with other work.
There are too many review comments. How do I prioritize?
Filter first by whether a comment can cause bad data or a production failure, then check whether the trigger is realistic. Send style comments to the linter instead of the discussion. For what remains, do the cheap fixes with clear payoff first.
Does a small change need this whole workflow?
Not all of it. A one-line config change may only need step 1 plus a confirmed rollback. Changes touching shared state, permissions, or money should not skip steps 4 and 5. Decide by the cost of getting it wrong, not by the number of lines.