🔍 El revisor imparcial

Imagina pedirle al mismo ingeniero que escribió el código que lo revise. Él sabe lo que quisiste decir, entonces lee lo que imaginó escribir, no lo que escribió realmente. Lo mismo ocurre con un LLM: si construyó el resultado en una sesión, carga el razonamiento de esa sesión. Un segundo agente, con contexto fresco, ve lo que el primero normalizó o ignoró. Ese es el principio del revisor imparcial.

↑ Builder acumula contexto (y sesgo). Reviewer empieza desde cero: evalúa el producto, no el esfuerzo.

Un agente que construyó algo internalizó el razonamiento que llevó al resultado. Cuando le pedimos que lo revise, no lee el resultado con ojos nuevos: lo lee con los ojos de quien ya conoce la intención. Las brechas quedan invisibles porque fueron completados mentalmente durante la construcción. Un segundo agente no tiene ese contexto: solo ve el artefacto final.

El revisor no sabe — y no necesita saber — cuántas iteraciones hizo el builder, qué alternativas consideró o qué presión de tiempo había. Recibe el artefacto y aplica criterios objetivos: ¿el código compila? ¿Pasan las pruebas? ¿El plan tiene premisas verificables? Esto elimina el efecto esfuerzo: la tendencia a juzgar un resultado como bueno porque el proceso fue laborioso.

Este es el principio de los cuatro ojos trasladado a subagentes. El builder tiene permiso para escribir, crear y modificar. El revisor tiene permiso para leer, analizar e informar — nunca editar directamente. Esa separación de herramientas en el frontmatter del agente es lo que garantiza que el revisor no "corrija mientras revisa" y oculte los problemas encontrados.

O code-reviewer es el caso más claro. El agente builder escribe el diff; el code-reviewer recibe el diff y aplica criterios de corrección, seguridad y cobertura de pruebas, sin saber cuántas versiones descartó el builder. La salida es un informe de hallazgos, no una reescritura.

Un plan de implementación tiene un problema distinto al del código: es internamente coherente por construcción. Quien planificó eliminó las contradicciones del proceso, pero puede haber introducido premisas falsas o dejado preguntas sin respuesta. El plan-roaster es un revisor que recibe el plan y hace exactamente las preguntas incómodas que el autor no quiso hacerse.

La investigación hecha por un subagente presenta sesgo de confirmación acelerado: el agente busca fuentes y, a medida que acumula evidencia, tiende a reforzar la hipótesis que surgió al principio. Un revisor de investigación no cuestiona si el texto es bonito; cuestiona si las las afirmaciones son verificables y si hay contradicciones en las fuentes que el builder pudo haber minimizado.

Agregar un revisor imparcial al final de cualquier pipeline de subagentes es la cambio de mayor impacto por menor costo. Un agente Haiku como revisor, que cuesta una fracción de lo que cuesta el builder, puede detectar errores que el modelo más caro no detectaría en sí mismo. La asimetría es enorme: revisar cuesta menos que construir, pero tiene valor de seguro sobre todo el trabajo anterior.

Dos archivos .md que implementan el patrón del revisor imparcial. Observa cómo ambos usan tools: Read, Grep, Glob — sin permiso de escritura — e instruyen explícitamente a informar, no corregir.

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

Tres prompts para activar el patrón del revisor imparcial en tu trabajo real. El segundo es el más poderoso: pide explícitamente la perspectiva de un ingeniero 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.

Así es como aparece el patrón en la terminal: el builder termina y devuelve un diff; enseguida, el code-reviewer entra con contexto cero, lee el diff y emite el informe. Ten en cuenta que el contexto del maestro permanece reducido durante todo el proceso.

↑ Recreación ilustrativa de la terminal. El builder trabajó en un contexto separado; el revisor empezó desde cero. Maestro usó solo el 9% del contexto.