Give the right context first
Dumping only the diff invites wrong calls. Share the change plus related files plus project conventions, and say what the code should do and why it changed, only then are conclusions trustworthy.
Constrain the output format
Require a fixed shape: severity + file:line + issue + suggestion. Otherwise the model writes a wall of correct-sounding filler that buries the real problems.
Review dimensions
- Correctness: boundaries, nulls, concurrency, timing;
- Security: injection, privilege, secrets, dependencies;
- Performance: N+1 queries, needless loops, large copies;
- Testability: side effects, can it be unit-tested;
- Consistency: matches the repo's existing style and conventions.
Separate facts from guesses
Ask the model to tag "definitely a problem" vs "worth a look". Treat guesses as leads to verify, not conclusions to apply.
Two pitfalls
- Leaking private code: sending internal code to an external cloud model is a compliance risk; use a local model or an approved setup for sensitive repos;
- Overconfidence: models invent APIs or line numbers that don't exist, verify every citation yourself.
Review behaviour, not style
AI-generated code is usually tidy and reasonably named, so review time belongs on the places that actually break.
- Boundaries and error paths: empty collections, empty strings, extreme values and concurrent duplicate calls. The most common defect is a perfect happy path with no error path.
- Honest error handling: look for exceptions that are logged but not handled, swallowed errors and unconditional fallback returns, these surface failures later and harder.
- Secure defaults: check whether authorisation was skipped, whether input is concatenated into queries or commands, and whether logs carry sensitive fields. Generated code does not know your permission model.
- Dependencies and side effects: is a new dependency necessary, and is there a lighter alternative? Are side effects (file writes, requests) placed where you expect?
- Testability: is the logic welded to hard-coded time, randomness or global state, making stable tests impossible?
Folding it into process
Putting these items in a review template beats relying on memory, and add integration coverage in modules where generated code dominates. The reviewer owns the merged result regardless of where the code came from.
Record and reuse review findings
Turn recurring review findings into a case library and reference it in later prompts. That nudges generated output toward your conventions and lets newcomers learn the rules from examples. Savings only materialise once conclusions are written down.