A clean-looking diff is not proof that a change is correct. AI-generated code can be readable, well-commented, and still solve the wrong problem.
Review it with the same responsibility you would apply to any other contribution. The authoring tool may change how quickly code appears; it does not remove the need to understand what will run.
Restate the intended behavior
Read the task before the diff. Write a short description of what should change and what should remain unchanged.
This prevents the review from becoming a discussion of style while a missing business rule goes unnoticed. If the requirement itself is unclear, resolve that before approving implementation.
Look for scope expansion
Check new dependencies, configuration changes, database edits, and unrelated cleanup. Ask why each is necessary.
An apparently small interface fix should not include a broad authentication rewrite without a separate explanation. Work that affects API and backend behavior deserves explicit review of its boundaries.
Trace one real journey
Follow a normal input through the changed code to its visible result. Then trace an invalid input or a failed dependency.
Look for missing error handling, duplicated writes, and assumptions about data that may not hold. Keep the review tied to the application rather than searching for abstract perfection.
Inspect the tests as code
Read assertions, fixtures, and mocks. A test that reproduces the implementation's mistaken assumption can pass while the product remains wrong.
Use the Claude Code verification guidance as background, then require evidence appropriate to your own project. Confirm which tests actually ran and which were skipped.
Leave an actionable review
Explain the condition that fails, why it matters, and what evidence would resolve it. Avoid vague comments such as “make this safer” when you can describe the missing check.
