Últimamente en X y Discord han aumentado bastante las publicaciones de gente que dice “usa Claude Code y Codex juntos”, y como todo el mundo hablaba bien de eso, probé durante alrededor de un mes instalando y haciendo funcionar ambas herramientas en un mismo repo. Cuando quise adoptarlo de verdad, me di cuenta de que había un montón de puntos de decisión: por dónde empezar el setup, cómo repartir el trabajo entre las dos herramientas para que no choquen, si AGENTS.md y CLAUDE.md deberían llenarse con el mismo contenido o no. Así que lo organicé en forma de un currículo de 8 capítulos para que quienes aún no arrancan por tener las mismas dudas puedan reducir la prueba y error.
El workflow de doble agente es simple. Si haces que el mismo modelo escriba el código y además lo revise, tiende a aceptar las mismas suposiciones con las que lo escribió y no detecta sus propios huecos; por eso la estructura consiste en poner al lado otro modelo como revisor advisory (sin bloqueo). Claude Code es el autor principal y Codex el revisor advisory. La clave no es cuál de los dos es más inteligente, sino que son modelos distintos; y en cuanto uno se vuelve el gate del otro, el workflow se rompe, así que la regla más importante es no convertir nunca ese advisory en un bloqueo.
Antecedentes — cambios que volví a repasar mientras lo ordenaba
• Antes la pregunta era: “¿Cuál herramienta de AI coding es la mejor?”
• Ahora la pregunta es: “¿Cómo repartir el trabajo entre dos o más herramientas?” y “¿Cómo cubrir con otra herramienta los puntos ciegos de una?”
• Con comandos slash y subagentes en Claude Code, la separación review/exec en Codex, y archivos de contexto como AGENTS.md, recién ahora se volvió una opción realista incorporar esta estructura doble directamente al workflow
Puntos clave del patrón de doble estructura (lo que más me impresionó tras usarlo un mes)
• advisory nunca significa bloqueo — aunque Codex detecte algo CRITICAL, el push sigue pasando. Si una sola vez se convierte en bloqueo, una caída del modelo puede detener todo el trabajo; y con un solo falso positivo, el usuario empieza a saltarse el hook completo con --no-verify
• CLAUDE.md / AGENTS.md no se llenan con el mismo contenido — al autor se le da “cómo construirlo”, al revisor “qué debería sospechar”. Si se superponen más de un 80%, es señal de que en la práctica no hay reparto de funciones
• codex review --base vs codex exec se separan por caso de uso — review lee git directamente y queda limpio, pero en PR grandes puede disparar el consumo de tokens; exec permite controlar el costo metiendo el diff directo en el prompt. Cuando los cambios superan 100 archivos, el patrón es cambiar a exec
• La defensa en dos etapas para secretos en el pre-push hook — los patrones de archivos (.env, *.pem, secrets/) abortan el push; las regex inline (sk-, ghp_, AKIA…) solo muestran advertencia. Que advisory “never block” aplica a la salida del modelo; hacer push de archivos secretos es un incidente de seguridad aparte, así que ahí sí corresponde bloquear
• Todo se absorbe con un único wrapper de graceful degradation — envelope JSON por defecto + Markdown con --raw, timeout nativo de bash, y siempre exit 0. El llamador solo ramifica mirando status
Qué cambió después de usarlo un mes
• Aumentó la cantidad de bugs detectados justo antes del merge. Aparecen con bastante frecuencia casos donde Claude dice con confianza “está bien hecho” y Codex termina señalando race conditions o checks de null faltantes
• Casi desapareció eso de volver a abrir el PR al día siguiente y pensar “¿por qué hice esto así?”. Como ya entró una segunda mirada desde otro ángulo, baja el costo de la revisión de regresiones
• Se redujo claramente la fatiga del self-review, esa de revisar tu propio código tú mismo. El efecto es parecido a sumar un revisor humano más
• En cambios difíciles de revertir, como SQL de migración o flujos de pago, la mayor diferencia psicológica es saber que otro modelo lo vio una vez más antes de avanzar
Estructura del currículo (8 capítulos, 5 partes)
• Parte 1, forma de pensar el uso combinado de dos agentes · 1 capítulo — puntos ciegos de un agente único, criterios para justificar el costo
• Parte 2, entorno y contexto · 2 capítulos — setup base de VSCode + Claude Code + Codex CLI, reparto entre AGENTS.md y CLAUDE.md
• Parte 3, patrones de automatización de review · 3 capítulos — script wrapper advisory, pipeline multifase con comandos slash, automatización con pre-push hook
• Parte 4, guía operativa · 1 capítulo — árbol de decisión para elegir herramienta según tipo de trabajo, guía de costos y modelos, sección de Security & Privacy
• Parte 5, boilerplate · 1 capítulo — paquete de plantillas de wrapper, hook y CLAUDE.md/AGENTS.md que puedes instalar tal cual en tu repo
Lo que pensé mientras lo ordenaba
• El valor real de esta estructura doble está en que “las dos herramientas no se vuelvan el gate una de la otra”. Si permites un solo bloqueo, una caída de uno de los lados puede frenar el trabajo; y con un solo falso positivo, el usuario empieza a saltarse el hook entero, dejándolo inutilizado
• Cuanto más rápidas se vuelven las herramientas de AI, más parece que la variable decisiva deja de ser “qué herramienta usas” y pasa a ser “cómo superpones los puntos ciegos de varias herramientas para cubrirlos”. Es la misma lógica detrás de pedir code review humano a más de una persona
• Lo comparto porque puede servirles a quienes no terminaban de confiar en revisar su propio código mientras trabajan con herramientas de AI coding, o a quienes vienen postergando si instalar o no juntos Claude Code y Codex. Si hay partes que entendí o resumí mal, avísenme en los comentarios y lo corregiré.
2 comentarios
Dicen que hay gente que lo hace así, y me da curiosidad saber de qué manera lo implementan.
No sé si el desarrollador invoca cada herramienta directamente cuando la necesita, sin agruparlas como agentes separados,
o si lo resuelven con una configuración para que Codex haga la revisión automáticamente al ejecutar un Git Hook.
Nosotros terminamos estableciéndonos en usar ambos.
Metemos una fase de revisión cruzada con Codex dentro del flujo de comandos slash (dentro de
/ship, en el orden planificación → implementación → verificación → revisión con Codex → reporte) y, al mismo tiempo, colgamos esa misma revisión en elpre-push hook. Si dejas solo los comandos slash, cuando hay prisa alguien simplemente hace push y la revisión se salta; si dejas solo el hook, el resultado recién aparece justo antes del push y ya es tarde.En ambos caminos no llamamos directamente al Codex CLI, sino que desde los dos lados invocamos exactamente el mismo script de bash envuelto una vez (
codex-review.sh). Ese script resuelve en un solo lugar el timeout, la verificación de autenticación, la revisión de secretos y el formato de salida, así que tanto en comandos slash como en hooks el lado que lo invoca queda limpio.La clave es que jamás bloqueamos en función del resultado de la revisión de Codex. Aunque el CLI se caiga o salga un
CRITICAL, el push igual pasa y solo se imprime el resultado. Si aunque sea una vez lo conviertes en bloqueo, cuando Codex marque por error código que en realidad no tiene problemas, el usuario va a terminar usando la opción para saltarse el hook al hacer push (git push --no-verify), y si eso se vuelve costumbre, tener el hook puesto pasa a ser prácticamente lo mismo que no ejecutarlo nunca. Por eso, las verificaciones que sí necesitan bloqueo (lint, tipos, tests, push de archivos secretos) las separamos en gates aparte, y dejamos la opinión del modelo solo como referencia.El script, los comandos slash y el cuerpo del hook están tal cual en los capítulos 4 a 6 de Track, por si te sirve revisarlos.