A second AI model can help review a patch by looking for a different failure mode than the model that wrote it. It can also miss the same bug, raise a false alarm, or sound confident about an incorrect concern. Treat its output as a list of hypotheses to verify, not as a merge approval.
Give the reviewer the change and its contract
Start with a clean diff and the requirement the patch is meant to satisfy. Include relevant interfaces, tests, and constraints, but avoid sending secrets or unrelated source. Ask for concrete defects with file and line references, a failure scenario, and a reason the existing tests may not catch it.
Use a reviewer that did not write the patch when practical. Separate authorship can reduce shared assumptions, but two different model names do not guarantee independent reasoning if they share training data, prompts, or the same incomplete context.
A prompt to adapt
Review this diff against the stated requirement. Report only actionable correctness, security, data loss, or compatibility risks. For each finding, identify the affected line, describe a concrete input or state that causes it, and explain how to verify it. Do not rewrite the patch or approve it.Verify every finding against the repository
Reproduce the proposed failure with a test or a small example. Check whether the reviewer understood the surrounding code and whether the concern is already handled elsewhere. Reject findings that rely on a behavior the application does not promise or an assumption the source disproves.
A reviewer that finds nothing has not proven the patch safe. It may not have seen the relevant file, may misunderstand the requirement, or may share the author’s blind spot. Read the diff yourself and run the checks that matter.
Control extra cost and sensitive context
A second review uses additional model time and may send code to another provider. Check that the repository is allowed to be processed by that service and that the model receives only the context needed to assess the change. Avoid asking for a full codebase review when the question is about a small function.
Reserve a second model for changes where an independent perspective is useful, such as authentication, data migrations, concurrency, or a security boundary. For a formatting change, a normal diff review and test may be enough.
- Review the change yourself before requesting another opinion.
- Give the second model the requirement and focused diff.
- Ask for concrete, testable findings instead of a generic score.
- Reproduce each valid issue and discard unsupported claims.
- Make the merge decision using tests and human ownership.
Keep the review trail clear
Record which model reviewed the change, what context it received, and which findings you accepted or rejected. This helps a team understand whether the second review improved defect detection or only added noise. Do not describe a patch as independently verified solely because another model read it.
For a reusable pull request routine, see the code review CLI workflow and checklist. They cover the rest of the human review process around a model generated patch.