Cómo ejecutar 3 a 8 agentes de codificación en paralelo sin perder pista

Correr dos agentes a la vez te lleva cinco minutos. Abres dos terminales, entregas cada uno una una tarea, y observas el desplazamiento de texto.

El problema comienza en el cuarto.

Ya no sabes cuál es la espera de una revisión, que uno terminó, que uno se estrelló hace diez minutos mientras estabas buscando en otro lugar. Te desplazas en el terminal equivocado. Relanzar una tarea que ya se hizo. Una hora adentro, estás haciendo el trabajo de tres agentes a mano sólo para mantener tus rodamientos.

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

El verdadero cuello de botella es tu cabeza

Un agente de codificación entrega autónomamente en ráfagas. Piensa por 40 segundos, escribe, para, espera tu señal. Durante esos 40 segundos puedes seguir a un segundo agente. Mientras el segundo escribe, apruebas el primero.

Hasta 3 agentes, tu cerebro se mantiene despierto. Pasado 5, baja el hilo.

Antrópico publicó un número contable en sus docs: los intentos sin guía tienen éxito una vez en tres. La brecha entre las personas que envían volumen y todos los demás no es el modelo. Es la estructura que pusieron antes de lanzar.

Así que antes de escalar, estructura.

Regla uno: un agente, un espacio de trabajo aislado

El error clásico es poner tres agentes en la misma copia del repo. Se dan el uno al otro. Uno edita package.json, así que hace otro, y terminas con una fusión que no puedes desenredar.

La solución es 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. Revisa cada rama por separado y fusiona cuando está listo.

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

Regla dos: nunca entregar el mismo archivo central dos veces

Antes de dividir el trabajo, encontrar los archivos varias características necesitarán tocar. El router. El esquema de bases de datos. La ruta API config.

Esos archivos tienen exactamente un agente. Los otros esperan o trabajan a su alrededor.

Entrega el mismo routes.ts a dos agentes paralelos y pagarás en conflictos de fusión lo que crees que ganarías en el paralelismo. Ese comercio pierde cada vez.

Regla tres: una tabla, no diez terminales

Aquí es donde la mayoría de la gente deja de ser multiagente. Abren ocho pestañas terminales, pierden el hilo y se arrastran de nuevo a un solo agente.

Necesitas una vista que responda a tres preguntas de un vistazo:

• ¿Quién está en codificación ahora mismo?
• ¿Quién espera mi revisión?
• ¿Quién terminó o se rompió?

Sin esa vista, el multiagente le cuesta más en carga mental de lo que le da a la velocidad. Con él, usted puede realmente mantener 6 o 8 torrentes de trabajo a la vez.

Esa es la brecha exacta AgentsRoom llena. Cada agente obtiene su propio nivel, su estado, su color. Un agente que espera en tu respuesta se vuelve rojo y te pincha. Dejas de desplazar el terminal equivocado, miras la tabla y sabes a dónde ir.

La cadencia que funciona en la práctica

Este es el ritmo con el que empezaría.

Comience con dos agentes, en dos características que no comparten archivos. Acostúmbrate al bucle de revisión y fusión. Ese bucle, no el código, se convierte en tu verdadero trabajo.

Una vez que ese bucle se sienta suave, vaya a cuatro. Mantenga una lista estricta de prioridades de tareas de alto impacto, y apoye duro en el modo plan: aprueba el plan del agente antes de que escriba una línea. Un plan aprobado en el frente le ahorra una revisión dolorosa más tarde.

El lugar dulce se encuentra entre 3 y 8 características en el mismo repo, con supervisión visual. Más allá de eso, incluso con una buena tabla, la revisión se convierte en el cuello de botella y pierdes el beneficio.

Lo que realmente ganas

Multi-agente es inútil para el 95% de las pequeñas tareas. Para arreglar un tipopo o añadir un botón, un solo agente es bastante, y es más rápido.

Donde cambia tu semana está en gran trabajo. Una noche les echas tres refactores independientes, los revisas mientras aterrizan, y la mañana siguiente tienes tres días de trabajo listos para fusionarte.

El secreto no es el número de agentes. Siempre es saber cuál te necesita, ahora mismo. Arregla eso, y el resto sigue.