🔍 O revisor imparcial

Imagine pedir para o mesmo engenheiro que escreveu o código revisá-lo. Ele sabe o que quis dizer, então lê o que imaginou escrever — não o que escreveu de fato. O mesmo acontece com um LLM: se ele construiu o resultado numa sessão, carrega o raciocínio daquela sessão. Um segundo agente, com contexto fresco, enxerga o que o primeiro normalizou ou ignorou. Esse é o princípio do revisor imparcial.

↑ Builder acumula contexto (e viés). Reviewer começa limpo — julga o produto, não o esforço.

Um agente que construiu algo internalizou o raciocínio que levou ao resultado. Quando pedimos para ele revisar, ele não lê o resultado com olhos novos — ele lê com os olhos de quem já sabe a intenção. Gaps ficam invisíveis porque foram preenchidos mentalmente durante a construção. Um segundo agente não tem esse contexto: ele vê apenas o artefato final.

O revisor não sabe — e não precisa saber — quantas iterações o builder fez, quais alternativas considerou, ou que pressão de tempo existia. Ele recebe o artefato e aplica critérios objetivos: o código compila? os testes passam? o plano tem premissas verificáveis? Isso elimina o efeito esforço: a tendência de julgar um resultado como bom porque o processo foi trabalhoso.

Este é o princípio dos quatro olhos transposto para subagentes. O builder tem permissão de escrever, criar, modificar. O revisor tem permissão de ler, analisar, reportar — nunca de editar diretamente. Essa separação de ferramentas no frontmatter do agente é o que garante que o revisor não "consertar enquanto revisa" e encobrir os problemas encontrados.

O code-reviewer é o caso mais claro. O agente builder escreve o diff; o code-reviewer recebe o diff e aplica critérios de correção, segurança e cobertura de testes — sem saber quantas versões o builder descartou. A saída é um relatório de achados, não uma reescrita.

Um plano de implementação tem um problema diferente do código: ele é internamente coerente por construção. Quem planejou eliminou as contradições no processo — mas pode ter inserido premissas falsas ou deixado perguntas sem resposta. O plan-roaster é um revisor que recebe o plano e faz exatamente as perguntas incômodas que o autor não quis se fazer.

Pesquisa feita por subagente sofre de viés de confirmação acelerado: o agente busca fontes e, à medida que acumula evidências, tende a reforçar a hipótese que emergiu cedo. Um revisor de pesquisa não questiona se o texto é bonito — questiona se as afirmações são verificáveis e se existem contradições nas fontes que o builder pode ter minimizado.

Adicionar um revisor imparcial ao final de qualquer pipeline de subagentes é a mudança de maior impacto por menor custo. Um agente Haiku como revisor — que custa fração do builder — pode detectar erros que o modelo mais caro não detectaria em si mesmo. A assimetria é brutal: revisar é mais barato que construir, mas tem valor de seguro sobre todo o trabalho anterior.

Dois arquivos .md que implementam o padrão do revisor imparcial. Note como ambos usam tools: Read, Grep, Glob — sem permissão de escrita — e instruem explicitamente a reportar, não consertar.

---
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?

Três prompts para acionar o padrão do revisor imparcial no seu trabalho real. O segundo é o mais poderoso: pede explicitamente a perspectiva de um engenheiro externo.

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.

É assim que o padrão aparece no terminal: o builder termina e devolve um diff; em seguida o code-reviewer entra com contexto zero, lê o diff e emite o relatório. Note que o contexto do maestro permanece baixo durante todo o processo.

↑ Recriação ilustrativa do terminal. O builder rodou em contexto separado; o revisor iniciou fresco. Maestro usou apenas 9% do contexto.