Sal del cuello de botella. Conserva el oficio.

Con un agente de codificación, eres un pair programmer: él escribe más rápido, tú diriges. Con varios, el trabajo cambia de forma. Los agentes en la nube corren en sus propios entornos aislados, trabajan en sus propias ramas y devuelven pull requests — nada de eso toca tu máquina. [1] La promesa del paralelismo es real. Pero tu rendimiento deja de ser tu velocidad de escritura. Pasa a ser lo bien que mantienes a una flota apuntando en una sola dirección.

Y las flotas fallan de una forma específica. Apunta a un segundo agente al mismo checkout que el primero y, en minutos, ambos estarán editando el mismo archivo — uno sobrescribe al otro a mitad de un cambio, y obtienes diffs a medio aplicar y un build roto sin saber qué agente hizo qué. [2] El coste no es solo código roto. Son los tokens que tus agentes queman descubriendo la colisión, resolviéndola y reconstruyendo — un proveedor de herramientas para agentes en paralelo señala créditos de API desperdiciados en conflictos de fusión y cambios a medio terminar [3] — y eres tú, al final, quien desenreda diffs que nunca quisiste que existieran.

La solución no es un agente más inteligente. Es tratar la coordinación como infraestructura: límites de tarea explícitos, ejecución aislada y fusiones basadas en evidencia. [2] Consigue eso y de verdad dejas de ser el cuello de botella — los agentes construyen, y tú dedicas tus horas a las decisiones que solo tú puedes tomar.

La mayoría de los agentes de codificación asumen que son dueños del directorio del proyecto — leen y escriben archivos directamente. Pon a dos en el mismo checkout y tres cosas fallan rápido: colisiones de archivos, donde el agente A reescribe un archivo mientras el B lo refactoriza y git solo ve la última escritura; contaminación de contexto, donde B lee un archivo que A está cambiando a medias y razona sobre un estado que nunca existió; e interferencia de build, donde ambos agentes disparan builds y tests que compiten por los mismos directorios de salida y puertos. [4] Ninguno de estos es un caso raro. Aparecen la primera vez que pruebas dos sesiones en un repositorio.

La solución estándar son los git worktrees: un directorio de trabajo enlazado en su propia rama que comparte el mismo historial .git — aislamiento sin clonar. El comando existe desde 2015; lo que cambió es que se convirtió en la forma estándar de ejecutar más de un agente contra un mismo código base. [2] Cada agente obtiene su propio directorio y su propia rama, así que no puede tocar los archivos de nadie más — y los conflictos se trasladan al momento de fusionar, donde las herramientas normales de git los detectan, en lugar de ocurrir en silencio mientras el trabajo está en curso. [5]

Los worktrees aíslan archivos, pero no todo lo demás. Cada agente también necesita su propia base de datos (o rama de base de datos) y un puerto de servidor de desarrollo único — si no, dos agentes siguen chocando en los datos y en la red. [2]

¿Cuántos son demasiados? Quienes usan worktrees locales reportan cinco a siete agentes en un portátil como el techo práctico — más allá de eso, los límites de tasa, el disco y la carga de revisión te alcanzan. [2] Otros recomiendan de tres a cinco, así que digamos de tres a siete, según a quién preguntes. [4] Los agentes en la nube eliminan los límites del portátil, pero no el de la revisión.

El aislamiento evita que los agentes se pisen los archivos. No evita que construyan cosas incompatibles. Los repositorios reales tienen archivos "hotspot" compartidos — rutas, configuraciones, registros — y decirles a los agentes que se mantengan en archivos distintos ayuda menos de lo que uno esperaría: un fabricante de herramientas señala que una refactorización que toca la interfaz de un módulo afecta a cada archivo que lo importa, y dos agentes que añaden endpoints distintos suelen necesitar el mismo archivo de rutas. [6]

Así que la segunda mitad de la solución es el reparto. Asigna tareas que no se solapen, de modo que el solapamiento sea difícil por diseño en lugar de evitado por suerte. [5] La prueba es directa:

"Si dos tareas tienen listas de archivos que se solapan, deben ser secuenciales, no paralelas." [7]

En nuestra experiencia, el corte más limpio es por frontera, no por capa: dale a cada agente una funcionalidad o una costura, no una loncha de la misma historia vertical. Luego fusiona las ramas de una en una en orden de dependencia, ejecutando build y tests después de cada fusión, de modo que cada una aterrice en un código base sobre el que el siguiente agente pueda construir. [2]

Cuando dos partes realmente dependen entre sí, no las ejecutes en paralelo y esperes lo mejor. Marca una como bloqueada por la otra en Linear, y deja que la segunda empiece solo cuando la primera se haya fusionado. La dependencia se vuelve visible en el tablero en lugar de vivir en tu cabeza.

Cada parte sigue necesitando el mismo contrato que cualquier historia de un solo agente: la misión, las restricciones, qué está fuera de los límites y qué significa terminado. Una historia bien delimitada es lo que hace compatibles las suposiciones de dos agentes sin una reunión — cubrimos cómo escribir una en nuestra guía de historias para agentes de codificación.

Con varios agentes en marcha, no puedes revisar a ojo cada diff — y no deberías tener que hacerlo. Nuestro consejo: traslada el listón de calidad a la automatización. Exige tests y verificación automática antes de que algo se fusione, y haz que la propia fusión se base en evidencia y no en esperanza. La división de roles que surge es coordinador, especialistas y verificador — tú planificas y juzgas, los agentes ejecutan, y las comprobaciones verifican.

Esto también es lo que mantiene los tokens fluyendo hacia trabajo útil. Cuando los criterios de aceptación viven en la historia, un agente que se desvía falla sus propios tests en lugar de enviar su desviación a un revisor — o peor, a otro agente que construye encima. Cuando no, el fallo aparece como un conflicto entre dos pull requests confiados, plausibles y equivocados.

La recompensa está en dónde va tu atención: tiempo de revisión dedicado al criterio — ¿es este el comportamiento correcto, la forma correcta, el nombre correcto? — en lugar de arqueología de conflictos y diffs misteriosos.

Hay un coste más silencioso que los conflictos de fusión, y recae sobre personas que llevan toda la vida programando. Los agentes se comen exactamente el trabajo que solía hacer el día satisfactorio — las victorias pequeñas y completas — y lo que queda es decidir qué construir, juzgar compromisos, revisar y detectar sutilezas. [8] Algunos que entregan funcionalidades así no sienten nada después: el trabajo ocurrió cerca de ellos, no a través de ellos. [9]

Un desarrollador rastreó esa sensación hasta sus propias decisiones. La IA no le quitó la alegría, concluyó — él la regaló al elegir la velocidad:

"Dejo de ser la persona que lo hizo y me convierto en la persona que lo aprobó." [11]

Otro lo plantea como una cuestión de valores: automatizamos tareas que no valoramos — así que sé honesto sobre si quieres el resultado o la comprensión, y cuando sea la comprensión, hazla por la vía difícil. [10] Esa es la sensación detrás de "me he convertido en un robot de revisión de código". No es una ley del desarrollo con IA. Es lo que pasa cuando la división del trabajo se decide por defecto en lugar de por elección. Así que decide —a propósito— qué sigue siendo tuyo:

Resulta que la diversión también es un problema de diseño. Deja que los agentes se encarguen del código repetitivo, y quédate tú con los problemas difíciles y satisfactorios. [8] Un desarrollador defiende la lentitud intencional y elegir proyectos ambiciosos:

"La clave para divertirse es retarte justo en el límite de tus capacidades." [9]

Optimizar puramente para entregar rápido drena exactamente eso. Como dice la misma autora: "La capacidad de pensar problemas complejos simplemente desaparece." [9]

Hay un contrapunto honesto que merece ser escuchado: "Si ejecutas cinco agentes en paralelo, ya no estás programando, eres controlador de tráfico aéreo." [8] Eso es cierto cuando la coordinación vive en tu cabeza. Es justo por eso que la coordinación — quién va después, qué está bloqueado, qué necesita revisión — debería ser herramienta, no tu atención.

Algunos movimientos concretos que sobreviven el contacto con una semana real: quédate tú con la parte más difícil de una historia y entrega el resto a la flota. Conserva una parte del sistema que siempre sea tuya — el lugar donde todavía escribes cada línea. Termina el día con una revisión que sea arquitectura, no inspección: eres tú quien decide en qué debe convertirse el código a continuación.

Esto no es nostalgia. La motivación es un insumo de producción: nadie sostiene una flota desde un trabajo que se siente como vigilar máquinas. Conserva el oficio, y los agentes se convierten en palanca.

El consejo de esta guía se reduce a tres hábitos: dividir el trabajo para que no pueda chocar, fusionar una rama a la vez en orden de dependencia, y dejar que las comprobaciones —no tus ojos— sean la primera puerta de calidad. Aerunit convierte esos hábitos en automatización para equipos en Linear y Cursor Cloud Agents.

Sigue las relaciones de Linear blocks / blocked-by: cuando un pull request se fusiona, Aerunit encuentra las incidencias que ese PR estaba bloqueando y las pone en cola para Cursor Cloud Agents, de modo que la siguiente parte empieza sobre código ya fusionado. Eso es fusión secuencial, hecha por ti. Cuando un agente abre un PR, Aerunit ejecuta una revisión de código y puede enviar los hallazgos de vuelta a la sesión del agente. Y Aerunit lee cada repositorio que toca una historia antes de escribirla, así que el trabajo entre varios repos obtiene un plan coherente y una subtarea por repositorio. Tú sigues decidiendo qué se ejecuta; Aerunit gestiona el "qué sigue" en cuanto se fusiona un bloqueador.