AI can review AI-generated code, but the review is useful only when it has an independent job. Asking the same model to “check your work” with the same context often produces a polished restatement of the original assumptions. Give the reviewer different evidence, explicit failure criteria and permission to reject unsupported findings.
Using a different model can help, but model diversity is weaker than process diversity. A reviewer that inspects repository contracts, tests concrete failure modes and verifies each claim can add value even when it uses the same model family as the coding agent.
Why a second model call can repeat the first mistake
Imagine a coding agent receives this request:
Add an endpoint that lets an authenticated user delete an invitation.
It writes a route that checks for a session and deletes the invitation by ID. The product rule, never included in the prompt, says only workspace administrators can delete invitations from their own workspace.
Now ask the same model to review the diff. It may praise the authentication check, error handling and test coverage. Nothing in its evidence says workspace ownership matters. A second pass cannot verify a rule it was never given and never discovered.
This failure is not about the model being lazy. The generation and review share the same incomplete specification.
Independence has three parts
A useful review differs from generation in its evidence, objective and failure criteria.
1. Different evidence
The coding agent may have seen the issue, selected files and its own conversation. The reviewer should inspect additional sources:
- callers and related code outside the diff
- types, schemas and database constraints
- neighboring protected routes
- repository-specific review rules
- installed dependency versions
- product acceptance criteria
- previous bugs and tests
Repository context matters because both real bugs and false positives often depend on code the diff does not contain. We cover those cases in why diff-only code review misses bugs.
2. A different objective
The coding agent tries to complete a task. Completion rewards a coherent implementation and a working happy path.
The reviewer should try to disprove specific claims:
- this actor is allowed to perform the action
- this value survives every affected layer
- this side effect cannot happen twice
- this API exists in the installed version
- this test fails when the protected behavior breaks
“Find problems” is too broad. It encourages a model to produce something, including style commentary and speculative edge cases. A verification objective can end with “the claim is supported; do not comment.”
3. Independent failure criteria
The tests and review checks should come from requirements, invariants and threats rather than from the implementation’s current branches.
For example:
- requirement: members cannot view another workspace’s invoices
- invariant: one webhook event creates at most one charge
- threat: a user-controlled URL must not reach internal services
- compatibility rule: old clients can omit the new field
These criteria give the reviewer a position from which to disagree with the generated code.
Is using a different model enough?
Different models have different training, reasoning habits and blind spots. Running one model for generation and another for review can reduce exact repetition. It does not guarantee independence.
Two models can still:
- receive the same incomplete prompt
- inspect only the same diff
- trust the same generated tests
- miss the same undocumented product rule
- hallucinate the same plausible library API
- optimize for producing comments rather than verifying claims
Model diversity is useful after the review process has distinct evidence and goals. Before that, it is mostly another opinion on the same packet of information.
What a useful AI review pipeline looks like
A practical pipeline has separate stages.
Gather context
Collect the pull request, relevant surrounding code, definitions, callers, tests and repository rules. Keep the context focused enough that the reviewer can identify which evidence supports each claim.
Generate candidate findings
Ask for correctness, security and project-rule violations with a concrete location and failure scenario. Avoid asking for a general list of improvements unless the team wants style and maintainability commentary.
Verify each candidate
For every candidate finding, run a second check that tries to reject it:
- Does unseen code already handle the condition?
- Is the claimed behavior possible with the actual types and callers?
- Does the finding name a user-visible or operational failure?
- Can the relevant line be identified?
- Is the severity supported?
- Does the repository explicitly allow this pattern?
Unsupported findings should disappear before they reach the pull request. This verification step is one of the main ways to reduce AI code review false positives.
Use deterministic tools where they are stronger
Run compilers, linters, static analysis, dependency scanning, secret scanning and tests for rules they can enforce reliably. Do not spend model attention guessing whether a type error exists when the compiler can answer.
AI review is more useful for context-shaped questions: mismatched intent, missing error paths, repository conventions and interactions across files. The comparison in AI code review versus static analysis explains where each fits.
Keep a human owner
The author or approving reviewer must understand the implementation and decide whether the evidence is enough. The AI reviewer can produce findings. It cannot accept responsibility for the merge.
How to review code generated by Copilot, Cursor or Claude Code
The product used to generate the code does not change the core process. The reviewer needs a clean handoff.
Ask the author to provide:
- intended behavior in one sentence
- key constraints and permissions
- uncertain parts of the implementation
- commands and environments used for verification
- relevant agent instructions or repository rules
- any external documentation the implementation relies on
Do not make the review depend on reading the full agent transcript. Transcripts contain useful clues, but they mix abandoned approaches, speculative claims and context that never reached the final code.
Then run the normal review against the repository. The article on reviewing a vibe-coded pull request gives a complete sequence for large or unfamiliar changes.
Can the same model generate and review code safely?
Yes, if the two stages are separated properly.
For generation:
- give the model the task, local conventions and implementation tools
- ask it to run tests and report uncertainty
- keep changes small enough to inspect
For review:
- start a separate context rather than continuing the implementation chat
- provide the final diff and repository evidence, not the model’s rationale
- add explicit review rules and failure criteria
- ask for evidence and concrete impact with every finding
- verify candidate findings before publishing them
- include deterministic tool results
The separation reduces self-justification. The review model sees the submitted artifact, not a conversation in which it has already defended every design choice.
When AI-on-AI review adds little
Skip or distrust the extra pass when:
- the review sees only a tiny fragment with no contracts or callers
- the prompt asks for a fixed number of issues
- generated tests are treated as proof without mutation or independent cases
- every suggestion is posted without verification
- style comments overwhelm correctness and security
- nobody on the team can explain the change
This process can create the appearance of scrutiny while adding another layer of plausible text. A quiet review that verifies two risky claims is more useful than twenty generic suggestions.
Measure whether the review helps
Track outcomes instead of comment volume:
- findings that led to a code change
- findings dismissed as wrong or irrelevant
- bugs found later that the reviewer should have caught
- repeated classes of misses
- time spent investigating comments
- acceptance by severity and repository
Use dismissal reasons to improve context, rules and thresholds. If a category never leads to action, stop publishing it. If the same authorization miss appears repeatedly, encode the rule and add a deterministic or test-based check where possible.
A checklist for independent AI code review
### Independent AI review
- [ ] The reviewer starts from the final change, not the generation transcript.
- [ ] It sees relevant callers, schemas, policies and repository rules beyond the diff.
- [ ] Review objectives name correctness, security and concrete project constraints.
- [ ] Failure criteria come from requirements, invariants and threats.
- [ ] Every finding includes evidence, location and practical impact.
- [ ] Candidate findings are checked for missing context before publication.
- [ ] Compilers, tests and scanners handle deterministic rules.
- [ ] Generated tests are challenged with independent cases or mutations.
- [ ] A person who understands the implementation owns the merge.Frequently asked questions
Can AI review its own code? Yes. Use a separate review context, different evidence and explicit failure criteria. A second request to “double-check” the same conversation is much weaker.
Should I use one model for coding and another for review? It can reduce shared blind spots, but it is optional. Improve process independence first: repository context, project rules, adversarial checks and verification of findings.
Does AI code review replace human review? No. It can perform a fast first pass and check recurring rules. Humans still own product intent, architectural trade-offs and the decision to accept risk.
Can AI reviewers catch bugs in code written by Copilot? Yes, especially bugs exposed by repository context, explicit rules and failure-path reasoning. They can also repeat Copilot’s assumptions, so require evidence and keep conventional tests and analysis in the workflow.
The model matters, but the review contract matters more. Give the reviewer a real way to disagree with the code, then suppress anything it cannot support.