🔍 The impartial reviewer

Imagine asking the same engineer who wrote the code to review it. They knows what you meant, so it reads what it imagined writing—not what it actually wrote. The same thing happens with an LLM: if it built the result in one session, it carries that session’s reasoning. A second agent, with fresh context, sees what the first one normalized or ignored. That’s the principle of the impartial reviewer.

↑ The builder accumulates context (and bias). The reviewer starts fresh — judging the product, not the effort.

An agent that built something internalized the reasoning that led to the result. When we ask it to review, it doesn't read the result with fresh eyes — it reads it with the eyes of someone who already knows the intent. Gaps remain invisible because they were filled in mentally during construction. A second agent doesn't have that context: it sees only the final artifact.

The reviewer doesn’t know—and doesn't need to know — how many iterations the builder made, which alternatives it considered, or what time pressure there was. It receives the artifact and applies objective criteria: Does the code compile? Do the tests pass? Does the plan have verifiable assumptions? This eliminates the effort effect: the tendency to judge a result as good because the process was difficult.

This is the principle of four eyes transposed to subagents. The builder has permission to write, create, modify. The reviewer has permission to read, analyze, report — never to edit directly. This separation of tools in the agent's frontmatter is what ensures the reviewer doesn't "fix things while reviewing" and cover up the problems they find.

O code-reviewer is the clearest case. The builder agent writes the diff; the code-reviewer receives the diff and applies criteria for correctness, security, and test coverage— without knowing how many versions the builder discarded. The output is a findings report, not a rewrite.

An implementation plan has a different problem than code: it is internally coherent by construction. The planner eliminated contradictions in the process — but may have introduced false assumptions or left questions unanswered. The plan-roaster is a reviewer who receives the plan and asks exactly the uncomfortable questions the author didn't want to ask themselves.

Research done by a subagent suffers from accelerated confirmation bias: the agent searches for sources and, as it gathers evidence, tends to reinforce the hypothesis that emerged early. A research reviewer doesn’t question whether the text is polished—it questions whether the claims are verifiable and whether there are contradictions in the sources that the builder may have downplayed.

Adding an impartial reviewer at the end of any subagent pipeline is a biggest-impact change for the lowest cost. A Haiku agent as a reviewer — which costs a fraction of what the builder does — can catch errors that the most expensive model wouldn't detect in itself. The asymmetry is dramatic: reviewing is cheaper than building, but it has insurance value for all the previous work.

Two files .md that implement the impartial reviewer pattern. Notice how both use tools: Read, Grep, Glob — with no write permission — and explicitly instructs the report, don't fix.

---
name: code-reviewer
description: Revisa o diff atual em busca de bugs,
  falhas de segurança e testes ausentes. Use após
  qualquer mudança de código — especialmente antes
  de commitar.
tools: Read, Grep, Glob     # apenas leitura
model: haiku               # custo baixo, revisão precisa
---

You are an impartial senior code reviewer.
You have no knowledge of how this code was written.

Steps:
1. Run git diff HEAD to see the current changes.
2. Read each changed file completely.
3. Check for: correctness bugs, security issues,
   missing tests, and unhandled edge cases.

Output: A numbered list of findings, severity
(critical/major/minor), and the exact line.

Rules:
- Do NOT edit, fix, or rewrite anything.
- Report only — the orchestrator decides what to fix.
- If nothing is wrong, say so explicitly.

---
name: plan-roaster
description: Questiona planos de implementação com
  ceticismo construtivo. Use SEMPRE antes de aprovar
  qualquer plano técnico ou de produto.
tools: Read                 # só lê o plano
model: sonnet              # precisa raciocinar sobre premissas
---

You are a skeptical senior engineer who has seen
many plans fail. You know nothing about how this
plan was created.

For each plan section, ask:
1. What hidden assumptions does this make?
2. What is the single most likely failure point?
3. Is there a missing dependency or external risk?
4. Is the rollback defined if this fails mid-way?

Output: A structured critique. For each issue,
state: what is assumed, why it might not hold,
and what question the author should answer.

Rules:
- Do NOT rewrite or "improve" the plan.
- Be adversarial but constructive.
- Prioritize: what will actually fail first?

Three prompts to use the impartial reviewer pattern in your real work. The second is the most powerful: it explicitly asks for the perspective of a external engineer.

Use o code-reviewer para revisar o que acabei de fazer.
Não quero que ele edite nada — só um relatório de
achados com severidade (crítico / maior / menor).

Abra um subagente com contexto fresco e peça para ele
revisar criticamente este resultado como um engenheiro
externo que nunca viu o projeto. Ele deve apontar o
que parece errado, incompleto ou arriscado — sem levar
em conta o esforço que custou.

Use o plan-roaster neste plano. Quero as 3 premissas
mais perigosas que estão implícitas e a pergunta
que eu precisaria responder antes de aprovar cada fase.

This is how the pattern appears in the terminal: the builder finishes and returns a diff; then the code-reviewer comes in with zero context, reads the diff, and generates the report. Note that the orchestrator’s context stays small throughout the process.

↑ Illustrative terminal recreation. The builder ran in a separate context; the reviewer started fresh. The maestro used only 9% of the context.