Hace unos meses el reto era hacer que un agente hiciera bien su trabajo. Hoy el reto es otro: tengo varias sesiones abiertas al mismo tiempo, sobre repos distintos, y ninguna me está esperando a mí.
Suena a presumir. No lo es. La primera vez que corrí tres agentes en paralelo sobre el mismo repositorio, dos colgaron trabajo distinto del mismo ticket y el merge se comió una de las dos versiones. Tuve que abrir dos tickets más solo para reparar lo que el paralelismo rompió.
Eso me obligó a aprender algo que no es técnico: dirigir agentes se parece más a dirigir personas que a programar.
Estas son las tres reglas que saqué de ahí.
1. Los agentes son una segunda bandeja de entrada, y esa sí puede esperar
Si abres cinco sesiones, tu cabeza te dice que tienes cinco cosas corriendo. Es falso. En cualquier momento dado, casi ninguna está trabajando: están esperando que apruebes un plan, que contestes una pregunta, o que les digas qué sigue.
Es una bandeja de entrada. Y la diferencia con la otra bandeja es la que importa:
Cuando dirigía un equipo de personas, contestaba primero a mi equipo. No por eficiencia — por respeto. Alguien bloqueado esperándome es alguien a quien le estoy quitando su día.
A un agente lo dejo esperando tres días sin sentir nada. No se frustra, no se desmotiva, no actualiza su currículum. Esa asimetría es justo lo que hace que el paralelismo funcione: puedes tener más frentes abiertos de los que podrías atender si fueran personas.
Y sí conviene tener varios abiertos, por dos razones que no controlas:
- Salen bugs y urgencias de cliente. No vas a cerrar el frente A antes de que aparezca el frente B. Aparecen encimados.
- Algunas ideas solo existen en el momento en que se te ocurren. Si no la arrancas cuando te llegó, no la arrancas nunca. Empezarla y dejarla esperando cuesta menos que perderla.
La trampa está en el siguiente punto.
2. Si el contexto vive en tu cabeza, el paralelismo te va a costar más de lo que te da
El cuello de botella de correr diez frentes no es la computadora. Eres tú acordándote de en qué iba cada uno.
Por eso la regla más barata y la que más rinde: el agente escribe el plan y el avance en archivos, desde temprano. No al final como documentación. Desde el principio, como memoria de trabajo.
En mi caso eso no es teoría, es lo que hay en disco ahora mismo:
- 246 planes en
docs/planes/, uno por trabajo no trivial, con objetivo, qué se hizo y qué falta verificar. - 11 logs de sesión con decisiones tomadas, lecciones aprendidas y pendientes para la siguiente.
- 11 handoffs, que son el archivo que una sesión le deja a otra para que retome sin releer la conversación.
- 68 skills, que son procedimientos escritos una vez y ejecutados muchas.
El efecto de escribirlo es doble y el segundo es el que no se ve venir:
Primero, tú dejas de cargarlo. Abres el archivo y en treinta segundos sabes dónde quedó.
Segundo, y más importante: cualquier agente puede retomar el trabajo de otro. El contexto dejó de estar amarrado a una sesión. Un agente puede pasarle el trabajo a otro sin que nadie te consulte. Ahí es donde deja de ser "tengo varias ventanas abiertas" y empieza a ser un equipo.
Un plan escrito no es burocracia. Es lo único que hace que el trabajo sobreviva a la sesión que lo empezó.
3. La coordinación no se pide, se hace físicamente imposible
Aquí está lo que casi nadie te dice, y lo que a mí me costó dos tickets de reparación.
Cuando varios agentes trabajan sobre lo mismo, la solución no es coordinarlos mejor. Les puedes escribir la instrucción más clara del mundo: "revisa antes de tocar", "no edites lo que otro está editando". No basta. Un agente que no puede ver lo que hace el otro no coordina — adivina.
La solución es estructural: que físicamente no puedan tocarse.
La regla que uso, y que dejé escrita como candado en mi sistema:
Un issue = una rama = un worktree = un agente.
Cada agente trabaja en su propia copia del repositorio, en su propia rama, con su propio ticket. Lo que hicieron se integra al final, de uno en uno. Ninguna de esas cuatro cosas se comparte nunca.
Y antes de que cualquier agente empiece, un paso que no se salta ni con prisa: revisar si alguien ya está en ese ticket. Ramas locales, ramas remotas, copias de trabajo abiertas. Si está ocupado, no se arranca: se avisa y se reparte distinto.
Dos detalles que parecen menores y no lo son:
El trabajo se reparte por archivos, no por temas. "Tú ve la parte de pagos y tú la de correo" suena a reparto limpio hasta que ambos necesitan tocar el mismo archivo de configuración. Reparte por lo que se toca, no por lo que se llama.
La limpieza es parte del trabajo, no el pendiente de después. Si no cierras y borras las copias de trabajo terminadas, la revisión de "¿está ocupado?" empieza a dar falsos positivos y en dos semanas nadie le hace caso. Un candado que da alarmas falsas es un candado apagado.
Lo que esto se parece de verdad
Cuando cada agente tiene su propio espacio de trabajo, su propio ticket, y deja su avance por escrito para que otro lo retome, la experiencia deja de parecerse a usar una herramienta.
Se parece a dirigir un equipo remoto. Con la diferencia de que este equipo no se ofende si tardas tres días en contestar.
Pero la parte que sigue siendo tuya es la misma que con personas: decidir qué se trabaja, en qué orden, y revisar lo que entregaron antes de darlo por bueno. El paralelismo multiplica la ejecución. No multiplica el criterio.
Si estás en el punto donde ya tienes un agente funcionando y estás pensando en abrir el segundo, el orden que yo seguiría es este: primero que escriba sus planes en archivos, luego el candado de que no se pisen, y hasta el final abrir más frentes. En el orden contrario, el paralelismo te cuesta más de lo que te da — te lo digo por los dos tickets que abrí para reparar lo que rompí.
¿Quieres montar esto en tu operación en vez de armarlo a prueba y error? Es exactamente lo que hago con mis clientes: dejar el proceso por escrito, ponerle candados donde se rompe, y que el sistema siga corriendo cuando cierras la laptop. Agenda una llamada y lo vemos sobre tu caso.
