Claude Code y Codex, en paralelo

Casi todo lo que se discute sobre agentes de programación con IA da por hecho que eliges uno. En la práctica, si trabajas con agentes todo el día, no es así: recurres al que mejor encaja con la tarea que tienes delante y, cada vez más, los ejecutas a la vez en el mismo proyecto. Así es como se ve de verdad.

No apuestas por un proveedor, eliges una herramienta

Tratar «Claude Code contra Codex» como una cuestión de lealtad es un error de categoría. Son herramientas con un tacto distinto, y la pregunta interesante no es cuál gana, sino a cuál recurres y cuándo. Después de suficientes sesiones le coges el truco, igual que aprendes cuándo compensa escribir un script y cuándo hacerlo a mano.

Más o menos queda así: un agente se lleva las tareas que puedes describir con claridad y quieres ver ejecutadas, y el otro, el trabajo en el que prefieres que se quede más tiempo con la ambigüedad antes de tocar nada. Cuál es cuál depende del día, de las versiones de los modelos y de tu propio gusto. Y va cambiando a medida que cambian las dos herramientas.

La cuestión no es un ranking fijo. Es que, teniendo las dos a mano, nunca fuerzas la herramienta equivocada en una tarea solo porque es la única que tienes abierta.

Los dos en el mismo código

El movimiento realmente útil es el paralelismo entre proveedores. Pon un agente con la capa de API y otro con los tests. Que uno redacte una migración mientras el otro trabaja en los cambios de interfaz que dependen de ella. Ejecuta un par del mismo proveedor y uno del otro, y deja de pensar en ellos como «mis sesiones de Claude» y «mis sesiones de Codex». Son simplemente tus agentes, trabajando.

Aquí es donde la dependencia de un proveedor se nota de verdad, y no en el sentido habitual. El problema no es no poder cambiar más adelante. Es que una herramienta de un solo proveedor solo puede enseñarte la mitad de tu flota a la vez. Si tu vista de estado solo entiende Claude, las dos sesiones de Codex que tienes en marcha le resultan invisibles, y vuelves a ir pestaña por pestaña para comprobarlas. Una vista unificada solo funciona si es independiente del proveedor desde la base, con un detector por CLI que alimente una sola cuadrícula.

Así está construido vord. Ejecuta cinco CLI de agentes en el mismo cockpit: Claude Code, Codex, Kimi, OpenCode y Grok. Tú las instalas y las arrancas; vord aloja las sesiones y lee su estado. Este artículo se centra en las dos por las que más se pregunta, pero nada de lo que cuenta es exclusivo de ellas.

El problema de coordinación del que nadie te avisa

Dos agentes en el mismo repositorio pueden pisarse. Los dos deciden tocar el mismo archivo. Los dos asumen que son los únicos trabajando. Acabas arbitrando un merge entre dos de tus propios agentes, que es una forma realmente extraña de pasar una tarde.

No hay solución mágica, pero sí una mitigación real: dile a cada agente en su prompt que no está solo. Una línea como «ahora mismo hay otros dos agentes trabajando en este proyecto» cambia cómo razona un agente sobre el alcance. Se vuelve más prudente con los cambios amplios y tiende a quedarse en su carril. No elimina los conflictos, pero reduce los de agentes seguros de sí mismos y ajenos a todo, los que reescriben un archivo delante de las narices de otro porque no tenían ni idea de que había alguien más.

La otra mitad depende de ti: dales trabajo que no se solape. El paralelismo es seguro cuando los agentes se ocupan de archivos o responsabilidades distintas. En cuanto dos agentes editan la misma zona, has convertido el trabajo en paralelo otra vez en trabajo secuencial, con conflictos añadidos. Divide la tarea para que las costuras entre agentes caigan en límites reales.

El flujo de trabajo, en concreto

Así se ve en una herramienta preparada para ello:

• Una cuadrícula, los dos proveedores. Sesiones de Claude Code y de Codex en la misma vista, con los mismos estados y las que esperan primero. No cambias entre dos apps para ver las dos mitades de tu trabajo.

• MCP gestionado para ambos. Los servidores MCP que usan tus agentes se gestionan en un solo sitio, tanto para Claude como para Codex, a través de sus CLI oficiales, así que las capacidades son coherentes en lugar de configurarse dos veces.

• Un estado que distingue. Cada CLI tiene su propio detector por debajo, basado en hooks donde la CLI los admite y en lectura de pantalla donde no. Todos se traducen a los mismos estados, así que la cuadrícula se lee igual sea quien sea el que está en marcha.

• Revisión en un solo sitio. Cuando cualquiera de los dos termina, el mismo inspector de git te muestra el diff. Revisas el trabajo de Claude y el de Codex de la misma forma.

El límite honesto

Ejecutar los dos no duplica lo que produces, y no sale gratis. Duplica las decisiones y los diffs que leer, y añade la posibilidad de que dos agentes choquen. Compensa cuando el trabajo de verdad se divide en partes independientes y tienes una vista que muestra a los dos proveedores como una sola flota.

Si fuerzas el paralelismo en un trabajo que en realidad es secuencial, lo notarás como fricción, no como velocidad.

Pero cuando el trabajo sí se divide, y buena parte lo hace, tener Claude Code y Codex uno junto a otro en una cuadrícula, vigilados por un solo motor de estado, es un día notablemente mejor que saltar entre dos herramientas que solo ven su propia mitad.