Agentes de código en paralelo: Claude Code y Codex juntos

Ejecuta Claude Code y Codex en paralelo como agentes de código: reparte el trabajo, evita conflictos de archivos con worktrees y pasa la salida de un agente a otro.

Solviera Teknoloji 7 min de lectura

Ejecutar agentes de código en paralelo significa tener más de un agente de código con IA trabajando en el mismo proyecto a la vez. Un agente escribe una función, otro escribe los tests, un tercero actualiza la documentación. Bien montado, repartes un trabajo que antes hacías paso a paso. Mal montado, los agentes pisan los mismos archivos, el contexto se infla y pierdes la pista de quién hizo qué.

Este artículo recorre una forma práctica de ejecutar Claude Code y Codex en paralelo: cómo repartir el trabajo, cómo evitar conflictos de archivos y cómo pasar la salida de un agente al siguiente.

¿Por qué agentes de código en paralelo?

El cuello de botella con un solo agente es la espera. Mientras piensa, lee archivos y ejecuta tests, tú esperas o te pasas a otra cosa. Los agentes en paralelo aprovechan ese tiempo de espera.

Rinden más cuando tienes:

  • Trabajo independiente: un endpoint de backend y un formulario de frontend que no se tocan.
  • Escribir y comprobar: un agente escribe el código, otro escribe tests para el mismo cambio.
  • Investigación e implementación: un agente compara bibliotecas mientras otro edita código existente.
  • Distintos puntos fuertes: Claude Code y Codex vienen con modelos y herramientas distintos; probar ambos enfoques sobre el mismo problema puede llevarte antes a la solución. Para ver en qué se diferencian, consulta Claude Code vs Codex.

Tres reglas para repartir el trabajo

Que el trabajo en paralelo salga bien depende de cómo lo repartas.

1. Traza los límites de archivos de antemano

Dos agentes editando el mismo archivo es el fallo más común. Escribe en el rol de cada agente qué carpetas puede tocar. Por ejemplo, un agente trabaja solo bajo src/api/ y el otro solo bajo tests/.

2. Da a cada agente un objetivo

En lugar de «mejora el módulo de autenticación», da un objetivo medible como «mueve la gestión de sesiones a refresh tokens». Un objetivo claro permite que el agente pare pronto y hace fácil comprobar su salida.

3. Decide a dónde va la salida

Si el resultado de un agente alimenta a otro, diséñalo de antemano. ¿Escribirá un archivo de plan, hará commit o enviará su respuesta directamente al siguiente agente?

Evita conflictos de archivos con git worktrees

Cuando los límites de carpeta no bastan, la opción más robusta es un árbol de trabajo separado por agente. Los git worktrees abren carpetas separadas en ramas distintas del mismo repositorio:

git worktree add ../acme-web-auth -b auth-refactor
git worktree add ../acme-web-tests -b auth-tests

Cada agente trabaja en su propia carpeta y nunca toca los archivos del otro. Cuando terminan, fusionas las ramas con un pull request normal. Lo cuento con detalle en git worktrees para agentes en paralelo.

En AgentVera, los worktrees viven en el panel derecho: crea uno desde una rama nueva o existente, mira su número de cambios y cuánto va por delante o por detrás de la rama principal, e inicia un agente directamente en él.

Configuración de ejemplo: Claude Code escribe, Codex prueba

Un diseño inicial simple y eficaz:

AgenteHerramientaRolTrabaja en
ArquitectoClaude CodePlanifica e implementa la funciónworktree auth-refactor
TesterCodexEscribe tests de integración para el cambioEl mismo worktree, solo tests/
Servidor de desarrolloTerminalEjecuta pnpm devCarpeta principal

Pasos de configuración:

  1. Añade la carpeta del proyecto a AgentVera.
  2. En el diálogo «New agent», elige Claude Code, ponle el nombre «Architect» y escribe los límites de archivos en su rol.
  3. Haz lo mismo con Codex como «Tester».
  4. Inicia el servidor de desarrollo en un agente Terminal.
  5. Dale a Architect su tarea; cuando termine su turno, pasa su salida a Tester.

En vez de hacer el último paso a mano, crea un flow. Los flows envían la última respuesta de un agente a otro mediante una plantilla {{output}} y esperan a que el agente destino termine su turno si está ocupado.

Vigilar a los agentes en paralelo

A medida que crece el número de agentes, el trabajo real pasa a ser seguirlos. Fíjate en:

  • Estado: ¿qué agente está trabajando, cuál te espera, cuál tuvo un error?
  • Tamaño del contexto: las conversaciones largas cuestan más tokens en cada turno.
  • Solicitudes de aprobación: un agente que espera un permiso se detiene mientras los demás siguen.

El espacio de trabajo de AgentVera muestra los agentes uno junto a otro en una cuadrícula. Cada panel tiene su estado, el tamaño de contexto en vivo y un cuadro de mensaje. Los agentes que esperan aprobación aparecen en la barra de estado, y ⇧⌘A salta al que lleva más tiempo esperando.

Contexto y coste

Trabajar en paralelo también multiplica el uso de tokens. La primera petición de cada agente incluye definiciones de herramientas, el prompt de sistema y los plugins. En conversaciones largas esa base se vuelve a leer en cada turno.

Para mantener el coste bajo control:

  • Inicia los agentes para trabajos simples con un conjunto de herramientas más reducido.
  • Compacta las conversaciones largas con /compact.
  • Al pasar salida entre agentes, envía solo la parte necesaria.

Para ver cifras medidas, consulta reducir el uso de tokens de Claude Code.

Errores comunes

Dos agentes en un archivo. La solución más rápida es un worktree o un límite de carpeta estricto.

Tareas vagas. Las tareas abiertas como «arregla el código» hacen que el agente lea archivos sin fin e inflen el contexto.

Fusionar sin comprobar. Ejecuta los tests y revisa los diffs antes de fusionar lo que produjeron los agentes en paralelo. La revisión de código automática ahorra tiempo aquí.

Empezar con todo a la vez. Empieza con dos agentes y añade un tercero cuando el reparto funcione.

Un ejemplo completo: pasar a refresh tokens

Repartir el trabajo parece fácil sobre el papel; así se desarrolla en una tarea real. El objetivo: pasar la gestión de sesiones de una app web a access tokens de corta duración con refresh tokens rotativos.

Dividir la tarea

Primero, divide el trabajo en piezas independientes. Esta tarea tiene tres:

  • Lado servidor: emisión, validación y rotación de tokens (src/auth/).
  • Tests: tests de integración del nuevo flujo (tests/api/).
  • Documentación: reflejar los cambios de la API en el README.

El servidor y los tests miran el mismo comportamiento pero viven en carpetas distintas. La documentación solo tiene sentido cuando el lado servidor está asentado. Así que ejecuta los dos primeros en paralelo y el tercero después.

Instrucciones de rol

Mantén el rol de cada agente corto y estricto. Para Architect:

Work only under src/auth/. Don't change tests.
Run pnpm test auth after every change.
When you're done, summarize your changes as a bullet list.

Para Tester:

Work only under tests/. Don't touch application code.
Write integration tests for the behaviors in the summary you receive.

La última línea del rol de Architect importa: su resumen se convierte en la entrada de Tester a través del flow. Cuanto más ordenado el resumen, menos archivos tiene que leer Tester.

Traspaso y seguimiento

Cuando Architect termina su turno, el flow envía su última respuesta a Tester mediante una plantilla. Si Tester está ocupado, el flow espera a que termine su turno, y el límite de turnos de la conexión evita que los dos agentes entren en bucle para siempre. Mientras tanto puedes ver los logs del servidor de desarrollo en el agente terminal o hacer que un tercer agente prepare la documentación.

Cuándo no ir en paralelo

No todo trabajo se paraleliza. Quédate con un solo agente que trabaje paso a paso cuando:

  • El cambio se concentra en un archivo o en unos pocos muy acoplados.
  • La tarea aún no está clara; primero van la investigación y un plan.
  • La salida de un agente es condición previa del otro y el segundo trabajo es corto.

En esos casos funciona mejor un pipeline por etapas que el paralelismo. Lo explico en flujo de trabajo de agentes de IA.

Lista de comprobación

Antes de una sesión en paralelo:

  • ¿Está el objetivo de cada agente escrito en una frase?
  • ¿Están los límites de archivos en el rol?
  • Si hay riesgo de conflictos, ¿tiene cada agente su propio worktree?
  • Si la salida de un agente alimenta a otro, ¿está listo el flow o el archivo de plan?
  • ¿Hay un agente o terminal para ejecutar los tests?

Para terminar

Los agentes de código en paralelo ahorran tiempo real en trabajo que se reparte limpiamente. La clave es separar a los agentes y definir el traspaso entre ellos. Los worktrees separan archivos, los flows llevan la salida y unos roles bien escritos separan responsabilidades.

AgentVera está pensado para montar esto en una sola ventana: Claude Code, Codex y otros CLIs se ejecutan en paralelo con sus propios inicios de sesión. Puedes empezar con el plan gratuito y consultar los planes cuando necesites más.

Preguntas frecuentes

¿Pueden Claude Code y Codex trabajar en el mismo proyecto a la vez?

Sí. Cada uno se ejecuta en su propia sesión de terminal. La configuración más segura es repartir el trabajo por carpetas o dar a cada agente su propio git worktree para que nunca editen los mismos archivos.

¿Los agentes en paralelo necesitan cuentas distintas?

No. Cada CLI usa su propio inicio de sesión. Puedes abrir varios agentes con una misma cuenta; los límites de uso se consumen por cuenta.

¿Cuántos agentes debería ejecutar a la vez?

Tantos como puedas seguir. De dos a cuatro agentes es manejable en la mayoría de proyectos; a partir de ahí ayudan los flows y las notificaciones.

¿Pueden los agentes usar la salida de otros?

Con los flows de AgentVera, la última respuesta de un agente se envía a otro mediante una plantilla, así que no tienes que copiar y pegar a mano.

Reúne a tus agentes en un mismo escritorio.

Descarga AgentVera gratis; tus CLI instaladas ya están listas.

Más artículos