How to Set Up an Independent Reviewer Subagent for Coding Agent Work

When a coding agent changes software, a separate reviewer can inspect its patch, the set of code changes, for defects and regressions. A subagent is an agent assigned a narrower task by another agent or a person. The reviewer works independently when it examines the change using its own context and limited authority, rather than relying on the coding agent’s account of its work.

Give the reviewer a specific change to inspect, permission to read files but not edit them, and instructions to support its findings with evidence. Let a person or existing repository controls decide whether the change is ready to merge. The reviewer adds another check, but cannot guarantee that the code is correct.

Separate the reviewer from the coding agent

A second agent does not automatically make a review independent. Start the reviewer in a fresh session and give it the original task, the criteria for accepting the work, project instructions, and the exact change to inspect. The reviewer should read the code and diff, a view of the changes, directly. The coding agent’s summary can add context, but cannot replace that inspection.

Limit what the reviewer is allowed to do. It should report concerns but not edit files, commit changes, or approve its own proposed fixes. If you let it run tests or other commands, specify which commands it may run and use a temporary environment with limited access. Reading repository files is safer than running code from those files.

A different model or provider can offer another perspective, but that alone does not make the review independent. Independence comes from the reviewer’s context, permissions, evidence, and role in the decision.

Give the reviewer a fixed change to inspect

Set the exact review target before starting the reviewer. For a Git change, identify the base revision and head revision: the points in the project’s history where the patch starts and ends. Decide whether the review includes untracked files, generated files, and changes outside the main source code. If the reviewer sees only part of the change, it cannot assess the rest.

Give the reviewer the original task and acceptance criteria, then explain the conditions the change must meet. Include the diff and behavior that must stay the same, such as the rules for how other code uses a public API or a security requirement. The Codex review workflow example shows one way to fetch a pull request’s base and head revisions and construct a diff for review. That example is specific to its GitHub Actions setup; local agent frameworks will have their own ways to identify and pass a change.

A fixed target also clarifies follow-up reviews. After the coding agent addresses a finding, send the reviewer the new diff so it can inspect the updated code instead of relying on a description.

Limit the reviewer’s tools and instructions

If your agent framework has a custom-agent feature, use it to set the reviewer’s role and allowed tools. For example, GitHub’s custom-agent documentation describes prompts and tools limited to a specific role, including a read-only researcher configuration. In your framework, let the reviewer read files and diffs, but omit tools that edit files or write to version control.

Tell the reviewer what makes a finding useful. This prompt is a starting point, not a configuration file for a specific vendor:

Review the specified change independently against the original task and
applicable repository guidance. Inspect the diff and relevant surrounding
code. Do not modify files or claim to have applied a fix.

Report only discrete, actionable issues supported by the code or a
reproducible check. For each finding, state the affected location, the
conditions that trigger the problem, its impact, and the supporting
evidence. If you find no issue, say so without claiming the change is
proven correct. Identify important checks you could not run.

If the reviewer needs to run a check, specify the commands it may run and the environment where it may run them. Read-only tools do not make it safe to run arbitrary code: tests and scripts can still change files or access resources available to that environment.

Require findings that a person can verify

Ask the reviewer to report each issue separately and link it to the code. The Codex review rubric calls for findings that describe a clear scenario, give a concise location, and do not repeat another finding.

A useful finding names the relevant file and a short line range, explains which inputs or conditions trigger the issue, and says what fails or becomes less safe. It also gives evidence, such as the code involved or the result of an approved check. If the reviewer could not verify the concern, it should say what remains uncertain instead of calling a guess a confirmed defect.

You can ask the agent to return findings as prose or in a consistent format:

Structured output makes findings easier to handle, but it does not make them more accurate. The Codex workflow example demonstrates structured review output for paths, line numbers, titles, and descriptions.

Test the reviewer against real examples

Before relying on a reviewer, test how it handles different changes. The OpenAI guidance on custom code review rules recommends testing a change that should trigger a rule, a safe example that should not trigger it, and an unrelated change. Use the same tests for your reviewer’s prompt and project instructions. Check that it raises the intended concern, does not flag the safe example, and does not invent an issue in unrelated code.

Keep project instructions concise and specific. Rules about compatibility or security can help the reviewer catch requirements that are not clear from the diff alone. If the proposed change also edits the reviewer’s instructions, inspect those edits separately. GitHub documents that Copilot code review reads repository instructions and related guidance from a pull request’s head branch. So a change to those instructions is not trustworthy just because the reviewer read them.

Treat test results and code findings as separate evidence. Ask the reviewer to name each command it ran and say whether it passed. Passing tests do not show that the reviewer checked every relevant behavior. A concern about the code is not verified just because the reviewer describes it confidently. Keep existing tests, branch protections, and required approvals in place; OpenAI’s guidance likewise presents review as an additional layer rather than a replacement for those controls.

Keep the final decision with a person or repository control

Use the reviewer’s feedback to guide the next steps, then inspect the revised diff and rerun relevant checks. A person or a controlled coding step should decide whether to address each finding. Do not let the coding agent apply every suggestion automatically. A finding can be wrong, incomplete, or irrelevant to the project’s requirements.

Benchmark results reinforce the need for that judgment. A March 2026 preprint, SWE-PRBench, reports that eight evaluated models detected 15–31% of human-flagged issues in a diff-only setting. That result applies to the paper’s particular dataset and evaluation method; it is not a general detection rate for every reviewer setup. A July 2026 preprint, SWE-Review, reports improved task resolution in selected generate-review-revise experiments. Those results support testing an iterative review loop, but they do not show that every individual finding is correct or safe to apply automatically.

Track useful findings and false alarms in your own code. If the reviewer often misses a known defect, check whether it received the relevant file, task criteria, and context. If it flags safe examples, narrow its instructions or clarify the project rule. These checks help you improve the setup, but a review with no findings does not prove that a patch has no defects.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com