Dos IAs Revisando Tu Código Son Mejor Que Una — Claude + Codex Peer Review
Hay un problema bien conocido en desarrollo de software: la misma persona que escribió el código generalmente es la peor persona para revisarlo. Eres ciego a tus propios supuestos. Lees lo que quisiste escribir, no lo que realmente escribiste.
Lo mismo aplica a la IA.
Claude escribe algo, Claude lo revisa, y Claude tiene exactamente las mismas probabilidades de pasar por alto el mismo tipo de error. La solución — en equipos de ingeniería humanos y cada vez más en flujos de trabajo con IA — es traer una segunda perspectiva.
Esa segunda perspectiva ahora es Codex.
La lógica detrás del peer review de IA
La idea es directa: después de que Claude termina de implementar algo, no aceptas el output de inmediato. Despachas un segundo modelo — en este caso Codex de OpenAI — para que revise independientemente el trabajo, lo critique, y surfacee cualquier cosa que pudo haberse pasado por alto.
Modelos diferentes, entrenados en datos diferentes, con arquitecturas diferentes, detectan cosas diferentes. Claude puede ser excelente en razonamiento arquitectónico y pasar por alto un problema sutil de concurrencia que Codex marca. Lo inverso también es igual de cierto. Que se revisen mutuamente es una forma práctica de acercarse a la corrección sin esperar un ciclo completo de revisión humana.
La premisa no es que uno sea mejor que el otro. Es que la divergencia entre modelos es una señal de valor.
Dos implementaciones que vale la pena conocer
hamelsmu/claude-review-loop — La opción práctica para el día a día
Esta es probablemente la implementación más útil para uso cotidiano. Instálala como plugin de Claude Code y obtienes un nuevo comando /review-loop. Lo que pasa internamente:
- Describes una tarea. Claude la implementa.
- Cuando Claude termina, un Stop hook intercepta la salida — antes de que cualquier cambio llegue a tu codebase.
- Codex arranca (hasta 4 sub-agentes en paralelo, dependiendo del tipo de proyecto) y revisa independientemente lo que Claude escribió.
- La revisión se consolida y se escribe en
reviews/review-<id>.md. - Claude recibe la retroalimentación y debe resolverla antes de poder firmar el trabajo.
Cada tarea recibe una segunda opinión independiente antes de que aceptes cualquier cambio. El ciclo de revisión ocurre automáticamente — no tienes que dispararlo manualmente.
claude plugin marketplace add hamelsmu/claude-review-loop
claude plugin install review-loop@hamel-review
Luego en cualquier sesión de Claude Code:
/review-loop
alecnielsen/adversarial-review — El debate estructurado
Esta implementación adopta un enfoque más riguroso. Corre cuatro fases:
- Revisión independiente — Claude y Codex revisan el código por separado.
- Revisión cruzada — cada modelo lee y critica los hallazgos del otro.
- Meta-revisión — cada uno responde a la crítica recibida.
- Síntesis — Claude evalúa todos los artefactos del debate, decide cuáles problemas son válidos, e implementa correcciones con confianza alta o media.
Luego el loop se repite hasta que ambos agentes reportan que no hay problemas restantes.
Es más exhaustivo y más costoso en tokens que el review loop. Vale la pena para decisiones de arquitectura y código sensible a seguridad. Probablemente excesivo para un endpoint CRUD estándar.
El mecanismo de escalación
Ambas implementaciones — y el plugin Agent-Peer-Review de Composio — comparten una característica particularmente útil: cuando Claude y Codex genuinamente no están de acuerdo, el workflow no simplemente elige un lado.
Escala.
El desacuerdo se envía a Perplexity o búsqueda web para arbitraje externo — trayendo documentación actualizada, mejores prácticas conocidas, o conocimiento de la comunidad para resolver el conflicto. El resultado es una respuesta con fuente, no la posición de cualquier modelo que resultó ser más confiado.
Este es el detalle que hace que todo sea prácticamente útil. El output de IA confiado pero incorrecto es uno de los principales modos de falla en el desarrollo asistido por IA. Incluir una capa de “estos dos no están de acuerdo, busquemos” captura una porción significativa de esos casos.
Para qué usarlo (y para qué no)
Este no es el flujo correcto para cada tarea. Algunas guías prácticas:
Úsalo para lógica compleja y código sensible a seguridad. Flujos de autenticación, procesamiento de pagos, cualquier cosa donde un bug sutil tiene consecuencias reales. El ciclo de revisión extra vale el tiempo invertido.
Saltéalo para boilerplate. Una migración de datos simple o un scaffold no necesitan revisión adversarial. Gastarás más tokens de los que justifica el riesgo.
Úsalo como benchmark. Corre ambos modelos contra el mismo problema antes de una decisión arquitectónica importante. Donde coinciden, tienes alta confianza. Donde difieren, tienes una señal interesante que vale la pena investigar.
El tradeoff honesto
Estás duplicando (o más) tu uso de tokens y agregando latencia a cada tarea. Eso es real.
Pero si ya estás en Claude Code haciendo trabajo con consecuencias, la alternativa es despachar código que una IA revisó una vez y llamarlo listo. Para cualquier cosa donde la corrección realmente importa, el costo de una segunda opinión suele ser menor que el costo del bug que previene.
El peer review de dos IAs no es una bala de plata. Es una mejora estructural a un flujo de trabajo que de otra forma era inherentemente unilateral.
Links
- claude-review-loop: github.com/hamelsmu/claude-review-loop
- adversarial-review: github.com/alecnielsen/adversarial-review
- Composio Agent-Peer-Review: github.com/composio/awesome-claude-plugins