Deja de tratar a los agentes de IA como herramientas desechables: dales workspaces de verdad
La evolución de los agentes de IA: de jaulas seguras a equipos de desarrollo reales
Al principio, con asistentes de código como Claude o frameworks de agentes, todos poníamos barreras por todos lados. Era lógico. Nadie quería ver cómo un agente hiperactivo borraba todo con un comando equivocado.
Los contenedores calmaron los nervios. Ambientes aislados permitían que los agentes experimentaran sin dañar nada importante. Pero luego llegó el cambio: estos herramientas empezaron a ser lo suficientemente buenos para tareas reales. No experimentos. Código listo para producción.
Ahí el modelo de un solo agente comenzó a fallar.
El lío del procesamiento paralelo que nadie menciona
Imagina que tienes pendientes:
- Refactorizar un endpoint de API
- Arreglar tests que fallan
- Diagnosticar un problema en Docker
- Mejorar el frontend
Lo natural es hacer cola: agente termina uno, revisas, pasas al siguiente. Pero eso anula la magia de la autonomía. Terminas supervisando como niñera, cuando el objetivo es liberarte para pensar en grande.
Intentas varios agentes en paralelo. Y ahí empieza el desmadre.
Git se convierte en pesadilla. Dos agentes tocando el mismo repo en la misma rama generan conflictos nonstop. Un commit de uno choca con el otro. Redescubres por qué existen las revisiones de código.
El filesystem no perdona. Proyectos grandes tienen basura por todos lados: node_modules, cachés de build, código generado, bases SQLite, .env llenos de secretos. Nada en Git. Todo colisiona cuando varios procesos pisan las mismas carpetas.
Docker Compose mata la fiesta. Todos quieren el puerto 5432. Todos nombran su contenedor "postgres-dev". Todos usan el mismo volumen. Lo que parecía progreso paralelo termina en contenedores muriendo en cadena.
La trampa de los Git worktrees
La solución clásica dice: "¡Usa Git worktrees!".
Suena bien en teoría. En la práctica, resuelve poco.
Los worktrees permiten checkouts múltiples en branches distintas, compartiendo .git. Ideal para humanos. Para agentes, tapa un 15% del problema y complica el resto.
No dan node_modules separados. No aíslan .env. No crean namespaces para Docker Compose. Aún debes instalar dependencias manualmente, reconstruir cachés, remapear puertos y rezar por paths relativos.
Es como pedirle a un dev que trabaje sin la mitad de sus herramientas.
Cambia el enfoque: agentes como compañeros de equipo
El giro clave: deja de verlos como herramientas y trátalos como developers.
No le dices a Ana: "Trabaja como worktree en mi branch". Le dices: "Clona el repo, arma tu entorno, corre la app, sube tu branch al final".
No forks de branches. Forks de contextos completos de desarrollo.
Para que funcionen en paralelo, cada agente necesita:
Entornos aislados. Clone propio, dependencias propias, .env propio. Cero estado compartido, cero choques.
Infra independiente. Proyectos Docker Compose con namespaces distintos. El Postgres de uno no peleará con el Redis del otro. Pueden correr, debuguear y testear solos.
Autenticación y permisos precisos. SSH para Git. Credenciales de GitHub por agente. Nada de claves globales compartidas.
Conciencia del contexto. Saber su branch, su tarea específica, cómo medir éxito.
Coordinación asíncrona. Trabajan solos, dejan resultados listos para review. Tú decides merges y timings.
Así se ve en la práctica
En NameOcean vemos equipos adoptando esto para desarrollo con IA. No un agente por proyecto. Múltiples instancias con:
- Workspaces en contenedores (tipo yolobox)
- Bases de datos independientes o fixtures
- Configs Docker Compose separadas
- Manifests de contexto que los agentes leen
- Puentes de clipboard y SSH para integración fluida
El flujo queda así:
- Agente Alfa arranca en workspace A, ataca el módulo de auth
- Agente Beta en workspace B, arma la doc de API
- Agente Gamma en workspace C, escribe y pule tests
- Cada uno termina, sube a su feature branch
- Tú revisas todo en paralelo, merges con cabeza
Sin colas. Sin vigilancia. Sin muertes de contenedores.
La pregunta de la infraestructura
Hay que repensar cómo armamos entornos de dev. Plataformas cloud se adaptan: IaC pasa de opcional a esencial. Docker, Kubernetes y dev en contenedores (como explora Vibe Hosting de NameOcean) dejan de ser moda para ser imprescindibles.
Los templates importan. Fragmentos de Dockerfile, variaciones de docker-compose.yml, scripts de bootstrap: eso es la spec que los agentes ejecutan.
Por qué importa hoy
Estamos en el punto de quiebre. Agentes de IA son lo bastante buenos para ser riesgosos y útiles para invertir en infra. Equipos que organicen flujos como squads reales de software volarán más rápido que los atascados en sandboxes de tareas sueltas.
No es solo velocidad. Es multiplicar capacidad real o solo automatizar teclas.
Pasos siguientes
Si pruebas agentes en tu flujo:
- No optimices para uno solo. Diseña para escalar desde ya.
- Invierte en templates de entorno. Docker e IaC no son costo: son el SO de tus agentes.
- Permisos estrictos. Acceso amplio genera caos.
- Provisión como prioridad. Cuánto tardas en spawn un agente nuevo define tu ritmo.
- Versiona configs de agentes. Igual que el código, versiona sus entornos.
El dev futuro no es humano + agente. Son orquestas mixtas, en contextos aislados, hacia un goal común.
Ahí desbloqueas productividad de verdad.