Cómo Ejecutar de 3 a 8 Agentes de Codificación en Paralelo Sin Perder el Control

Ejecutar dos agentes a la vez te lleva cinco minutos. Abres dos terminales, asignas una tarea a cada uno y observas cómo el texto se desplaza.

El problema comienza con el cuarto.

Ya no sabes cuál está esperando una revisión, cuál terminó, cuál se estrelló hace diez minutos mientras mirabas a otro lado. Desplazas en la terminal equivocada. Vuelves a lanzar una tarea que ya estaba hecha. Después de una hora, estás haciendo el trabajo de tres agentes a mano solo para mantenerte orientado.

No es un problema de potencia. Es un problema de visibilidad.

El verdadero cuello de botella es tu cabeza

Un agente que codifica de manera autónoma entrega en ráfagas. Piensa durante 40 segundos, escribe, se detiene, espera tu aprobación. Durante esos 40 segundos puedes seguir a un segundo agente. Mientras el segundo escribe, apruebas al primero.

Hasta 3 agentes, tu cerebro sigue el ritmo. Más de 5, pierdes el hilo.

Anthropic publicó un número revelador en sus documentos: los intentos sin guía tienen éxito aproximadamente una vez de cada tres. La diferencia entre las personas que envían volumen y todos los demás no es el modelo. Es la estructura que establecen antes de comenzar.

Así que antes de escalar, estructuras.

Regla uno: un agente, un espacio de trabajo aislado

El error clásico es poner tres agentes en la misma copia del repositorio. Se pisan entre ellos. Uno edita package.json, otro también, y terminas con una fusión que no puedes desenredar.

La solución son dos palabras: git worktree.

git worktree add ../project-auth feature/auth
git worktree add ../project-billing feature/billing
git worktree add ../project-export feature/export

Cada agente trabaja en su propia carpeta, en su propia rama, con sus propios archivos. Cero colisiones. Revisas cada rama por separado y fusionas cuando esté lista.

Esta es la base de lo que los investigadores llaman delegación aislada: un gerente central divide el trabajo, cada subtarea se ejecuta en su propio rincón, y la integración ocurre después, con pruebas para validar.

Regla dos: nunca entregues el mismo archivo central dos veces

Antes de dividir el trabajo, encuentra los archivos que varias funciones necesitarán tocar. El enrutador. El esquema de la base de datos. La configuración de la ruta API.

Esos archivos reciben exactamente un agente. Los demás esperan o trabajan alrededor de ellos.

Entrega el mismo routes.ts a dos agentes en paralelo y pagarás en conflictos de fusión lo que pensabas ganar en paralelismo. Ese intercambio siempre se pierde.

Regla tres: un tablero, no diez terminales

Aquí es donde la mayoría de las personas abandonan el multi-agente. Abren ocho pestañas de terminal, pierden el hilo y vuelven arrastrándose a un solo agente.

Necesitas una vista que responda tres preguntas de un vistazo:

• ¿Quién está codificando ahora mismo?
• ¿Quién está esperando mi revisión?
• ¿Quién terminó o se estrelló?

Sin esa vista, el multi-agente te cuesta más en carga mental de lo que te da en velocidad. Con ella, puedes manejar genuinamente de 6 a 8 flujos de trabajo a la vez.

Ese es el vacío exacto que llena AgentsRoom. Cada agente obtiene su propio recuadro, su estado, su color. Un agente esperando tu respuesta se vuelve rojo y te avisa. Dejas de desplazarte en la terminal equivocada, miras el tablero y sabes a dónde ir.

La cadencia que funciona en la práctica

Aquí está el ritmo con el que comenzaría.

Empieza con dos agentes, en dos funciones que no comparten archivos. Acostúmbrate al ciclo de revisar y luego fusionar. Ese ciclo, no el código, se convierte en tu verdadero trabajo.

Una vez que ese ciclo se sienta fluido, pasa a cuatro. Mantén una lista de prioridades estricta de tareas de alto impacto y apóyate mucho en el modo plan: apruebas el plan del agente antes de que escriba una línea. Un plan aprobado de antemano te ahorra una revisión dolorosa más tarde.

El punto óptimo se encuentra entre 3 y 8 funciones en el mismo repositorio, con supervisión visual. Más allá de eso, incluso con un buen tablero, la revisión se convierte en el cuello de botella y pierdes el beneficio.

Lo que realmente ganas

El multi-agente es inútil para el 95% de las tareas pequeñas. Para corregir un error tipográfico o agregar un botón, un solo agente es suficiente, y es más rápido.

Donde cambia tu semana es en el trabajo grande. Inicias tres refactorizaciones independientes una noche, las revisas a medida que llegan, y a la mañana siguiente tienes tres días de trabajo listos para fusionar.

El secreto no es el número de agentes. Es siempre saber cuál te necesita, ahora mismo. Soluciona eso, y lo demás sigue.