Agentes de codificación paralela con worktrees de Git, Conductor y Antigravity 2.0

De manejar terminales a un sistema visual

Si 2025 fue el año del agente de IA, 2026 parece ser el año en que muchos agentes trabajarán juntos, y un ingeniero de Google predijo desde temprano que este sería el año de la orquestación de agentes. Los problemas surgen rápidamente para quienes viven exclusivamente en terminales. Intentar coordinar a un equipo de subagentes en paralelo para crear un pequeño juego de relojes, utilizando paneles tmux, descargas de repositorios y notas adhesivas en la pantalla para recordar qué tarea estaba realizando cada uno, se convirtió en un verdadero desastre cognitivo.

La foto muestra varios escritorios de macOS repletos de terminales agy con notas adhesivas, una buena imagen de cómo se ve la gestión de espacios de trabajo de agentes en paralelo sin las herramientas adecuadas.

La idea de crear aplicaciones con un sistema de múltiples agentes surgió de una publicación de junio de 2026 que mostraba cómo una sola instrucción generaba cuatro agentes de desarrollo en paralelo y producía una aplicación funcional en menos de dos minutos. Los asistentes de línea de comandos especializados son ideales para tareas de un solo hilo, pero varios flujos de agentes concurrentes, cada uno con su propia rama, mecanismo de verificación y bucle de retroalimentación del coordinador, no caben en un buffer de desplazamiento plano. Por eso, el siguiente paso fue pasar a la aplicación de escritorio Antigravity 2.0.

La aplicación agrupa todo por proyecto, básicamente como una carpeta, y muestra los hilos bajo cada uno, del más reciente al más antiguo. Un proyecto personal podría contener un hilo para agregar un botón de inicio de sesión azul con una contraseña oculta y otro para añadir una ruta de backend /checkout/, mientras que un proyecto laboral incluye hilos para escribir doc/PRD.md y agregar pruebas de seguridad. Los hilos pueden archivarse, por lo que sobreviven a un reinicio, y ya nadie necesita notas adhesivas físicas.

Una vez que funciona el entorno visual, la siguiente pregunta es la escalabilidad. Un entorno de pruebas aislado y un juego sencillo son fáciles de manejar. Esta configuración permite ampliar la aplicación de escritorio a una simulación SRE de 12 pistas, utilizando worktrees de Git, un orquestador de estilo Rails llamado Conductor++ y un agente de asistencia llamado Agostina.

La ilustración muestra a un desarrollador intentando controlar un montón de subagentes de worktree, con un panettone en la mano.

La idea que lo desató

La inspiración provino de una instrucción concisa para desarrollar una aplicación de reservas de habitaciones de hotel con un pequeño equipo de agentes.

Let's build a hotel room booking app [..].

First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.

Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS>  to interact with the API <details>.

[..] How to sync the 3 sub-agents [..]

Finally, spin up both components and a browser so I can test the live app.

Al leerlo con atención se puede ver su contenido:

1. una descripción del producto deseado, en este caso una aplicación para reservas de hoteles
2. un equipo formado por tres subagentes
3. el orden y el momento de su interacción
4. lo que ocurre al final, cuando el sistema se pone en marcha para que una persona que no está directamente involucrada lo revise
5. lo que más importa: un estado de archivo compartido, el archivo común architecture.md

El diagrama muestra cómo interactúan los agentes en ese ejemplo. Se trata de programación meta en su forma más pura. La instrucción no describe el código, sino el equipo que lo escribirá. Además, los agentes se comunican entre sí a través de un archivo en Markdown, lo que significa que las especificaciones mismas son el canal de comunicación.

La lista de deseos para una configuración paralela fue aún más allá: la implementación se activa mediante GitHub Issues (GHI), de modo que cada subagente recibe un ticket real.

Componentes del flujo de trabajo

Varios elementos componen esta configuración.

• Integración de issues. Cada subagente debe trabajar en un issue cuando existe alguno.
• Rails para IA. La extensión Conductor proporciona a las tareas de los agentes ciertos “rieles”, es decir, límites definidos. Un issue por sí solo no siempre contiene suficiente información para que un agente actúe, y a veces es necesario que una persona interviniente (HITL) responda a las preguntas difíciles, lo que evita que las implementaciones sean descuidadas, como cuando alguien dice “por supuesto, me refería solo a usuarios autenticados”.
• git worktree. Los worktrees impiden que dos o más agentes dañen el mismo repositorio. Con N agentes abriendo solicitudes de pull en ramas remotas, también tiene sentido contar con un “conserje” de Git que resuelva el código para integrarlo en la rama principal. Esa función debe ser cautelosa. Mientras el agente X intenta publicar la función X, el conserje permanece imperturbable, siendo la última línea de defensa para mantener la consistencia, ya que el código puede estar en orden pero publicarse sin ejecutar pruebas ni actualizar el registro de cambios, y una ventana de contexto actualizada ayuda a detectar eso.

Para reutilizar todo este sistema en diferentes bases de código, las reglas y la automatización se integraron en una habilidad de agente de código abierto, conductor-worktree-hitl, apodada condutree. Sus componentes principales son:

• git worktree para la implementación asíncrona, con un subagente por worktree y una pista de Conductor
• GitHub Issues junto con Conductor para establecer límites claros en la implementación
• Antigravity 2.0 como herramienta visual de gestión
• El estado se guarda en disco, de modo que el contexto del agente se mantiene entre ejecuciones; es compatible con Conductor, pero añade un estado basado en archivos para vincular problemas y un marco experimental de preguntas y respuestas para subagentes
• Opcionalmente, un complemento que proporciona la habilidad using-git-worktrees para automatizar el aislamiento de worktrees

Existen tres razones para presentarlo como una habilidad externa, en lugar de pegar comandos de git en el prompt del coordinador. Primero, reúne toda la configuración de nivel bajo del espacio de trabajo, los enlaces simbólicos y las exclusiones de git en un único script mantenible. Segundo, el prompt del coordinador se mantiene breve y se centra en delegar tareas de los agentes principales a los subagentes y resolver dudas, de modo que el agente no tiene que lidiar con la sintaxis de git. Tercero, otros desarrolladores pueden incorporar esta habilidad en sus propios repositorios y herramientas, y ejecutar tareas en paralelo sin conflictos, sin necesidad de reescribir los scripts de integración.

Un agente equipado con esta habilidad aprende cuatro cosas:

1. cómo obtener árboles de trabajo independientes para tareas concurrentes
2. las buenas prácticas de git, es decir, crear enlaces simbólicos a las carpetas de metadatos compartidas de Conductor y excluirlas localmente para que git status se mantenga limpio
3. un protocolo dual reentrante HITL para publicar comentarios sobre problemas, leer registros locales y consultar respuestas sin agotar la cuota de la API
4. cómo realizar commits localmente y registrar las aprobaciones como notas de Git, sin realizar envíos directos a remoto

La versión 1.0 constituye una base sólida, y está prevista una versión 2.0 con enlaces simbólicos de configuración automática y scripts auxiliares más completos.

Esta ilustración generada por IA juega con la expresión “demasiados cocineros en la cocina”: una multitud de subagentes de programación que causan desorden en una rama al no haber aislamiento del árbol de trabajo.

Prueba de estrés: un simulador de incidentes SRE

Para determinar hasta qué punto se puede llevar la ejecución paralela, el modelo se aplicó a un simulador realista de automatización SRE y de comando en incidentes. El objetivo no eran aplicaciones simples, sino un sistema multiagente que audita entornos en la nube y coordina la gestión de incidentes en varios espacios de trabajo aislados al mismo tiempo. Antes de que funcionara sin conflictos, fue necesario resolver algunos problemas relacionados con la organización de los archivos y la nomenclatura en Git.

• Contaminación por enlaces simbólicos. En la configuración de Conductor++, cada agente paralelo cuenta con su propio árbol de trabajo, por ejemplo .worktrees/telegram_incident_creation/. Dado que los subagentes envían metadatos al coordinador, el directorio raíz conductor/ se enlaza simbólicamente a cada árbol de trabajo mediante ln -s ../../conductor conductor. Todo, excepto esa carpeta, difiere según el árbol de trabajo, y como cada traza se encuentra en su propia subcarpeta de conductor, es muy poco probable que surjan problemas al fusionarlas.
• La coordinadora. La principal encargada se llama Agostina, una italiana tranquila y organizada que funciona como un motor impulsado por espresso; mantiene sincronizados a subagentes como Mario y Luigi sin que interfieran entre sí. Elige ser italiana a propósito, y su nombre suena un poco como Antigravity.
• El escriba. Un agente dedicado llamado Amanuense, tomado de la palabra latina para designar a un escriba, registra la creación de directorios, los cambios en el código y las interacciones entre agentes con fechas y horas exactas en un archivo de auditoría central, de modo que se pueda ver quién hizo qué, cuándo y en qué árbol de trabajo. Fue creado para verificar el funcionamiento de la sincronización entre subagentes y para proporcionar fechas y registros precisos para los informes.

Ejecutar varios agentes de IA en un mismo repositorio exige un aislamiento estricto además de una forma de comunicación libre de conflictos.

Aquí Agostina resuelve las fusiones realizadas por Mario y Luigi, mientras que un tercer subagente amarillo sigue trabajando en su propio árbol de tareas.

Reglas que mantienen el repositorio ordenado

Varias decisiones de diseño tuvieron un impacto decisivo.

• Ningún push directo desde la nube. Si muchos subagentes ejecutan git push al mismo tiempo, provocan colisiones de bloqueos en las referencias remotas y pueden introducir código sin probar en producción. Los subagentes solo realizan commits en las ramas locales feature/ y escriben notas resumidas en Git. Solo el coordinador puede hacer pushes, obtener la rama de validación y fusionar las ramas de características.
• Protocolo de preguntas dual reentrante. Un único archivo global questions.json generaría competencias por escritura cuando los subagentes hicieran preguntas de forma concurrente. En su lugar, cada subagente escribe su pregunta en su carpeta de seguimiento privada (conductor/tracks//metadata.json), lo que evita por completo dichas competencias. También publica la pregunta como comentario en un issue de GitHub, incluyendo una firma de seguimiento única. El script de sondeo de Agostina primero verifica si alguna carpeta local tiene el estado awaiting_human. Si no hay ninguna, se omite por completo la llamada a la API de GitHub, lo que permite ahorrar más del 95 por ciento de la cuota asignada. Cuando aparece una respuesta correspondiente en GitHub, el metadato local cambia a answered, lo que activa al subagente.
• Una memoria compartida al estilo wiki. En lugar de llenar el contexto de cada subagente con toda la historia del proyecto, el directorio compartido conductor/ funciona como memoria persistente: un directorio local estructurado que los agentes leen y escriben como si fuera una página de wiki. Esto refleja una idea bien conocida sobre la memoria de los LLM de Andrej Karpathy, y aborda la preocupación común de que una memoria de los agentes mal gestionada convierta a los asistentes en peces dorados.
• Resolución en cascada de conflictos. Cuando las ramas de funcionalidades completadas se fusionan una por una, puede producirse una cascada. La rama de Mario se fusiona sin problemas en la rama de validación, pero la de Luigi genera conflictos. Si una persona soluciona el conflicto de Luigi en la rama de validación, la rama original de funcionalidades de Luigi en su árbol de trabajo sigue teniendo conflictos y está desactualizada. Para evitar ese desfase, Agostina selecciona manualmente las soluciones o las fusiona de vuelta en la rama de Luigi, manteniendo el árbol de trabajo aislado alineado con el código validado.
• Se utilizan solicitudes de pull en lugar de hacer push a main. Al hacer push directamente de la rama de validación fusionada a main se omitirían las etapas de revisión, por lo que la integración se realiza a través de una PR. Los subagentes realizan commits localmente, Agostina hace pull, valida y fusiona localmente, y una vez que las pruebas de integración pasan, ella hace push de la rama unificada y ejecuta gh pr create --title "feat: ..." --body "...". Un revisor humano puede entonces examinar las diferencias y las verificaciones de CI en la propia interfaz de GitHub. Agostina registra la URL de la PR en metadata.json del registro y muestra el estado en tiempo real mediante gh pr list y gh pr status.
• Terminación por conflictos conceptuales. Dos rutas pueden ser lógicamente incompatibles, como cuando una implementa una función que la otra refactorea de manera incompatible. Si Agostina detecta esto, puede terminar de inmediato a uno de los subagentes en conflicto. La cancelación debe registrarse en el problema correspondiente a ese agente, y dicho problema debe bloquearse o vincularse al problema del otro agente para mantener un registro claro de las decisiones. Esto ha ocurrido exactamente una vez.

El ciclo de vida de la orquestación

El operador humano nunca habla directamente con los subagentes. Estos funcionan en total aislamiento dentro de sus árboles de trabajo, y la persona solo se comunica con el coordinador en dos momentos: al iniciar la ejecución y al responder a las preguntas transmitidas por el observador HITL.

El diagrama de flujo muestra el ciclo de vida del agente y los subagentes en seis pasos:

1. Inicio. El operador inicia la ejecución.
2. Estado de lectura. Agostina audita los problemas activos en GitHub y los estados de las pistas en Conductor.
3. Provisión. Ella crea árboles de trabajo aislados y genera subagentes de desarrolladores en paralelo.
4. Observador de HITL. Las preguntas bloqueadas por los subagentes se envían al humano y las respuestas se devuelven, manteniendo el ciclo de retroalimentación seguro y asíncrono.
5. Limpieza. Cuando los subagentes terminan y abren sus PR, Agostina elimina los directorios temporales de los árboles de trabajo.
6. Fusión con la rama principal. Ella integra los cambios y abre o fusiona el PR final, volviendo al paso de limpieza para cualquier tarea restante. Puede convertirse en un verdadero caos, pero los agentes manejan las fusiones de Git mejor que las personas.

Responder preguntas sigue siendo algo muy experimental, y se probaron tres enfoques. Uno consiste en un puente tipo sidecar de Telegram que funciona como un demonio en segundo plano, envía las preguntas o las aprobaciones de modificación de la base de datos al teléfono del desarrollador a través de un bot de Telegram y consulta por respuestas.

El diagrama muestra ese flujo asíncrono de Telegram. Sus ventajas son la posibilidad de responder y aprobar desde dispositivos móviles en primer lugar, un paralelismo sin conflictos ya que las preguntas se almacenan en directorios por cada trayecto, lo que evita disputas por el bloqueo de archivos, y un registro de auditoría, ya que cada decisión se guarda en el repositorio en formato JSON. El enfoque más simple, que consistía en comunicarse con el agente principal a través de questions.json, fue descartado porque nunca liberaba el bloqueo automáticamente y tenía que activarse manualmente, aunque los ganchos o futuras versiones podrían solucionar eso.

Estudio de caso: doce trayectos SRE en cinco horas

El entorno de pruebas era una aplicación web desarrollada sobre la base de una extensión SRE. Gran parte de sus funciones podía ejecutarse en paralelo: pantallas de interfaz de usuario, puntos finales del backend, un asistente de chat respaldado por un LLM, un bot de Telegram, instrumentación con OpenTelemetry y detección de recursos de GCP.

El proceso involucró doce capacidades complejas de SRE, que se dividieron en más de veinte problemas concretos en GitHub. Luego se puso en marcha la máquina. En aproximadamente cinco horas, en su mayor parte sin supervisión, el pipeline Conductor++ las construyó, probó y fusionó todas ellas en la rama principal. El alcance abarcó desde la configuración del seguimiento con OpenTelemetry en Cloud Run hasta la creación de asistentes interactivos de Telegram para incidentes y registros para aprobar mutaciones pendientes.

Resultados de integración y fusión

Bajo la orquestación del árbol de trabajo en paralelo, cada traza de funcionalidad se desarrolló, probó e integró en main.

La imagen de la tabla muestra la auditoría del estado final de las pistas principales. También se integraron ocho pistas operativas adicionales, que abarcan la taxonomía de estado de los incidentes, la eliminación y archivado de incidentes, el enlace cruzado entre proyectos wiki, la gestión del estado en múltiples entornos, la migración del estado a la nube, una interfaz de usuario responsive para wiki, conectores en tiempo real con GCP y mutaciones pendientes.

Dos semanas después de la ejecución, se puede verificar el estado de Conductor con una sola orden de task-runner que inicia al inspector sobre el repositorio e imprime un resumen del espacio de trabajo.

$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short

🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS      |  PROGRESS  | RATIO |  GHI  |   AGENT    |   CHANGED   | TRACK ID                                           |  🌳
==============================================================================================================================
NEW         | ░░░░░░░░░░ |  0/25 |  #23  |            |  💻 15days   | managed_agents_sandbox_20260616                    |
NOT_READY   | ░░░░░░░░░░ |  0/17 |  #22  |            |  💻 15days   | mcp_streamline_abilities_20260616                  |
NOT_READY   | ░░░░░░░░░░ |  0/11 |  #15  |            |  💻 15days   | migrate_tf_cb_logic_20260616                       |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #21  |            |  💻 15days   | ai_engineering_practices_20260616                  |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #19  |            |  💻 15days   | workspace_agent_installation_20260616              |
NEW         | ░░░░░░░░░░ |  0/15 |  #31  | antigravity|  🐙 16days   | disable_mock_fallback_dev_20260616                 |
==============================================================================================================================
TOTAL       |            |  0/86 |       |            |              | 0 completed, 6 open (6 total)                      | 0 🌳

La línea de tiempo del flujo de trabajo

Un análisis paso a paso de la ejecución muestra cómo el coordinador, el escriba y los subagentes paralelos evitaron interferirse entre sí.

Paso 1: inicialización de pistas y árboles de trabajo

En la máquina anfitriona, el coordinador principal preparó los espacios de trabajo. A continuación, la CLI del inspector Conductor enumeró las pistas activas y las asignó a subagentes designados: uno se encargó de las salas de guerra de Discord y otro de las mutaciones pendientes. Una bandera que incluye todas las pistas permite que la misma herramienta muestre las ramas y los estados de los agentes para cada espacio de trabajo paralelo.

./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all

A continuación se muestra la salida del terminal capturada durante la inicialización.

================================================================================
  CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
  Worktree: .worktrees/issue-29-telegram-wizard
  Branch:   feature/issue-29
  Agent:    pinocchio
  Status:   AWAITING_HUMAN (Question: "Verify Telegram Token config?")
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/29

[Track: unified_incident_lifecycle_observability_20260607]
  Worktree: .worktrees/issue-18-discord-warrooms
  Branch:   feature/issue-18
  Agent:    grazia
  Status:   RUNNING
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================

En esa lista, el subagente encargado de las mutaciones pendientes está bloqueado, a la espera de una respuesta de HITL.

Una pregunta lógica es si los problemas de GitHub y las pistas de Conductor son lo mismo. Se trata de dos sistemas que pueden desviarse entre sí. Se pidió a un agente que detectara dichas desviaciones.

La captura de pantalla muestra un resumen del inspector sobre los árboles de trabajo activos, las ramas y las asignaciones de subagentes. Armonizar ambos sistemas requiere una sola instrucción en cualquiera de las direcciones: una opción pide a Conductor que cree una nueva pista para cada problema, haciendo todas las preguntas necesarias una por una; la otra se asegura de que exista un problema para cada pista de Conductor.

La vista detallada muestra una pregunta pendiente de HITL que aguarda información en GitHub Issues.

Paso 2: aislamiento de árboles de trabajo en paralelo

Cada agente trabajó en su propia rama, y el escriba registró las ediciones exactas de los archivos y los eventos del espacio de trabajo sin conflictos.

Esta captura muestra el monitor de archivos del worktree durante el desarrollo concurrente.

El rastreador de hilos Antigravity muestra las tareas en curso, una visualización que habría impresionado a la demo original de una sola instrucción con cuatro subagentes.

Paso 3: sondeo y dirección humana

Cuando los agentes necesitaban aclaraciones, publicaban problemas que un script de sondeo, poll_ghi_questions.py, analizaba. Para que la dirección humana fuera compatible con dispositivos móviles, las preguntas pasaban por el puente Telegram sidecar. El operador no tenía que quedarse frente a una computadora actualizando GitHub, ya que el puente enviaba cada pregunta a un teléfono para obtener aprobaciones rápidas mientras se desplazaba.

La captura de pantalla muestra en acción el ciclo de retroalimentación de aprobaciones y diagnósticos.

Paso 4: el estado final verde

Después de que cada rama de características superara la validación y se fusionara en secuencia, Agostina abrió la solicitud de pull request, y la auditoría final confirmó que las doce rutas SRE se habían integrado en la rama de producción. ¿Estaban todas perfectamente probadas, incluyendo su forma de interactuar? No del todo, y eso es un tema para trabajos futuros. Una herramienta de visualización llamada Conductor At Scale también convierte un historial git genérico en una animación al estilo arcade, con las rutas de Conductor explotando en la pantalla mediante JavaScript.

Lecciones de la ejecución

La primera lección es mantener la conversación con un único agente siempre que sea posible y asignar a los subagentes únicamente tareas simples y predeterminadas que no requieran interacción. Dos prácticas respaldan esto.

• Minimizar el tiempo de espera entre el agente y el humano. Un comando /roastme es una buena forma de plantear las preguntas difíciles desde el principio para que el agente pueda funcionar sin interrupciones, y Conductor es eficaz para recopilar preguntas de forma offline. En lugar de hacer una pregunta cada 30 segundos cada cinco minutos, se responde todo en un bloque de 30 minutos, se va en bicicleta y se vuelve con la aplicación terminada.

Esa captura de pantalla muestra /roastme en ejecución dentro de Conductor, incluyendo errores de escritura.

• Mantener una relación sencilla entre el agente y los subagentes. En el sector se habla de jerarquías complejas con múltiples agentes, pero en 2026 la opción más segura son tareas simples y repetibles que requieran mucha implementación pero poca ambigüedad, lo que evita una sobrecarga innecesaria en la orquestación.

También existe un impuesto por la orquestación. Esbaratar código es barato; lo importante es la especificación, y las pruebas y la aceptación de los resultados son el nuevo cuello de botella. Otros en el campo parecen estar de acuerdo. Los equipos pueden adelantarse a esta tendencia o quedar abrumados por ella.

Para quienes deseen probar este enfoque, el punto de partida es la aplicación de escritorio Antigravity 2.0, que ofrece orquestación multi-pista visual lista para usar desde el primer momento.