Using an AI agent as a reviewer, not an implementer

Using an AI agent as a reviewer, not an implementer, means running a separate session whose only job is to read finished or proposed work and report problems, with no ability to change the code it is reviewing. The reviewer reads the task, the diff and the check results, answers specific questions, and hands back findings. You decide what to do with them. This is different from asking the implementing agent whether it is done, which mostly produces a confident yes, and different from your own review, which human review of agent output covers. A reviewing agent is a second reader that does not tire and will search the whole repository for callers you forgot. It is also a reader that can be wrong with confidence. Used well, it narrows where your attention goes. Used badly, it becomes a second agent's opinion standing in for evidence.

Why keep review and implementation apart

An implementing session is a poor reviewer of its own work. It shares every assumption it made, it remembers what it intended rather than what it wrote, and it has a strong pull toward reporting success. Asking it to review itself mostly yields a restatement of its plan.

A separate review session starts without that history. It sees the diff as a diff, not as the end of a story. It can be given different instructions: be skeptical, look for problems, do not suggest improvements outside the task.

Keeping the reviewer read-only matters as much as keeping it separate. A reviewer that can edit will fix what it finds, and then you have a second implementation nobody reviewed, mixed into the first. Findings should come back as text. If a finding needs a fix, the fix becomes a task for an implementing session, with its own scope and check.

The separation also gives you a clean record: the implementation attempt, then the review findings, then your decision, each distinct and each attributable to one session.

Setting up a review session

Start the session read-only. In Claude Code, plan mode keeps the agent from editing; in Codex CLI, the read-only sandbox does the same. Point it at the branch or commit range to review.

Give it the inputs in this order: the original task text with its completion criteria, then the diff, for example from git diff against the base branch, then the check output. Hold back the implementing agent's own summary at first. If the reviewer reads a claim that everything works before reading the code, it tends to look for confirmation.

Review sessions are also useful after work is closed. Reviewing a task marked done a week ago, when new work is about to depend on it, is a reasonable use of a read-only session and needs no edit permission at all.

If you use a different model or tool for review than for implementation, you get a somewhat different set of blind spots, which helps. Do not mistake it for independence: two models can share the same misreading of an ambiguous task, so the task text needs to be clear for both.

What to ask a reviewing agent

A request to review this produces a vague answer. Ask specific questions instead.

Does the diff satisfy each completion criterion? Answer per criterion, with the file and line that satisfies it.

Which changed files are outside the declared scope, and why might they have changed?

What else calls the functions that changed? Search the repository and list callers that the tests do not exercise.

Were any tests deleted, skipped or weakened, such as an assertion loosened or an expected value changed to match new output? Test tampering by agents is common enough to ask about every time.

Would the new tests fail if the change were reverted?

Which error paths, empty inputs or boundary values are not handled?

Ask for findings as a list, each with a file, a line, a one-sentence problem and a confidence level, and say explicitly that no findings is an acceptable answer. Without that permission, a reviewer will often produce minor issues to appear useful, and they bury the real ones.

Treat review output as input, not a verdict

A reviewing agent's findings are claims, just like the implementer's report. Check each one against the code before acting on it. Some will be wrong, some will be right but outside the task, and a few will matter. Discard the first group, record the second as follow-ups and turn the third into fix tasks.

Above all, a reviewer's approval is not evidence that the work is correct. Testing on BRAIN FLUID's development builds shows why agent assertions are weak evidence on their own: on one route, a completion report with a failed check was refused, but a later report asserting a pass, against the same still-broken app, was accepted [D1]. A reviewer saying the change looks fine is the same kind of assertion. What counts is a check that ran independently and your own reading of the diff. Self-reported versus independent checks goes deeper on this.

The acceptance decision stays with a person. A reviewing agent can make that decision quicker and better informed, and human sign-off remains the step that closes the task.

QUESTIONS

Can an AI agent review code written by another AI agent?

Yes, and it is often useful, as long as the reviewer runs in a separate read-only session and its findings are checked rather than trusted. Different agents catch different things. But agreement between two agents is not independent evidence; they can share a misreading of the task. Use the reviewer to direct your attention, and keep the acceptance decision with a person.

Should a reviewing AI agent fix the problems it finds?

Not in the same session. A reviewer that edits produces a second, unreviewed change mixed into the first. Have it report findings as text, decide which ones matter, and turn each fix into a task for an implementing session with its own scope and check. Then review that fix like any other change.

What should I give an AI agent to review a pull request?

The original task with its completion criteria, the diff against the base branch and the output of the checks. Hold back the implementer's summary until the reviewer has formed its own view. Ask specific questions about criteria, scope, callers, weakened tests and edge cases, and ask for findings with a file, a line and a confidence level.

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.
• Self-reported vs independently run checks for AI agent work Self-reported vs independently run checks for AI agent work: why an agent's own "tests pass" is weaker than a check the system runs itself.
• When an AI agent edits the tests to make them pass When an AI agent edits the tests to make them pass: the signs, why it happens, and how to keep test files out of an implementation task's scope.
• Deciding which AI agent tasks need human sign-off Deciding which AI agent tasks need human sign-off: a risk-based policy, who signs off what, and why DONE is not the same as released.