How to Review Pull Requests with AI Coding Agents

Verdict

Use AI review as a second pass over a pinned diff. Require each finding to identify a reachable failure, the changed line that causes it, and evidence a human can check. Keep speculative concerns in a separate investigation list. An empty findings list is not approval, and an agent's confident comment is not a demonstrated defect.

This guide covers reviewing an existing change. For authoring, use the issue-to-PR workflow; for tool selection, start with the AI coding-agent guide. Product facts were checked October 2, 2026. The procedure below is editorial guidance, not a comparative test of review accuracy.

Choose a review surface and budget

Anthropic's managed Code Review is separately token-billed, with a vendor-reported average of $15–25 per review, not a fixed quote or included Pro benefit. Its check run concludes neutral, including failed runs: branch protection does not automatically turn findings into a merge block. Configure triggers and spend caps deliberately. A one-off @claude review does not subscribe a PR to later pushes; @claude review always does. Check organization eligibility in the linked documentation before setup.

For a closer two-tool decision, read Claude Code versus Codex. For terminal/provider controls, use the CLI shortlist.

1. Freeze the scope before asking for findings

Record the target branch, merge-base SHA, PR head SHA, intended behavior, changed files, test commands, and relevant architecture. Review the diff from the merge base to that head. A moving branch name is insufficient: new commits can invalidate line references and reproduction results.

Start with a change summary and a list of affected callers. If the repository is unfamiliar, first trace the relevant code paths. Read surrounding implementation and tests, not just added lines. Require the reviewer to distinguish a newly introduced defect from an existing problem exposed by the diff.

2. Prioritize failure paths that matter for this change

These are prompts for investigation, not automatic findings. Naming preferences and formatting belong in the project's existing lint/style process. For behavior-preserving work, apply the refactoring checks; for version changes, use the migration acceptance matrix.

3. Make findings falsifiable

A useful report contains severity, exact revision and location, triggering input/state, expected versus actual behavior, and supporting trace or command output. Label an unexecuted hypothesis as unverified. “This might have a race” does not explain whether callers can actually reach it.

Illustrative finding format, not an observed repository defect:

Location: <head SHA>, src/jobs/dispatch.ts:<changed line>
Condition: the same delivery ID is received twice after a timeout.
Expected: one durable charge.
Concern: the new retry branch bypasses the existing idempotency lookup.
Evidence required: caller trace + duplicate-delivery regression test.
Status: unverified until the path or reproduction is confirmed.

Ask for counterevidence before accepting a concern: an upstream guard, transaction boundary, unique constraint, or unreachable call path may invalidate it. Deduplicate comments that share one root cause. Save pre-existing defects separately so they do not masquerade as regressions introduced by this PR.

4. Execute checks with review permissions

Repository scripts, fixtures, and PR descriptions are untrusted inputs. Read commands before running them. Use an isolated checkout without production credentials; do not run a fork's workflow with privileged secrets merely to verify a finding. Permission prompts and read-only chat modes are different controls.

For a suspected regression, a focused test should fail for the expected reason on the reviewed head and pass on the appropriate baseline. If the old behavior was itself wrong, explain the changed contract instead of forcing that comparison. Use the unit-test guide for assertion quality and CI debugging guide when local evidence disagrees with the runner.

5. Triage before publishing comments

In a Hacker News discussion, zmmmmm reported that AI review found useful bugs but mixed them with speculative concerns, leading them to use it selectively. This is one person's report, not a measured accuracy result. It supports tracking reviewer burden alongside useful findings.

Have the human reviewer classify each item as confirmed, rejected with reason, or needing investigation. Record confirmed actionable findings divided by findings investigated, plus triage time. Neither a high finding count nor agreement between two models establishes quality; two reviewers can share the same wrong assumption.

Before merge, recheck the latest head, relevant tests, and outstanding findings. Keep the review's tested SHA in the final note. If code changed after verification, repeat the affected checks. The owner of the change remains responsible for approval and release.

When reviewing user-facing examples or API references, apply the technical documentation checks: cited symbols and commands must match the reviewed revision.

When using Cline for local inspection, review its surface-specific permissions and provider route before loading a pull-request branch; do not assume IDE approvals carry over to the CLI.

Qodo is a dedicated review-and-governance alternative. Compare its cross-repository context, rule controls, Git-provider feature gaps and review-credit costs if a separate review layer is the priority.

Sources & further reading

• Codex review scopes and findings
• Codex pricing and limits
• Claude pricing
• Claude Code managed Code Review
• Claude Code permissions
• Claude plan usage limits
• Aider chat modes
• Aider repository and license
• zmmmmm on AI review signal and noise