Un Claude que corrige al otro

Qué es y por qué importa

Cuando una sesión de Claude Code termina un trabajo y te dice «hecho», lo natural es pedirle que lo revise. Funciona poco. Acaba de escribir ese código, sabe por qué lo ha hecho así, y cuando lo vuelve a leer ve lo que quería hacer, no lo que ha hecho de verdad.

Es el mismo punto ciego que tenemos nosotros cuando releemos un texto nuestro. Los errores que se escapan son justo los que no imaginaste mientras escribías: el campo que se deja vacío, el doble clic, el usuario que abre los datos de otro.

Por eso el control se lo dejo a otra sesión, que empieza sin la conversación de la primera. Solo ve los cambios y una tarea: encontrar cómo romperlos. Lo dice también la guía oficial de Claude Code: una sesión con el contexto limpio revisa mejor el código, porque no está atada a lo que acaba de escribir.

Por qué importa: si construyes una app sin ser desarrollador, todavía no tienes el ojo para ver estos agujeros. Un revisor que tiene la tarea de atacar el código los busca por ti, antes de que los encuentren los usuarios.

1. El prompt del revisor

Este es el prompt que pego en la segunda sesión, palabra por palabra. Tal cual funciona antes del commit. Si ya has hecho commit, añade al final qué archivos mirar.

Eres un revisor externo. No has escrito tú este código y no sabes por qué está hecho así: no lo preguntes y no busques justificaciones. Mira solo los cambios recién hechos: ejecuta git status y git diff, y lee enteros los archivos nuevos que lista git status (el diff no los muestra). Tu única tarea es encontrar cómo romperlos. Busca:
- entradas: campos vacíos, textos larguísimos, caracteres raros, números negativos, doble clic, peticiones duplicadas;
- permisos: quién puede ver o modificar datos que no son suyos, qué pasa sin iniciar sesión o con la sesión de otro;
- casos límite: listas vacías, red lenta o sin red, dos usuarios en el mismo momento;
- seguridad: claves o contraseñas en el código, datos del usuario usados sin control, errores que muestran demasiado.
Para cada problema escribe: dónde (archivo y línea), cómo lo rompo (los pasos exactos), qué pasa, gravedad (alta, media, baja). Ordena del más grave. No corrijas nada y no modifiques los archivos: solo quiero el informe.

Cada parte tiene un motivo.

• «No has escrito tú este código»: le quito el papel de autor. Un autor defiende su trabajo, un revisor externo busca los defectos.
• «Ejecuta git status y git diff, y lee enteros los archivos nuevos»: git diff solo muestra los cambios en los archivos que git ya conoce. Los archivos creados desde cero los encuentra con git status, y sin esta línea se quedarían fuera.
• «Tu única tarea es encontrar cómo romperlos»: no le pregunto si el código está bien. Le pido que lo ataque, que es otra pregunta.
• Las cuatro áreas, es decir entradas, permisos, casos límite y seguridad, son los puntos donde más a menudo se rompen las apps hechas con prisa. Si tu app tiene una parte delicada, como los pagos, añádela como quinta línea.
• «Cómo lo rompo (los pasos exactos)»: un problema con los pasos lo compruebas tú en dos minutos. Un «podría haber un problema», no.
• «No corrijas nada y no modifiques los archivos»: el revisor avisa, no toca. Si corrigiera él, tendrías dos sesiones cambiando los mismos archivos y ya no sabrías quién ha hecho qué.

2. Cómo lo uso

1. Cuando la primera sesión dice «hecho», no le pido que se revise a sí misma.
2. Abro un terminal nuevo en la misma carpeta y lanzo claude. O, en la misma ventana, /clear abre una conversación nueva con el contexto vacío. La anterior queda guardada y la retomas con /resume.
3. Pego el prompt. Antes del commit, git status y git diff muestran el trabajo recién hecho. Después del commit, le indico los archivos.
4. Llevo el informe a la primera sesión y hago corregir empezando por la gravedad alta.
5. En login, pagos y datos de los usuarios reviso también la corrección, en otra sesión nueva.

Un detalle sobre git diff: muestra los cambios en los archivos que git ya conoce, así que los archivos nuevos no están. Por eso en el prompt está git status, que los lista, y el revisor los lee enteros. Si prefieres verlos también en el diff, antes de abrir el revisor lanza git add -N . en el terminal: git los marca como archivos por añadir y a partir de ahí aparecen en git diff.

El revisor no debe poder escribir

En el prompt pone que no modifique los archivos, pero es una petición, no un bloqueo. Si quiero estar seguro, abro la segunda sesión en plan mode:

claude --permission-mode plan

En plan mode Claude lee los archivos y puede lanzar comandos para explorar, como git diff, pero no modifica el código hasta que apruebas un plan. Si al final te propone un plan de correcciones, no lo apruebes: con el informe te basta. Si la sesión ya está abierta, entras pulsando Shift+Tab hasta que abajo aparece «plan mode on».

Llevar el informe de vuelta

En la primera sesión pego el informe con un prompt así:

Aquí tienes el informe de un revisor externo: [pega el informe]. Corrige primero los problemas de gravedad alta, uno a uno. Para cada uno dime qué has cambiado y cómo lo has comprobado. Los de gravedad baja no los toques: los decido yo.

Si había usado /clear, primero vuelvo a la conversación de partida con /resume, así la sesión que corrige tiene otra vez todo el contexto del trabajo.

Las bajas me las quedo por un motivo concreto. Un revisor al que le pides que encuentre problemas casi siempre encuentra alguno, aunque el trabajo esté bien hecho, porque es lo que le has pedido. Si lo corriges todo, acabas con código de más para casos que nunca van a pasar.

3. Con un subagente, en la misma ventana

Si no quieres abrir otra ventana, el revisor puede ser un subagente: un ayudante que trabaja dentro de tu sesión, con su propio contexto, y no ve la conversación. En la guía sobre los subagentes explico cómo crear un code-reviewer fijo con solo las herramientas para leer.

La ventaja: el informe vuelve directamente a la sesión que ha escrito el código, sin copiar y pegar. El riesgo: la tarea del subagente la escribe Claude, y Claude sabe por qué lo ha hecho así. Si se lo explica, el revisor empieza ya convencido. Así que le pido que pase el prompt tal cual:

Haz que el subagente code-reviewer revise los últimos cambios. Pásale este prompt palabra por palabra, sin añadir explicaciones sobre cómo o por qué has escrito el código: [pega el prompt del revisor]

Para las partes delicadas, eso sí, prefiero la sesión nueva: ahí el prompt lo pego yo y sé exactamente qué ha recibido el revisor.

La regla de oro

Nada de la conversación anterior: si le explicas por qué lo has hecho así, acaba dándote la razón.

Vale también para ti. Cuando pegas el prompt, no añadas «lo he hecho así porque…». Dale los cambios y la tarea, y ya está. Las explicaciones sirven después, cuando decides qué problemas corregir.

Una sesión nueva lee igualmente las instrucciones del proyecto (CLAUDE.md) y la memoria automática, si las usas. Está bien: son reglas, no la historia de cómo nació ese código.

Errores comunes

• Pedirle a la misma sesión que se revise: abre una sesión nueva, o usa /clear, así quien revisa no ha escrito el código.
• Explicarle al revisor por qué el código está hecho así: dale solo los cambios y la tarea, si no acaba dándote la razón.
• Dejar que el revisor corrija: pídele solo el informe y haz que corrija la sesión que ha escrito el código.
• Corregir cada problema señalado: empieza por la gravedad alta y las bajas decídelas tú, si no llenas el código de defensas inútiles.
• Fiarse solo de git diff cuando hay archivos nuevos: en el diff no aparecen, así que haz que ejecute también git status, como en el prompt.
• No revisar la corrección en las partes delicadas: para login, pagos y datos de los usuarios, repite la revisión en una sesión nueva.

Lista de comprobación

• El revisor está en una sesión nueva
• El prompt está pegado sin explicaciones
• Antes del commit: git status y git diff. Después: los archivos indicados
• Cada problema tiene dónde, pasos, efecto y gravedad
• Los problemas de gravedad alta están corregidos y comprobados
• Las partes delicadas han tenido una segunda revisión

Preguntas frecuentes