A Checklist for AI-Assisted Code Review

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

1. Correctness: boundaries, nulls, concurrency, timing;
2. Security: injection, privilege, secrets, dependencies;
3. Performance: N+1 queries, needless loops, large copies;
4. Testability: side effects, can it be unit-tested;
5. 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.

Real-world cases: three problems an AI review let through

1. Boundary checks "optimised away": the model dropped an empty-array guard and the reviewer read only the diff. Actively ask about empty, extreme and concurrent inputs.
2. Swallowed errors: the generated try/catch logs and never rethrows, hiding failures. Agree that exceptions are handled or propagated — never an empty catch.
3. Depending on a non-existent API: the model invents a plausible-looking library function that only fails at build or runtime. Run a build and critical-path tests before review rather than judging plausibility.

FAQ

Should AI-generated code be attributed? Follow team convention; the essential point is that review responsibility is human — whoever merges owns it. What should review focus on? Behaviour, security boundaries and test coverage, not style and naming that tooling can settle. Can it merge fully automatically? For low-risk changes with complete tests yes, but authentication, payments and data deletion always need a human. How do I reduce hallucination? Constrain context, require it to reference existing implementations, and prefer editing existing code over inventing new.

Review behaviour, not style

AI-generated code is usually tidy and reasonably named, so review time belongs on the places that actually break.

1. 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.
2. Honest error handling: look for exceptions that are logged but not handled, swallowed errors and unconditional fallback returns — these surface failures later and harder.
3. 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.
4. 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?
5. 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.