Independent Review: a separate critic agent checks a coding agent’s work and sends back issues to fix

STEP 0 (optional): a short instruction “verify the result through the real
        interface” in the agent’s system prompt (L0)
STEP 1: The agent does the task → result + list of changes (diff)
STEP 2: A new critic in a clean context gets ONLY the task + the changes
        → runs checks itself in the same environment → a list of defects found,
        with reproducible cases (it may not edit the result)
STEP 3: The findings go back to the agent → it fixes them → the result is accepted
STEP 4 (for hard tasks): one more round, or several critics in parallel

Steps 2–3 are separate requests or a subagent. The critic doesn’t live in the same conversation as the worker.

Task: You sell on Amazon. Using Claude Code, you ask for a script that takes the weekly settlement report (Excel) and calculates the real margin for every SKU. The calculation includes referral fees, FBA fulfillment, returns, penalties, and a 6% tax set-aside. The agent writes the script, runs it on one report, and says “done.” You worry the script quietly lies on returns, negative amounts, or SKUs with no sales.

Prompt:

You are an independent critic. You did NOT write this code and did not see how it was built.
Your only job is to find where it fails to match the task.

<Task>
The script margin.py reads the weekly Amazon settlement report (Excel) and
calculates the margin for each SKU: revenue − referral fees − FBA fees − returns
− penalties − 6% tax set-aside − cost of goods (from cost.csv). Output: report.csv.
Negative values (returns, penalties) must be subtracted correctly.
SKUs with no sales are left out of the report.
</Task>

<Changes>
Repository changes: git diff HEAD~1
</Changes>

Rules:
1. Don’t trust the author’s claims. Verify for yourself by running the code.
2. Come up with and run at least 5 checks of your own. Focus on edge cases:
   a return larger than the sale, a SKU with no cost of goods, an empty sheet,
   fractional cents, duplicate SKUs.
3. For each problem you find, give: what broke → the command or input
   that reproduces it → what the task says should have happened.
4. Do NOT edit files. Only read and run.
5. If you find no problems, say so and list what you checked.

Result: The critic returns a structured list of problems. Each one comes with a reproducible case: input, command, expected and actual result. Or it honestly writes “found nothing” and lists what it checked. You pass that list to the agent, which fixes the code and reruns the checks.

Weakness. An agent that wrote the code checks it through the lens of its own assumptions. It tests what it already thought about and skips what it didn’t. Asking it to “check again” before submitting yields only a limited gain: the agent either keeps working and breaks what already worked, or checks the wrong thing. In the study, there were cases where, after “polishing,” the agent left test junk in the working repository and the task failed.

Strength. A model is good at finding bugs in someone else’s work, especially if it can run the code. A fresh context rules out tunnel vision. The model doesn’t defend its own decisions, because it doesn’t know how they were made.

How the method exploits this. The critic gets a blank slate and only the requirements, so it checks compliance with the task, not the author’s reasoning. Read-only permissions force it to find defects instead of silently rewriting things. The agent receives concrete failing cases and fixes them. That’s cheaper and more reliable than asking it to “think some more.”

Control levers: - The critic’s context. Task + diff is the default. The agent’s full work history (trajectory) doesn’t improve results on average, and the critic costs 29–43% more. - Number of reviews. Two rounds or two critics add +2–3 pp of accuracy; four add up to +3.5. Scale up for hard tasks. - Several critics in parallel. Four critics nearly match four sequential rounds but are about a fifth cheaper. - The critic model. In the study, the critic was one cheap model for all seven agents. - Visual checks. For websites and interfaces, add a mandatory “open it, click it, look at it” step: it strengthens the effect. - Leaning on the agent’s claims. The researchers compared a critic that works only from the task (Task-first) with one that also checks the agent’s assumptions (Claim-guided). The first is simpler, and it’s the one to start with.

Part 1. Instruction for the main agent (in the system prompt, CLAUDE.md, or AGENTS.md). Short, following the L0 principle:

Before you consider the work done:
1. Run the result through the interface a human will use it with
   ({how_it_runs}).
2. Look at the actual output.
3. If you see defects, fix them and check again.
Don’t delete or modify files unrelated to the task in order to “prepare”
the test environment.

Part 2. The independent critic’s prompt (subagent or separate session):

You are an independent critic. You did NOT produce this work and don’t know how it was done.
Your job is to find where the result fails to match the task.

<Task>
{full_task_text_and_requirements}
</Task>

<Changes>
{diff_or_list_of_changed_files}
</Changes>

Rules:
1. Don’t believe the author’s claims that everything works. Verify for yourself by running
   {what_to_run}.
2. Come up with and run at least {number} checks of your own. Pay special attention
   to edge cases: {typical_edge_cases}.
3. For each problem: what broke → how to reproduce it (command or input)
   → what the task says should have happened.
4. Don’t modify files. You only read and run.
5. If there are no problems, say so and list what you checked.

Part 3. Passing the findings to the agent:

An independent critic reviewed your work and found the following:

{critic_findings_list}

Reproduce each problem, fix it, and verify that the fix works.
Don’t break anything that already worked.

Placeholders: - {full_task_text_and_requirements}: the original spec, unabridged. - {diff_or_list_of_changed_files}: what the agent changed, without its reasoning history. - {what_to_run}: the run command, the tests, the local server address. - {typical_edge_cases}: empty data, duplicates, negative values, unusual date and currency formats. - {number}: 5 for a small task, more for a complex one.

🚀 Quick start: paste this into a chat:

Here is a template for independently reviewing an agent’s work (agent instruction + critic prompt
+ passing back the findings). Adapt it to my task: [your task]. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what exactly the result does, how to run it, and what its typical weak spots are. It needs those answers so the critic gets a precise task and concrete edge cases instead of a vague “check the code.”

⚠️ The effect depends on the model. A short “verify” instruction in the system prompt gives a modest average gain. On some models it helps noticeably; on others it hurts. In the study, an agent given this instruction deleted the repository “to prepare the test” and failed the task.

⚠️ Forced re-checking before submission is expensive and unpredictable. If you forbid the agent from finishing, it burns noticeably more resources. It can also leave test junk in the final result. We don’t recommend making this the default.

⚠️ The critic finds a problem, but the agent may not fix it. In one case, the critic correctly pointed out that an asynchronous cleanup wasn’t finishing, but the agent hit its time limit and didn’t complete the fix.

⚠️ Putting the agent’s full work history into the critic’s context hurts. It’s not just more expensive, it’s also not consistently better. For some models, results even got worse.

⚠️ Only coding tasks and visual artifacts were tested (games, 3D configurators, dashboards). The method wasn’t tested on writing, analysis, or other tasks without a runnable result.

⚠️ The critic needs access to the environment. The method’s power is that the critic runs its own checks. If you give it only the code text with no way to run it, results aren’t guaranteed.

The researchers compared 17 ways of verifying an agent across four lifecycle stages: an initial instruction, reminders during the work, “gates” at the exit, and an independent critic. Everything was tested on seven current coding models using tasks from Terminal-Bench and SWE-bench Verified (three runs per task). Separately, they built a set of 18 visual tasks (playable games, 3D configurators, dashboards) and showed pairs of results to company employees blind.

First, they measured how agents actually behave. After code edits, a verification command was run after only 6–13% of edits. Hence the logic: the agent needs either a reminder or an outside view. The results were only partly as expected. Initial instructions and reminders gave a modest and uneven gain: +3–5 pp on average, but +12 on some models and negative on others. Forced polishing before submission gave up to +6 pp, but at 1.5–1.8x the cost. The independent critic gave +6–9.5 pp on Terminal-Bench and +4–6.6 on SWE at 1.00–1.25x the cost, and beat forced polishing.

The biggest surprise: the agent’s full work history didn’t help the critic and cost 29–43% more. The “diff plus spec” critic came out ahead. And the critic was the same relatively inexpensive model for all seven agents. Scaling worked too: four critics in parallel gave nearly the same result as four sequential rounds, but 19% cheaper.

🔧 Technique: require a reproducible case from the critic → the agent fixes more precisely

In the study’s good examples, the critic didn’t write “there might be a problem here”; it brought an executable case that fails. The agent reproduced it, fixed it, and verified it. Lock this into the critic’s rules:

Any finding without a command or input that reproduces the
problem is considered invalid. Don’t write guesses.

Extrapolation (not tested in the study): the same principle for no-code automations, such as an n8n or Make workflow that generates emails to customers. A separate “critic” request gets only the spec and the final text (not how it was written) and looks for mismatches with the requirements: tone, mandatory points, numbers.

You are reviewing an email written by someone else. You didn’t see
how it was created. Here is the spec: {spec}. Here is the email: {email}.
Find every mismatch with the spec. For each one, give a quote from the email and
the spec item it violates. Don’t rewrite the email.

• Rethinking Verification in Agent Harnesses
• Authors: Zhengxin Zhang, Erkang Zhu, Yin Lin, Claire Cardie, Bolin Ding, Jingren Zhou
• Cornell University, Alibaba Group
• Benchmarks: Terminal-Bench 2.1 (Merrill et al., 2026), SWE-bench Verified (Jimenez et al., 2023)
• Related work: Reflexion (Shinn et al., 2023), Self-Refine (Madaan et al., 2023)