Agentes de código en paralelo: por qué Meta ha comprado Conductor

En resumen: la tendencia de la semana en desarrollo con IA no es un modelo nuevo, sino trabajar con varios agentes de código a la vez. El 4 de noviembre de 2026 se conoció que Meta ha comprado Conductor, una app que ejecuta agentes como Claude Code, Codex o Cursor en paralelo, cada uno en su propia copia del código. La pieza técnica que lo hace posible es muy poco glamurosa: los git worktrees. El cuello de botella ya no es escribir código, sino revisarlo.

Qué ha pasado con Conductor y Meta

Según la información publicada el 4 de noviembre de 2026 por Axios y SiliconANGLE, Meta ha adquirido Conductor, una startup cuya aplicación permite lanzar varios agentes de programación al mismo tiempo. No se han hecho públicos los términos económicos.

Lo que se sabe del producto y de la operación:

• Qué hace: deja ejecutar agentes de herramientas como Claude Code, Codex o Cursor lado a lado, cada uno en una copia aislada del repositorio. Después, el desarrollador revisa y fusiona lo que ha producido cada uno. El producto se lanzó en julio de 2025.
• Qué pasa con el equipo: el equipo se integra en Meta Superintelligence Labs, según su CEO.
• Qué pasa con el producto: Conductor Cloud se cierra este mes y la app de escritorio recibirá actualizaciones solo hasta principios de 2027. Las fuentes discrepan en la fecha exacta del cierre de la nube (13 o 20 de noviembre), así que si dependes de ella conviene revisar el aviso oficial de la compañía.
• Lectura de los analistas: InfoWorld enmarca la compra como la señal de que la programación con IA se desplaza hacia el desarrollo multiagente.

Gartner ya había puesto los sistemas multiagente en su lista de tendencias tecnológicas estratégicas para 2026, que define como grupos de agentes de IA que trabajan juntos hacia objetivos comunes. Lo de Meta es un caso concreto dentro del desarrollo de software.

¿Por qué trabajar con varios agentes a la vez?

Un agente de código trabaja despacio comparado con una persona mirando la pantalla: lee archivos, edita, ejecuta tests, vuelve a leer. Mientras tanto, tú esperas. Lanzar varios en paralelo convierte ese tiempo muerto en trabajo útil:

• Un agente corrige un bug de la API.
• Otro añade tests a un módulo sin cobertura.
• Un tercero prepara una migración de dependencias.

Tú pasas de programar a dirigir y revisar. Es el mismo cambio que ya describimos al hablar de agentes que controlan su propio ordenador y de los mejores modelos de IA para programar: el agente ejecuta, el equipo decide.

Cómo se hace: git worktrees, una carpeta por agente

Dos agentes editando la misma carpeta se pisan los cambios. La solución es darle a cada uno su propio directorio de trabajo, y Git lo permite de forma nativa con git worktree: varias carpetas enlazadas al mismo repositorio, cada una con su rama.

git worktree add ../app-fix-login fix/login
git worktree add ../app-tests-pagos tests/pagos

Funciona, pero es incómodo de manejar a mano. Por eso están apareciendo herramientas encima. La más visible esta semana es Worktrunk, un CLI en Rust diseñado para flujos de agentes en paralelo, que a fecha del 9 de noviembre de 2026 supera las 12.000 estrellas en GitHub. Según su documentación ofrece:

• wt switch para moverte a la carpeta de una rama (con -c la crea junto con su worktree, y con -x lanza un comando, por ejemplo el agente).
• wt list para ver todos los worktrees con su estado: cambios sin confirmar, commits por delante o por detrás de main y, opcionalmente, el estado de CI.
• wt merge para aplastar, rebasar, fusionar y limpiar en un solo paso.
• Hooks al crear o fusionar, cachés de compilación compartidas y un puerto de desarrollo distinto para cada worktree.

Es un buen ejemplo de hacia dónde va el ecosistema: herramientas pequeñas que gestionan el aislamiento, mientras el agente concreto (Claude Code, Codex, Cursor…) es intercambiable.

Los tres problemas que aparecen al paralelizar

1. Revisar cuesta más que generar

Con tres agentes producirás tres veces más diff. Si no puedes revisarlo con calma, el paralelismo solo acumula deuda. Una regla práctica: no lances más agentes de los que puedes revisar en la misma jornada.

2. Los conflictos al fusionar

Aunque cada agente trabaje en su carpeta, dos tareas que tocan los mismos archivos acabarán en conflicto. Conviene repartir el trabajo por áreas de código distintas y fusionar de forma escalonada.

3. Permisos y seguridad

Cada agente ejecuta comandos y lee archivos. Cuantos más hay, mayor es la superficie de riesgo. Es el tema de nuestro artículo sobre seguridad de agentes de IA: sandbox, kill switch y credenciales.

Un flujo razonable para tu equipo

Estas son recomendaciones de trabajo, no un estándar:

1. Tareas pequeñas y bien acotadas. “Añade tests al módulo X” funciona mejor que “mejora el rendimiento”.
2. Un worktree y una rama por tarea. Nombres claros, vida corta.
3. Los tests y el linter como filtro. Que el agente no pueda dar una tarea por terminada sin pasar la CI.
4. Revisión humana siempre antes de fusionar. Sobre todo en código de pagos, autenticación y datos personales.
5. Sin credenciales de producción en el entorno del agente.
6. Registra qué pidió cada agente y qué cambió, para poder auditar después.

¿Qué significa para una empresa?

Para un equipo pequeño, el paralelismo es una forma de ganar horas útiles sin contratar, pero solo si hay buenas pruebas automáticas y una cultura de revisión. Sin eso, la velocidad se convierte en errores más rápidos. Un producto con tests sólidos, una CI fiable y un repositorio bien organizado está preparado para esta ola; uno sin ellos, no.

Si quieres incorporar agentes de código a tu proceso de desarrollo, o preparar tu repositorio para que funcionen bien, en Stellar Flavor ayudamos a diseñar el flujo, los controles y las pruebas.

Fuentes

• Axios: Meta acquires AI coding startup Conductor (4 de noviembre de 2026)
• SiliconANGLE: Meta acquires AI coding startup Conductor
• InfoWorld: Meta acquires Conductor as AI coding shifts toward multi-agent development
• Gartner: Top strategic technology trends 2026
• Worktrunk en GitHub (datos consultados el 9 de noviembre de 2026)