English

Deja de mirar a un solo agente Codex trabajar

Mirar a un solo agente de IA trabajar es como pagar por cinco empleados y darle escritorio a uno solo. Si ejecutas una única sesión de Codex a la vez, estás poniendo en fila un trabajo que podría correr en paralelo. git worktree hace checkout de una rama en su propia carpeta — mismo repositorio, directorio de trabajo separado — para que puedas apuntar un agente Codex distinto a cada una sin que se pisen los archivos entre sí.

El problema de una carpeta, un agente

Un checkout normal de git te da un único directorio de trabajo atado a una sola rama a la vez. Cambia de rama y cada archivo en disco cambia con ella. Eso se rompe en el momento en que quieres dos agentes de IA trabajando simultáneamente sobre el mismo repositorio — ambos estarían editando archivos en disco en la rama que esté activa, colisionando constantemente. Clonar el repositorio otra vez funciona, pero duplica todo el historial de .git y las dependencias por cada sesión paralela — un desperdicio, y fácil de dejar que se desincronice.

Qué es realmente un worktree

Un worktree de git es un segundo directorio de trabajo enlazado al mismo repositorio. Tu carpeta original se queda exactamente donde está, en la rama en la que estaba — intacta. El nuevo worktree es una carpeta nueva, con checkout a una rama nueva (o existente), que comparte por debajo el mismo almacén de objetos .git. Obtienes árboles de archivos aislados sin duplicar el historial ni el almacenamiento del repositorio.

Cómo crear uno

Un solo comando crea un worktree, una carpeta nueva y una rama nueva a la vez:

git worktree add ../feature-x feature-x

Esto hace checkout de una rama nueva feature-x en una carpeta hermana ../feature-x. Tu carpeta original queda intacta y se mantiene en main. Ejecútalo de nuevo con otra ruta y otro nombre de rama para tener una tercera carpeta, un tercer espacio aislado, todos apuntando al mismo historial del repositorio.

Ejecutar Codex en paralelo

1. Abre una terminal en la carpeta del nuevo worktree.
2. Inicializa/arranca Codex ahí y dale la funcionalidad en la que va a trabajar.
3. Repite para una segunda carpeta, una tercera, tantas como funcionalidades tengas en curso.

Cada sesión de Codex opera enteramente dentro de su propio worktree — leyendo y escribiendo archivos en esa carpeta, corriendo sus propias pruebas, haciendo commit en su propia rama — con cero riesgo de tocar un archivo que otro agente está editando en ese momento, ya que no comparten directorio. Ahora estás ejecutando agentes en paralelo en lugar de ponerlos en fila uno tras otro. Esto también está soportado directamente en las herramientas de Codex: la app de escritorio ofrece una opción de "entregar a un worktree" (hand off to a worktree) para que los agentes no se sobrescriban los archivos.

Limpieza después de una fusión

git worktree remove ../feature-x
git branch -d feature-x

Eliminar primero el worktree libera el directorio de trabajo enlazado; borrar la rama después es entonces una operación normal y segura. Saltarte el paso de eliminación deja una carpeta obsoleta apuntando a una rama que ya no necesita existir — desorden que se acumula rápido ejecutando varios agentes por semana.

Cuándo vale la pena hacer esto

• Cambios de front-end y back-end que aterrizan juntos — un worktree por lado, dos agentes trabajando en sincronía.
• Varias funcionalidades pequeñas e independientes a la vez — un worktree por funcionalidad mantiene el contexto de cada agente acotado a una pieza de trabajo, produciendo diffs más limpios que un solo agente haciendo malabares con múltiples cambios sin relación.
• Revisar trabajo terminado en lugar de cuidar a un agente — tu labor cambia de mirar a un agente teclear a revisar periódicamente a varios.

Errores comunes

• Olvidar eliminar los worktrees después de fusionar. No se limpian solos.
• Dividir las funcionalidades en piezas demasiado grandes. Los agentes en paralelo solo son manejables si cada pieza se termina y revisa en una ventana razonable — cinco worktrees sobre cinco funcionalidades enormes siguen siendo cinco cosas que no puedes seguir.
• Suponer que los worktrees también aíslan las dependencias. Aíslan el árbol de archivos y la rama, no los paquetes instalados ni el estado del entorno — configúralos por worktree.

Recursos

• git-scm.com — referencia de git worktree