Le pides a Claude que revise el trabajo que acaba de hacer y te contesta que se ve bien. Casi siempre. Aunque no lo esté.
No es que mienta. Es que le estás pidiendo una opinión a alguien que tiene todo el razonamiento que produjo el error todavía enfrente. El modelo ya se convenció una vez. Volver a preguntarle en el mismo hilo es pedirle que se contradiga contra su propio contexto, y eso es exactamente lo que un modelo de lenguaje hace peor.
La solución no es un mejor prompt de revisión. Es cambiar quién revisa.
Por qué la autocrítica en el mismo chat no funciona
Cuando Claude escribe algo, todo el camino que lo llevó ahí queda en el contexto: los archivos que leyó, las decisiones que tomó, las suposiciones que hizo sin decirlas. Si le pides que revise, revisa con ese camino a la vista. Lee su propia justificación y la encuentra razonable, porque la escribió él.
Hay un detalle práctico encima: si le preguntas "¿está bien?", el patrón más probable en cualquier conversación humana es responder que sí. El modelo está entrenado sobre conversaciones humanas.
La documentación de Claude Code lo dice sin adornos: un revisor que corre en un subagente ve solo el resultado y los criterios que le das, no el razonamiento que lo produjo. Por eso lo evalúa por sus propios méritos. Esa es toda la magia. Contexto fresco.
La regla: contexto fresco más criterio explícito
Dos cosas tienen que ser ciertas para que una revisión sirva:
- El revisor no vio cómo se hizo. Solo el entregable. En Claude Code eso es un subagente; en la app de Claude, una conversación nueva donde pegas el resultado y nada más.
- El criterio está escrito. "Revísalo" no es un criterio. "Verifica que cada requisito de este documento esté implementado y que nada fuera del alcance haya cambiado" sí lo es.
Sin lo segundo pasa algo peor que no revisar: el revisor inventa problemas. Si le pides que encuentre fallas, va a encontrar fallas, porque eso le pediste. Terminas persiguiendo comentarios de estilo mientras el error de fondo sigue ahí.
Los cinco prompts
Estos los uso en operación real: revisión de propuestas comerciales, de configuraciones de campaña, de reportes de cierre. No son solo para código.
1. El revisor ciego
El más simple y el que más rinde. Abre una conversación nueva, pega solo el entregable y nada del proceso.
Eres un revisor externo. No participaste en este trabajo y no vas a ver
cómo se hizo.
Abajo está un entregable. Tu única tarea es decirme si cumple con lo que
promete, evaluándolo por sí mismo.
Reglas:
- Señala únicamente lo que afecta correctitud o el requisito declarado.
- Ignora preferencias de estilo.
- Si algo está afirmado sin evidencia, márcalo como "no verificable" en vez
de asumir que es cierto.
- Si no encuentras nada, dilo. No inventes hallazgos para llenar la lista.
Devuelve máximo 5 hallazgos, cada uno con: qué encontraste, por qué importa,
y qué cambiarías exactamente.
ENTREGABLE:
[pega aquí]Para quién: cualquiera. Es el mínimo indispensable antes de mandar algo a un cliente.
2. El verificador contra la especificación
Cuando sí escribiste lo que querías antes de empezar, esta es la revisión que atrapa el 80% de los problemas: no busca errores, busca huecos entre lo pedido y lo entregado.
Te voy a dar dos cosas: una especificación y un entregable.
Tu trabajo NO es opinar sobre la calidad. Es hacer un cotejo línea por línea.
Para cada requisito de la especificación, clasifícalo:
- CUMPLE: y cita la parte del entregable que lo cumple.
- PARCIAL: y di exactamente qué falta.
- NO CUMPLE: y di dónde debería estar.
- FUERA DE ALCANCE: algo que está en el entregable pero nadie pidió.
Al final, una sola línea: ¿esto se puede entregar o no?
ESPECIFICACIÓN:
[pega aquí]
ENTREGABLE:
[pega aquí]Para quién: equipos donde alguien pide y alguien entrega. Convierte discusiones de "no era lo que quería" en una tabla.
3. El panel de tres personajes
El que más me sorprendió. En vez de una opinión promedio, pides tres opiniones con incentivos distintos. Los desacuerdos entre ellos son la parte útil.
Vas a evaluar el entregable de abajo desde tres personajes distintos. Cada
uno responde por separado, con su propio sesgo, sin suavizar.
PERSONAJE 1 — El escéptico técnico.
Le paga que esto no truene. Busca supuestos no declarados, casos límite,
dependencias frágiles y cifras que nadie verificó. Pregunta "¿cómo lo sabes?"
a cada afirmación.
PERSONAJE 2 — El cliente que va a pagar.
No le importa cómo se hizo. Le importa si esto resuelve su problema, si lo
entiende sin explicación, y si le parece caro. Es impaciente y dice lo que
piensa.
PERSONAJE 3 — El operador que se queda con esto.
Es quien lo va a mantener el próximo año. Busca lo que se rompe cuando la
persona que lo hizo ya no está: pasos manuales escondidos, cosas que solo
funcionan en una máquina, conocimiento que no quedó escrito.
Cada personaje: 3 observaciones, ninguna genérica.
Al final, tú como moderador: ¿en qué coinciden los tres? Ese es el problema
real. ¿En qué se contradicen? Ahí hay una decisión que alguien tiene que
tomar y todavía no tomó.
ENTREGABLE:
[pega aquí]Para quién: propuestas, precios, decisiones de arquitectura y cualquier cosa donde el riesgo no es un error sino un punto ciego.
4. El refutador
En vez de pedir revisión, pides demolición. Cambia la meta del modelo de "confirmar" a "derribar", y eso cambia lo que encuentra.
Tu objetivo es demostrar que esta conclusión está equivocada.
No busques equilibrio. Asume que hay un error y encuéntralo. Ataca en este
orden:
1. Los datos: ¿de dónde salió cada número? Marca los que no tienen fuente.
2. El salto lógico: ¿en qué punto la conclusión asume algo que no se probó?
3. La alternativa: dame la explicación rival más fuerte de los mismos hechos.
4. La prueba: ¿qué evidencia específica cambiaría la conclusión? Si no
existe ninguna, la conclusión no es falsable y eso también es un problema.
Solo si después de todo eso no logras derribarla, dilo explícitamente y
explica por qué aguantó.
CONCLUSIÓN A REFUTAR:
[pega aquí]Para quién: análisis, pronósticos, casos de negocio. Todo lo que va a sostener una decisión cara.
5. El de lo que falta
Los cuatro anteriores buscan lo que está mal. Este busca lo que no está. Es distinto y suele ser más caro de descubrir tarde.
No revises lo que está escrito. Dime qué NO está.
Contexto: este entregable es [describe qué es y para quién].
Responde tres preguntas:
1. ¿Qué pregunta obvia se va a hacer quien lo reciba y no está contestada aquí?
2. ¿Qué tuvo que quedar fuera para que esto se viera limpio? Nombra las
omisiones convenientes.
3. Si esto sale mal en tres meses, ¿cuál es la causa más probable, y está
mencionada en algún lado?
Sé concreto. Nada de "podría faltar más detalle".
ENTREGABLE:
[pega aquí]Para quién: quien manda documentos hacia arriba. Los directores no preguntan por lo que escribiste, preguntan por lo que no.
El paso que todo mundo se salta: decirle al revisor que puede no encontrar nada. Sin esa instrucción explícita, siempre reporta hallazgos, incluso cuando el trabajo está bien, y acabas metiéndole capas de defensa a algo que ya funcionaba. Un revisor que dice "no encontré nada relevante" es más valioso que uno que siempre encuentra tres cosas.
Cómo se corre esto sin copiar y pegar
En la app de Claude, la versión honesta es abrir un chat nuevo. Nada más. Si pegas el resultado en la misma conversación, no cambiaste nada.
En Claude Code no hace falta: los subagentes existen justo para esto. Corren en su propia ventana de contexto y regresan solo el resumen. Le pides algo como "usa un subagente para revisar este cambio contra el plan y reporta huecos, no preferencias de estilo" y el revisor arranca en frío. Hay además una revisión empaquetada, /code-review, que hace el cotejo del diff actual en un subagente aparte.
Si quieres que sea permanente, la ruta es guardar el prompt como una skill o un subagente en tu proyecto, para que deje de ser algo que te acuerdas de hacer. Eso es lo que separa la revisión que ocurre siempre de la que ocurre cuando no traes prisa. En las 7 formas de controlar Claude Code está dónde vive cada una.
El orden en que conviene usarlos
No corras los cinco. Se contradicen entre sí y acabas paralizado.
- Siempre: el revisor ciego. Es barato y atrapa lo evidente.
- Si escribiste una especificación: el verificador. Sustituye al revisor ciego, no lo acompaña.
- Antes de mandarlo a alguien con poder de decisión: el panel de tres.
- Cuando hay dinero o reputación de por medio: el refutador, y solo sobre la conclusión, no sobre el documento entero.
- Antes de la versión final: el de lo que falta.
Y una regla que aprendí perdiendo tiempo: si el revisor te tira quince hallazgos, no arregles quince. Ordénalos por si afectan el resultado o no. Los que no lo afectan son ruido con buena redacción.