Agentes de IA para programar: cómo usar varios en paralelo

Un entorno de desarrollo de agentes (ADE, por sus siglas en inglés) es un espacio de trabajo para ejecutar varios agentes de IA para programar al mismo tiempo. Cada agente recibe su propia tarea, una copia aislada del código y un estado visible, mientras una persona reparte el trabajo, supervisa el avance y revisa cada cambio antes de fusionarlo.

01Puntos clave

• Los agentes de IA en paralelo solo compensan cuando las tareas son independientes, acotadas y verificables.
• Primero, el aislamiento: dale a cada agente su propio git worktree y su propia rama.
• La observabilidad es la función central de un ADE: ver de un vistazo qué agente está trabajando, esperando, bloqueado o ha terminado.
• El cuello de botella deja de ser la generación de código y pasa a ser la revisión, así que ejecuta solo tantos agentes como puedas revisar.
• Cada fusión sigue siendo responsabilidad de una persona: lee el diff y ejecuta tú mismo las comprobaciones.

02¿Qué son los agentes de IA para programar?

Un agente de IA para programar es una herramienta basada en un modelo que puede leer un repositorio, editar archivos y ejecutar comandos y pruebas para completar una tarea descrita, en lugar de limitarse a sugerir código mientras escribes. Algunos ejemplos son los agentes de terminal como Claude Code, Codex CLI y Gemini CLI, los modos de agente de los editores de código y los agentes alojados que trabajan en un sandbox en la nube y devuelven una pull request.

03¿Qué es un entorno de desarrollo de agentes (ADE)?

Un IDE tradicional está pensado para una persona que edita una sola copia de trabajo, y muchos editores ya incorporan sus propias funciones de agente. Pero en cuanto hay varios agentes en marcha, tu jornada gira en torno a la coordinación, no a la edición. El término, que a veces aparece como agentic development environment, se refiere al lugar donde desarrollas software con agentes de IA para programar, no a herramientas para crear agentes de IA.

Un ADE no sustituye a tu editor ni a los agentes. Es la capa de orquestación que está por encima de ellos y se ocupa del trabajo que se multiplica con cada agente:

• Aislamiento del espacio de trabajo: un directorio de trabajo y una rama propios para cada agente, sin llevar a mano la contabilidad de git.
• Seguimiento de tareas: las instrucciones que recibió cada agente, siempre a la vista.
• Estado en vivo: qué agentes están en ejecución, esperando una respuesta, terminados o con errores.
• Superficie de revisión: el diff, los comandos y los resultados de las pruebas de cada agente en un solo lugar.
• Integración: un camino controlado desde la rama de cada agente hasta tu rama principal.

04¿Por qué ejecutar varios agentes de IA para programar en paralelo?

Un agente que trabaja en una tarea no trivial suele pasar varios minutos seguidos leyendo, editando, probando y corrigiendo. Si supervisas uno cada vez, pasas la mayor parte de ese tiempo esperando. Los agentes en paralelo convierten la espera en productividad: mientras uno refactoriza, otro escribe pruebas para un módulo distinto y un tercero investiga un informe de error.

En la práctica, tres patrones cubren la mayor parte del trabajo en paralelo:

• Reparto (fan-out): varias tareas independientes del mismo backlog, un agente para cada una, y cada una se fusiona por separado.
• Intentos en competencia: en problemas ambiguos, la misma tarea se asigna a dos agentes, o se lanza dos veces con instrucciones distintas, y te quedas con el mejor resultado.
• Cadena (pipeline): un agente implementa, un segundo revisa el resultado o escribe pruebas para él, y una persona toma la decisión final.

05¿Con qué configuraciones puedes ejecutar agentes de IA en paralelo?

La mayoría de los equipos usa una de estas cuatro configuraciones, y muchos las combinan:

• Pestañas de terminal o paneles de tmux, con un agente y un git worktree en cada uno: no hacen falta herramientas nuevas, pero tienes que seguir tú el estado de cada agente.
• Funciones multiagente integradas en un editor: cómodas cuando todo el equipo ya trabaja con ese editor.
• Agentes en la nube o en segundo plano que se ejecutan en un sandbox alojado y devuelven una pull request: nada se ejecuta en local y lo que revisas es una PR.
• Un entorno de desarrollo de agentes dedicado: el estado, los diffs y la revisión de todos los agentes en un solo lugar.

06¿Qué tareas encajan bien con agentes de IA en paralelo?

Pon a prueba cada tarea candidata con cuatro preguntas. ¿Es independiente de las demás tareas en curso? ¿Se puede describir en unas instrucciones breves? ¿Se puede verificar con pruebas, una comprobación de tipos, una compilación o un criterio de aceptación? ¿Toca una parte distinta del código?

Buenas candidatas

• Añadir pruebas a módulos sin cobertura.
• Correcciones de errores autocontenidas con una reproducción clara.
• Funcionalidades aisladas tras una interfaz bien definida, como un nuevo endpoint de API o un componente de interfaz.
• Migraciones mecánicas que se reparten limpiamente por directorio o paquete.
• Documentación, mejoras de tipado y correcciones de lint en zonas que nadie más está editando.

Malas candidatas

• Cambios de arquitectura que se propagan por tipos compartidos o por el modelo de datos.
• Tareas en las que decidir si están terminadas es cuestión de gusto.
• Dos tareas que necesitan modificar el mismo archivo central, como un router, un esquema o un manifiesto de dependencias.
• Trabajo que depende del resultado de otra tarea sin terminar.

07Cómo ejecutar varios agentes de IA para programar, paso a paso

1. 1Divide el trabajo en tareas independientes.
2. 2Aísla cada agente con su propio git worktree y su propia rama.
3. 3Escribe instrucciones que cada agente pueda ejecutar.
4. 4Supervisa, desbloquea e interviene.
5. 5Revisa y fusiona las ramas de una en una.

Paso 1: divide el trabajo en tareas independientes

Empieza por el resultado, no por los agentes. Divide el objetivo en tareas que puedan completarse, verificarse y fusionarse por sí solas. Si dos tareas van a editar los mismos archivos, júntalas o ejecútalas una detrás de otra. Una breve nota de dependencias, como “necesita el nuevo esquema de la tarea 2”, evita la mayoría de las sorpresas al integrar.

Paso 2: aísla cada agente con git worktrees

Dos agentes en el mismo directorio de trabajo pueden sobrescribir los cambios del otro y confundir sus respectivas ejecuciones de pruebas. El aislamiento confiable más sencillo es un git worktree: un directorio de trabajo adicional vinculado al mismo repositorio, con su propia rama.

# One worktree and one branch per agent
git worktree add -b agent/auth-refactor ../app-agent-auth
git worktree add -b agent/billing-tests ../app-agent-tests

# See what is checked out where
git worktree list

# Clean up once the branch has been merged locally (use -D after a squash merge)
git worktree remove ../app-agent-auth
git branch -d agent/auth-refactor

Por defecto, git no deja tener la misma rama activa en dos worktrees a la vez, que es justo la protección que quieres. Al limpiar, git worktree remove se niega a eliminar un worktree con archivos modificados o sin seguimiento: haz commit de ellos o descártalos antes, o usa --force cuando estés seguro. Los worktrees aíslan los archivos, no todo lo demás. Planifica lo que siguen compartiendo:

• Dependencias y compilación: cada worktree suele necesitar sus propios paquetes instalados (node_modules, entornos virtuales) y su propia salida de compilación.
• Puertos: dos servidores de desarrollo no pueden usar el mismo puerto, así que asigna uno a cada agente.
• Bases de datos: usa bases de datos o esquemas locales separados, nunca un entorno de staging compartido.
• Archivos de entorno: copia solo la configuración no secreta que necesite cada agente.

Paso 3: escribe instrucciones que cada agente pueda ejecutar

Los agentes rellenan con suposiciones cualquier hueco que dejen las instrucciones. Unas buenas instrucciones son breves pero completas:

• Objetivo: una frase que describa el resultado, no la implementación.
• Contexto: los archivos, módulos o documentos que importan y las convenciones que hay que seguir.
• Límites: lo que el agente no debe cambiar, como interfaces públicas, migraciones o dependencias.
• Definición de terminado: las pruebas, comprobaciones de tipos o comportamientos que deben superarse.
• Entrega: qué debe informar al terminar, como un resumen de los cambios y las preguntas pendientes.

Si guardas instrucciones permanentes del proyecto en un archivo que el agente lee al arrancar, como AGENTS.md o CLAUDE.md según el agente, te ahorras repetir las convenciones en cada encargo.

Paso 4: supervisa, desbloquea e interviene

Una vez que los agentes están en marcha, tu papel pasa de autor a supervisor. Revísalos con una cadencia fija en lugar de ver desfilar la salida de un solo agente, y responde rápido a las solicitudes de permiso, porque un agente bloqueado es tiempo perdido. Detén pronto a un agente cuando se desvíe: volver a empezar con instrucciones más precisas suele ser más rápido que rescatar una ejecución larga que salió mal.

Paso 5: revisa y fusiona las ramas de una en una

Fusiona en orden de dependencias, una rama cada vez. Después de cada fusión, haz rebase de las ramas restantes sobre la rama principal actualizada y vuelve a ejecutar sus comprobaciones. Los conflictos en esta fase son información útil: revelan tareas que eran menos independientes de lo que parecían.

08Cómo evitar conflictos entre agentes de IA

La mayoría de los conflictos entre agentes en paralelo nacen en unos pocos puntos calientes compartidos:

• Lockfiles y manifiestos de dependencias: en cada ronda, deja que solo un agente añada o actualice dependencias.
• Migraciones de base de datos: ejecútalas en secuencia, porque las migraciones generadas en paralelo pueden chocar por el orden o por el estado del esquema.
• Registros compartidos, como routers y configuración: asigna a cada archivo un único responsable, o haz tú el cambio primero.
• Código generado: vuelve a generarlo después de fusionar, en lugar de fusionar archivos generados procedentes de varias ramas.
• Cambios de formato innecesarios: pide a los agentes que no reformateen archivos que no hayan tenido que modificar por otro motivo.

La otra mitad de la respuesta son las ramas de vida corta: las tareas pequeñas que se fusionan en cuestión de horas generan muchos menos conflictos que las ramas que se alejan de la rama principal durante días.

09¿Cómo supervisar lo que hace cada agente de IA para programar?

Con un agente, basta con mirar la terminal. Con cinco, es imposible. Para cada agente deberías poder responder de un vistazo a estas preguntas:

• ¿En qué está trabajando y qué instrucciones recibió?
• ¿En qué estado está: en ejecución, esperando una respuesta o un permiso, bloqueado por un error o terminado?
• ¿Qué ha cambiado hasta ahora, visto como diff respecto a su rama base?
• ¿Qué comandos ha ejecutado y se superaron las pruebas y comprobaciones?
• ¿Cuánto tiempo lleva en ejecución y cuánto uso ha consumido?

Las notificaciones importan tanto como los paneles. Un agente que espera diez minutos una aprobación de una sola palabra es un costo oculto habitual del trabajo en paralelo. Un buen entorno de desarrollo de agentes te avisa de esos momentos al instante.

10¿Cuánto cuesta ejecutar varios agentes de IA para programar?

El costo tiene dos partes: el uso del modelo y el tiempo de las personas. El uso del modelo crece con el número de agentes, la duración de sus ejecuciones y el contexto que leen. Tanto si pagas por token como si trabajas dentro de los límites de una suscripción, los agentes en paralelo agotan ese presupuesto más rápido, y los intentos en competencia lo gastan a propósito en trabajo que vas a descartar.

El tiempo de las personas es el costo que más se subestima, porque el resultado de cada agente hay que leerlo, probarlo e integrarlo. Una regla práctica útil: ejecuta solo tantos agentes como puedas revisar con el mismo cuidado que dedicas a la pull request de un compañero. Para mantener ambos costos bajo control:

• Mantén las tareas pequeñas, para que las ejecuciones sean cortas y los diffs, fáciles de revisar.
• Dirige a los agentes a los archivos relevantes en lugar de a todo el repositorio.
• Detén las ejecuciones que se desvían en vez de dejar que terminen.
• Mide el uso por tarea para aprender qué tipos de trabajo vale la pena delegar.

11Por qué la revisión humana del código generado por IA sigue siendo importante

Los agentes de IA para programar son capaces, pero no rinden cuentas. Pueden malinterpretar un requisito, escribir pruebas que validan el comportamiento equivocado, silenciar un error en lugar de corregirlo o afirmar que una comprobación se superó cuando nunca llegó a ejecutarse. El código escrito por personas se revisa por las mismas razones; los agentes en paralelo simplemente producen más cambios, y más rápido.

Un ciclo de revisión práctico tiene tres capas: el agente comprueba su propio trabajo frente a la definición de terminado; opcionalmente, un segundo agente revisa el diff con un contexto nuevo; y, por último, una persona lee el diff y decide si se fusiona. Las capas automáticas reducen el ruido, pero no sustituyen esa decisión.

Lista de verificación para revisar cambios hechos por agentes

• Lee el diff en sí, no solo el resumen que hace el agente.
• Ejecuta tú mismo las pruebas y comprobaciones, o confirma que se ejecutaron en CI.
• Vigila que no se haya ampliado el alcance: archivos modificados que las instrucciones nunca mencionaban.
• Revisa las dependencias nuevas, las llamadas de red y todo lo que toque la autenticación, los pagos o los datos personales.
• Asegúrate de que no se hayan incluido en un commit secretos, tokens ni rutas propias de una máquina concreta.
• Confirma que las pruebas nuevas ejercitan de verdad el comportamiento nuevo, y no solo que pasan.

12Errores comunes al ejecutar varios agentes de IA

• Ejecutar dos agentes en el mismo directorio de trabajo y perder trabajo por archivos sobrescritos.
• Dejar las ramas de los agentes abiertas durante días, hasta que ya no se fusionan limpiamente.
• Dar a los agentes credenciales de producción o permisos que no necesitan.
• Contar agentes en ejecución en lugar de cambios fusionados que funcionan.

13Preguntas frecuentes

¿Qué diferencia hay entre un IDE y un entorno de desarrollo de agentes?

Un IDE tradicional gira en torno a una persona que edita código en una sola copia de trabajo, aunque muchos editores ya incluyen funciones de agente. Un entorno de desarrollo de agentes gira en torno a la supervisión de varios agentes de IA para programar, con aislamiento del espacio de trabajo, seguimiento de tareas, estado en vivo y un camino controlado de revisión y fusión. Muchos desarrolladores usan ambos: el ADE para coordinar a los agentes y el IDE para inspeccionar o rematar su trabajo.

¿Cuántos agentes de IA para programar debería ejecutar a la vez?

Tantos como puedas revisar como es debido. Como regla práctica, empieza con dos o tres agentes en tareas claramente independientes. Aumenta el número solo cuando tu proceso de revisión y fusión dé abasto. Si los diffs esperan días a que alguien los revise, o te sorprendes fusionando sin leer, estás ejecutando demasiados.

¿Necesito git worktrees para ejecutar agentes en paralelo?

Necesitas algún tipo de aislamiento, y los git worktrees son la opción más ligera: cada agente tiene su propio directorio y su propia rama dentro de un mismo repositorio compartido. Los clones separados o los contenedores aíslan mejor, pero ocupan más espacio en disco y requieren más configuración. Los sandboxes alojados que devuelven una pull request sacan el aislamiento de tu máquina, pero no la revisión. Nunca dejes que dos agentes editen el mismo directorio de trabajo a la vez.

¿Pueden los agentes de IA para programar revisar el código unos de otros?

Sí, y es una capa extra útil. Un segundo agente con instrucciones de revisor y un contexto nuevo suele detectar pruebas que faltan, casos límite sin tratar y cambios fuera del alcance. Aun así, no debería ser el filtro final: los agentes pueden compartir los mismos puntos ciegos, así que una persona debería seguir leyendo el diff y decidiendo la fusión de todo lo que vaya a llegar a producción.

¿Es seguro dejar que los agentes de IA para programar ejecuten comandos en mi equipo?

Puede serlo, con salvaguardas. Da a los agentes solo los privilegios mínimos que necesiten, mantén las credenciales de producción fuera de su entorno y exige aprobación para los comandos destructivos o que acceden a la red. Trata como no confiable todo lo que un agente lea fuera de tu código, como issues, páginas web o archivos de terceros, porque puede contener instrucciones diseñadas para engañarlo, un riesgo conocido como inyección de prompts (prompt injection). Los contenedores añaden otra capa de protección.

14Cómo aborda Neptay el desarrollo con agentes

Diseñamos agentes de IA y automatizaciones como parte de nuestros servicios para clientes, y creamos nuestros propios productos tecnológicos bajo la marca Anlato. Anlato Space, el producto insignia de la familia Anlato, es nuestro entorno de desarrollo de agentes: muchos agentes de IA para programar uno junto a otro en una sola ventana nativa, cada uno con su tarea y su estado, y cada cambio a la espera de tu revisión. Llegará pronto. Si estás diseñando un flujo de trabajo con agentes para tu equipo, o quieres seguir de cerca Anlato Space, escríbenos a hello@neptay.com.