Cinco agentes de programación con IA a la vez sin perder el control

El primer agente es una maravilla. Describes un cambio, se pone a trabajar, revisas el diff y haces commit. El segundo también va bien. Hacia el cuarto, algo se rompe en silencio, y no es el código. Eres tú.

El cuello de botella se ha movido, y nadie te lo dijo

Durante años, el límite de lo que podías entregar era la velocidad a la que podías escribir y pensar. Los agentes han movido ese límite. Ahora escribe el agente, y un solo desarrollador puede tener cinco cambios en marcha a la vez. El nuevo cuello de botella es tu atención: solo hay uno como tú y cinco cosas que cada cierto tiempo necesitan una decisión.

Y esto es lo que lo complica. Los agentes no siguen un horario. Uno termina en cuarenta segundos, otro se pasa seis minutos dándole vueltas, y un tercero se queda parado a los noventa segundos porque quiere permiso para ejecutar un comando. No puedes prever cuál te necesitará ni cuándo. Así que haces lo único que te deja un terminal: ir pestaña por pestaña, comprobando. Y comprobar es lo que sale caro.

El cambio de contexto es el impuesto

Cada vez que entras en una sesión para ver qué pasa, pagas el coste de cambiar de contexto. Tienes que recordar qué estaba haciendo ese agente, leer las últimas cien líneas de salida, averiguar si está bloqueado o solo pensando y decidir si intervienes. Haz eso en bucle con cinco sesiones y la mayor parte de tu día es el bucle, no el trabajo.

Empeora con los despistes silenciosos. Un agente termina y espera. Nada te avisa, así que se queda ahí con el trabajo hecho mientras tú estás tres pestañas más allá vigilando a uno que no necesitaba vigilancia. El coste no es dramático. Es una fuga constante: minutos de tiempo muerto en cada sesión, todo el día.

Comprobar no escala, recibir avisos sí

La solución es dejar de comprobar. No deberías ser tú quien mira; debería ser la herramienta la que avisa. Esa es la diferencia entre «voy pasando pestañas a ver quién me necesita» y «algo me llamará en cuanto alguien me necesite».

Para que eso funcione, algo tiene que conocer de verdad el estado de cada agente. Eso significa alojar la sesión lo bastante cerca para ver cuándo trabaja, cuándo está bloqueada y por qué. Una solicitud de permiso no es el mismo evento que una pregunta, un plan pendiente de aprobación o una tarea terminada, y quieres que te interrumpan de forma distinta en cada caso.

Lo que realmente te da una cuadrícula de estado

Reúne todo eso en una vista y el día cambia de forma. Cada sesión es una tarjeta con un estado: trabajando, te espera, inactiva, finalizada o detenida por un límite de uso. Las tarjetas se ordenan solas para que las que te esperan estén arriba. Echas un vistazo y ves dos sesiones trabajando, una inactiva y otra que dice que espera un permiso. Respondes a esa y dejas el resto en paz.

Donde la CLI del agente puede informar de su propio estado con hooks, ese estado es lo que el agente ha dicho de sí mismo, no una suposición. Donde no puede, leer la pantalla es el respaldo. La cuadrícula hace tres cosas que un montón de pestañas no puede:

• Te dice el estado sin hacer clic. Ves quién está bloqueado antes de decidir dónde mirar.

• Ordena por lo que te necesita. Lo que te espera, primero, para que la pantalla sea la cola.

• Te avisa en lugar de esperar a que compruebes. Una notificación en el momento en que algo se bloquea, para que el tiempo muerto deje de ser invisible.

La parte honesta

Una cuadrícula no hace más listos a los agentes ni correcto el código. Sigues teniendo que leer los diffs. Sigues teniendo que tomar las decisiones, y cinco agentes significan cinco veces más decisiones. Lo que elimina la cuadrícula es el trabajo que rodea esas decisiones: las comprobaciones y las sesiones terminadas de las que nadie te avisó. Las decisiones son el trabajo. Todo lo demás era impuesto.

Manejar bien cinco agentes no consiste en escribir más rápido. Consiste en dedicar tu atención solo donde de verdad hace falta, y nunca a averiguar dónde es eso.