¿Cómo evitar que varios agentes de codificación se sobrescriban entre sí?
Ejecutar un agente de codificación de IA en un repositorio se siente como programación en pareja. Ejecutar tres o cinco agentes en el mismo repositorio puede parecer una fábrica de conflictos de fusión si todos comparten el mismo checkout. Un agente cambia de rama, otro edita el mismo archivo, un tercero ejecuta un comando de limpieza y, de repente, nadie sabe qué diff pertenece a qué tarea.
La solución no es un prompt más grande. La solución es un flujo de trabajo. Trato a los agentes como desarrolladores junior rápidos con acceso a la shell: útiles, pero necesitan límites.
La versión corta
- Use un Git worktree por agente.
- Use una rama por tarea.
- Asigne a cada agente un límite claro de propiedad de archivos o módulos.
- Coloque las reglas compartidas del repositorio en
AGENTS.md,CLAUDE.md, o ambos con un enlace simbólico. - Bloquee los comandos destructivos de Git a menos que un humano los apruebe.
- Combine a través de pull requests con CI y protección de ramas.
Eso es suficiente estructura para la mayoría del trabajo paralelo de agentes.
Por qué un checkout compartido falla
Un checkout de Git normal tiene un árbol de trabajo, un índice y una rama actual. Eso está bien para un desarrollador o un agente. Se vuelve complicado cuando varios agentes actúan al mismo tiempo.
Si el Agente A está a mitad de un refactor de autenticación y el Agente B ejecuta git checkout main, el espacio de trabajo del Agente A acaba de cambiar bajo sus pies. Si el Agente C ejecuta git reset --hard, el trabajo no confirmado puede desaparecer. Incluso comandos inofensivos como git stash pop pueden mezclar cambios no relacionados.
Puede decirles a los agentes que no hagan esas cosas, y debería hacerlo. Pero el aislamiento del sistema de archivos es más fuerte que la confianza.
Use Git worktrees para el aislamiento
Git worktrees permiten que un repositorio tenga múltiples directorios de trabajo adjuntos al mismo historial. Cada directorio puede estar en su propia rama, mientras comparte la misma base de datos de objetos. Evita el costo y la confusión de clonar el repositorio cinco veces, pero cada agente todavía obtiene sus propios archivos.
git fetch origin
git worktree add ../site-auth -b agent/auth-refactor origin/main
git worktree add ../site-billing -b agent/billing-fix origin/main
git worktree add ../site-tests -b agent/test-coverage origin/main
git worktree listLuego inicie un agente dentro de cada directorio. El Agente A trabaja en ../site-auth. El Agente B trabaja en ../site-billing. El Agente C trabaja en ../site-tests. Pueden ejecutar pruebas, editar archivos y crear commits sin cambiar el checkout de los demás.
Este es también el patrón que Claude Code documenta para sesiones paralelas: worktrees separados, ramas separadas y ediciones aisladas. Las guías de ayuda de Anthropic van más allá y describen las sesiones paralelas basadas en worktrees como un flujo de trabajo común para usuarios avanzados para ejecutar varias sesiones de Claude a la vez.
Asigne a cada agente una superficie de propiedad
Los worktrees resuelven colisiones a nivel de archivo. No resuelven conflictos a nivel de producto. Dos agentes aún pueden tomar decisiones incompatibles si la tarea es vaga.
Antes de iniciar agentes en paralelo, divido el trabajo por propiedad. No solo por nombres de archivo, sino por responsabilidad.
Usted es el propietario de src/auth/** y tests/auth/**.
No edite archivos fuera de ese alcance.
No cambie las formas de la API pública sin detenerse primero.
Ejecute las pruebas de autenticación antes de informar que ha terminado.
Abra una PR con un resumen enfocado.Ese prompt es aburrido, que es exactamente por lo que funciona. Los agentes necesitan límites aburridos más que prosa ingeniosa.
Las mejores divisiones son a lo largo de líneas de módulos naturales: autenticación, facturación, búsqueda, documentación, componentes de UI, migraciones, pruebas. La peor división es dar a dos agentes propiedad superpuesta del mismo servicio y esperar que Git lo resuelva más tarde.
Use AGENTS.md y CLAUDE.md como reglas compartidas
Las instrucciones del repositorio deben vivir en el repositorio, no solo en una ventana de chat. CLAUDE.md es la convención que lee Claude Code. AGENTS.md es una convención más general para agentes de codificación. Si usa ambas herramientas, mantenga una única fuente de verdad y enlace simbólicamente el otro nombre a ella.
ln -s CLAUDE.md AGENTS.mdEse archivo debe incluir los comandos de compilación del repositorio, los comandos de prueba, las notas de implementación, las reglas de estilo y cualquier restricción estricta. Por ejemplo: no edite archivos generados, no toque migraciones sin aprobación, use npm run lint antes de la entrega, o mantenga los bloques de código de blog en una sola línea HTML con etiquetas <br/>.
El punto es simple: cada agente debe comenzar con el mismo contexto local.
Haga explícitos los comandos peligrosos de Git
No permito que los agentes improvisen con Git destructivo. Estos comandos son útiles en una terminal controlada por humanos, pero arriesgados en trabajo autónomo:
git reset --hard
git checkout .
git clean -fd
git push --force
git stash popMi regla predeterminada es: leer libremente, escribir de forma limitada y preguntar antes de usar Git destructivo. Los agentes pueden ejecutar git status, git diff, git log y commits normales. No deben descartar trabajo, forzar push o mover otra rama a menos que la tarea lo requiera explícitamente.
Use pull requests como punto de entrega
No combine el trabajo del agente copiando archivos entre carpetas. Haga que cada agente produzca una rama y una pull request.
git status
git diff
npm test
git add src/auth tests/auth
git commit -m auth-refactor
git push origin agent/auth-refactor
gh pr createEn GitHub, las reglas de protección de ramas pueden requerir revisiones de pull request, comprobaciones de estado, historial lineal y colas de fusión. Esos controles importan más cuando los agentes pueden generar código rápidamente. La velocidad solo es útil si main sigue siendo confiable.
Me gustan las PR de agentes pequeñas. Un diff enfocado de 200 líneas es revisable. Un refactor mixto de 4.000 líneas es donde se esconden los errores.
Combine en orden de dependencia
Si el Agente A cambia una API y el Agente B consume esa API, combine A primero. Luego, haga rebase de B sobre la rama base actualizada y deje que B resuelva sus propios conflictos.
git fetch origin
git rebase origin/main
npm testEsto mantiene el modelo mental limpio. El agente que posee el trabajo dependiente es responsable de adaptarse a la nueva base. El revisor humano ve una PR coherente a la vez.
El flujo de trabajo que usaría mañana
- Actualice
main. - Cree un worktree y una rama por tarea del agente.
- Inicie cada agente dentro de su propio worktree.
- Asigne a cada agente un límite de propiedad escrito.
- Haga que cada agente ejecute las pruebas relevantes.
- Haga push de cada rama y abra una PR.
- Revise, combine en orden de dependencia, y luego elimine los worktrees terminados.
git worktree remove ../site-auth
git branch -d agent/auth-refactorMúltiples agentes de codificación pueden trabajar en la misma base de código. Simplemente no deberían trabajar en el mismo checkout. Use Git para el aislamiento, pull requests para la revisión y archivos de instrucciones a nivel de repositorio para reglas compartidas. Eso le da velocidad paralela sin convertir el repositorio en un montón de diffs misteriosos.