Paralelo no significa pedir lo mismo a cinco agentes
Los flujos paralelos con Codex funcionan cuando cada agente posee una parte separada del problema. Fallan cuando todos editan los mismos archivos y entregan un conflicto de merge enorme.
La idea es dividir una función en workstreams seguros, ejecutar Codex en agentes VPS separados y recombinar solo después de pruebas y revisión. Office Claws lo hace práctico porque cada agente tiene su propio host, rama, terminal y escritorio visible en la app. Tú tomas las decisiones; los agentes hacen la espera, las pruebas y los cambios mecánicos.
La regla: divide por costuras, no por deseos
Un mal reparto:
- Agente A: implementar la función
- Agente B: escribir tests
- Agente C: actualizar docs
Parece paralelo, pero B no conoce la interfaz y C documentará algo que quizá cambie.
Un buen reparto sigue límites técnicos:
- Agente A: migración y capa de repositorio
- Agente B: ruta API y validación
- Agente C: estados de UI: vacío, carga y error
- Agente D: docs y nota de versión cuando la interfaz esté estable
Si dos agentes necesitan el mismo archivo, probablemente el reparto está mal.
Un flujo práctico de cuatro ramas
1. Escribe primero un contrato
Antes de lanzar agentes, deja un contrato pequeño en la rama principal: tipos, forma del endpoint, nombres de archivos y comando de test.
Endpoint: POST /api/runs/:id/retry
Request: { mode: "failed-only" | "all" }
Response: { runId: string, queuedTasks: number }
Tests: npm run test -- retry
No renombrar valores existentes de RunStatus.Es aburrido, pero separa paralelismo de caos.
2. Una rama por agente
Nombra las ramas por responsabilidad:
feat/retry-runs-apifeat/retry-runs-uifeat/retry-runs-testsdocs/retry-runs-release-note
En Office Claws, cada agente Codex trabaja en su propio VPS y rama. Los experimentos fallidos no contaminan el resto.
3. Prompts estrechos
Solo eres responsable de la ruta API y la validación para retry runs.
No edites archivos de UI. No renombres enums compartidos.
Antes de terminar, ejecuta: npm run test -- retry
Devuelve resumen, archivos cambiados y cualquier cambio de contrato necesario.Las prohibiciones evitan conflictos.
El orden de merge importa
Fusiona primero lo fundacional: datos, API, UI y documentación. Después de cada merge, rebasea las ramas restantes para que todos vean el contrato actual.
- Merge de repositorio/base de datos con tests verdes
- Rebase de API, corregir deriva, merge
- Rebase de UI y conexión al endpoint real
- Tests y docs al final
No esperes al final para fusionarlo todo. Eso crea una revisión gigante y oculta dónde cambió el diseño.
Cuándo merece la pena
El paralelismo ayuda cuando hay límites naturales:
- Backend + frontend + docs
- Migración + adaptador + tests
- Refactor de un paquete mientras otro agente actualiza llamadas
- Investigar tres posibles arreglos y conservar el mejor
- Portar el mismo patrón a integraciones independientes
Para un bug de 20 líneas, una sola sesión de Codex es más rápida.
Cómo encaja Office Claws
Puedes hacerlo con pestañas SSH y tmux. Lo difícil es recordar qué máquina, rama y terminal posee cada parte. Office Claws es ese plano de control: varios agentes Codex en VPS, visibles desde una app de escritorio.
Si vienes de OpenClaw, empieza con la comparación OpenClaw vs Codex. Si ya quieres agentes Codex alojados, la página de precios muestra las opciones self-hosted y managed.
Checklist
- ¿Hay un contrato escrito?
- ¿Cada agente posee archivos distintos?
- ¿Cada prompt dice qué está prohibido?
- ¿Hay un comando de validación por rama?
- ¿Conoces el orden de merge antes de empezar?
- ¿Una persona acepta o rechaza cambios del contrato?
Los flujos paralelos con Codex son potentes porque mantienen a los agentes enfocados. No se vuelven managers autónomos; dejan de esperarse entre sí mientras tú conservas la arquitectura.