¿Alguna vez has escrito un plan técnico a las once de la noche, convencido de que era perfecto, y a la mañana siguiente has descubierto que se te olvidó la autenticación?
A mí me ha pasado. Más de una vez. Y lo peor no es el olvido — es que cuando usas una IA para planificar, el plan suena tan coherente que tu cerebro deja de buscar agujeros. Claude te genera un documento con secciones, dependencias, orden de ejecución, y todo cuadra. Parece un plan de ingeniero senior. Pero nadie le ha llevado la contraria.
Aseem Shrey publicó un artículo que clava este problema y propone una solución que me parece elegante: hacer que un segundo modelo revise el plan del primero. Y no una vez — en bucle, hasta que el revisor diga «aprobado».
El problema: nadie discute con tu IA
Cuando usas un solo modelo para planificar y ejecutar, obtienes un resultado coherente pero no cuestionado. La IA no se contradice a sí misma. No va a decir «oye, este modelo de autenticación está incompleto» ni «el quoting de tu script de shell está roto».
Es como si escribieras un documento, te lo revisaras tú mismo, y te dijeras «qué bien está». Pues claro que está bien — lo has escrito tú. Ojo al dato: la revisión por pares existe en ciencia, en ingeniería y en medicina por una razón. No porque los autores sean tontos, sino porque el creador es el peor revisor de su propia obra.
Yo ya escribí sobre esto cuando construí mi consejo Jedi de code review. Pero ahí hablaba de revisar código. Lo que propone Aseem es revisar el plan antes de escribir ni una línea. Es atacar el problema una fase antes.
Cómo funciona: Claude planifica, Codex revisa
La mecánica es un skill de Claude Code — un fichero Markdown, sin infraestructura, sin servicios externos. Cuando invocas /codex-review:
- Claude escribe el plan en un fichero temporal.
- El plan se envía a Codex CLI en modo read-only (puede leer tu codebase para contexto, pero no toca nada).
- Codex revisa y devuelve un veredicto:
VERDICT: APPROVEDoVERDICT: REVISE. - Si dice REVISE, Claude corrige y reenvía. El truco clave: Codex resume la sesión anterior, así que recuerda lo que dijo y comprueba si se ha arreglado de verdad.
- Máximo 5 rondas. En la práctica, suele bastar con 3.
Para entendernos: es un pull request entre dos IAs, donde una propone y la otra le busca las cosquillas. Sin intervención humana.
14 bugs en 3 rondas
En el ejemplo del artículo — un dashboard para un enjambre de agentes — el bucle encontró 14 problemas en el plan original:
Ronda 1 (8 problemas): Sin autenticación en los endpoints de escritura. Bugs de quoting en scripts de shell. Campos de esquema que se pisaban entre sí. Arrays embebidos sin límite. Sin manejo de concurrencia. Estrategia de testing solo manual.
Ronda 2 (6 restantes): Claims no atómicos. Permisos ACL demasiado amplios. Rotación de claves sin especificar. Modelado de estados inconsistente.
Ronda 3: Todo resuelto. Plan aprobado.
La tabla del antes y después lo dice todo:
| Antes | Después |
|---|---|
| Plan en una pasada | 3 rondas de revisión iterativa |
| Sin modelo de auth | API keys por agente + matriz ACL |
| Scripts de shell rotos | CLI tipado con reintentos |
| Esquema con conflictos | Fuente única de verdad |
| Sin concurrencia | Claims atómicos + versionado |
| Testing solo manual | Tests de integración + seguridad |
De cero problemas detectados a catorce cazados y corregidos. Sin que un humano leyera una sola línea del plan.
Por qué la iteración importa más que la revisión
Una revisión de una sola pasada encuentra problemas pero no verifica correcciones. Aseem lo explica bien: el bucle iterativo pilla la clase de problemas del tipo «arreglé una cosa pero rompí otra».
Esto es exactamente lo que pasa en code review real. Le dices a alguien «este lock no es seguro», lo cambia, y al cambiarlo introduce un deadlock en otro path. Si solo miras una vez, te lo comes. Si miras dos, lo pillas.
El detalle técnico que hace que funcione: Codex soporta resume de sesiones. No empieza de cero cada ronda. Recuerda qué dijo, qué se le pidió arreglar, y comprueba que el arreglo es real — no una chapuza que mueve el problema de sitio.
Lo que quiero probar
Después de leer el artículo me quedé con ganas de montar algo parecido. Tengo el plan.md como paso previo a casi cualquier feature seria, y hasta ahora lo reviso yo. Que es como decir que no lo revisa nadie, porque cuando llevas tres horas en una historia de Linear, tu capacidad crítica está por los suelos.
La idea de un /second-opinion me parece natural. No para todo — no voy a pasar por tres rondas de revisión un cambio de CSS. Pero para planes que tocan modelos de datos, autenticación, concurrencia, o cualquier cosa que va a costar días implementar, tener un adversario automático que te diga «oye, ¿y si dos agentes reclaman el mismo recurso a la vez?» vale su peso en oro.
Lo que me atrae especialmente:
- Es un fichero Markdown. No hay servidor, no hay API wrapper, no hay dependencias exóticas. Un
SKILL.mdy a correr. - Es on-demand. No se ejecuta en cada commit ni en cada plan. Tú decides cuándo merece la pena. Leña al mono solo cuando hay algo gordo.
- Es adversarial por diseño. No le pides al revisor que «revise el plan». Le pides que busque agujeros. Que intente romperlo. Esa intención cambia completamente el resultado.
El elefante en la habitación
Hay una pregunta obvia que el artículo no responde del todo: ¿necesitas Codex específicamente, o vale cualquier modelo como revisor?
Mi intuición dice que lo que importa es que sea un modelo distinto. El valor está en la diversidad de sesgos. Si Claude planifica y Claude revisa, es como si te revisaras tú mismo — comparten los mismos puntos ciegos. Meter un modelo con entrenamiento diferente, con heurísticas diferentes, es lo que produce el efecto «abogado del diablo» real.
Dicho esto, la implementación con Codex CLI tiene una ventaja práctica seria: el resume de sesiones. Que el revisor recuerde rondas anteriores no es un nice-to-have — es lo que convierte esto en un bucle de mejora real en vez de tres revisiones independientes que repiten los mismos hallazgos.
Cuándo no usarlo
El propio Aseem lo dice: cuando la velocidad importa más que la exhaustividad, no merece la pena. Un hotfix en producción a las tres de la mañana no necesita tres rondas de revisión adversarial. Necesita un parche, un test, y un deploy.
También me imagino que para planes pequeños — «añadir un campo a un formulario» — el overhead no compensa. La regla que me pongo es: si el plan tiene más de una página, o si toca algo que comparten más de dos módulos, merece un /second-opinion.
La moraleja
Lo más interesante de esta idea no es la implementación técnica — que es simple. Es el cambio de mentalidad. Hasta ahora, el consenso era «usa IA para planificar, luego ejecuta el plan». Nadie cuestionaba el plan. El plan era sagrado porque lo había generado un modelo inteligente.
Pero un plan no revisado es un plan con bugs latentes. Da igual que lo haya escrito GPT-4, Claude, Codex o un ingeniero con veinte años de experiencia. Sin revisión adversarial, sin alguien que diga «¿y si esto falla?», estás jugando a la ruleta con la complejidad que aún no ves.
Un fichero Markdown. Dos modelos. Tres rondas. Catorce bugs menos. No está mal para algo que cabe en un gist.
Read this article in English.
