Code & PRs · Practical AI guide

How to review a pull request with AI: evidence over approval

Ask for concrete failure cases and evidence.

By AgentBoards · Published October 15, 2026 · Editorial guidance with an illustrative example; no product benchmark or guaranteed outcome.

Give the reviewer the intended base branch, the purpose of the change and the relevant project instructions. Ask it to trace affected callers and failure paths, then report issues it can explain with evidence. Treat the output as review assistance. The person responsible for merging still needs to assess the findings and any behavior the tool could not check.

Start with these three steps

Read the requirements and full diff.
Trace affected callers, permissions, and failure paths.
Prioritize actionable findings with reproduction steps.

Illustrative example

Make the request concrete

A PR adds an endpoint for downloading a team report. The interface hides the download button from non-members, but the change also needs to enforce access on the server.

Review this report-download PR against main. Trace how the handler identifies the signed-in user and verifies membership of the requested team. Check direct requests as well as the UI. For a supported issue, provide the file and line, a concrete request scenario, the expected denial and a suggested verification. Do not edit or merge.

What to check afterward

The review follows the actual handler and permission helper rather than assuming a hidden button enforces authorization.
Any finding identifies a reproducible access path and distinguishes observed behavior from a hypothesis.
A human checks the fix with member, non-member and signed-out requests, plus the existing report workflow.

A prompt you can adapt

Replace the [brackets] with your task and use only information appropriate for your tool.

Review this PR against [base] for correctness, regressions, authorization, and missing failure handling. Read surrounding code. For each finding include severity, file and line, a concrete failure scenario, and evidence. Separate confirmed issues from questions. Do not invent findings or edit files.

Watch for this failure

Treating an AI approval as proof that a change is safe.

An empty finding list does not prove the PR is safe. If surrounding code, test data or the target environment is unavailable, record that gap. Dismiss invented or unsupported findings, and investigate concrete risks before merging.

You’re done when: Each finding points to an observable risk; a human reviews merge readiness.