Technical Context
Pruebo regularmente entornos de codificación en la nube y agentes web (Jules, Codex/Claude Web, Cursor Web y similares) en tareas que surgen en proyectos reales: instalación de dependencias, acceso a API externas, levantamiento de servicios de desarrollo, ejecución de migraciones. Y casi siempre me encuentro con la misma limitación: el contenedor de ejecución no tiene acceso adecuado a la red o el acceso está severamente restringido.
Según mis observaciones, esto no parece un "error temporal", sino una política deliberada de sandbox. A menudo, solo se permiten solicitudes HTTPS estrictamente controladas a nivel de plataforma, sin la capacidad de salir libremente del contenedor, sin reenvío de puertos y sin el conjunto habitual de herramientas de red que esperamos en un entorno Linux.
Debido a esto, los síntomas se confunden con cualquier cosa: "DNS no resuelve", "conexión rechazada", "pip/npm no descarga", "git clone no funciona", "SDK no puede acceder a la API". Para un ingeniero, esto es crítico porque el agente formalmente "escribe código", pero no puede compilarlo y verificarlo como se hace en CI.
En este contexto, GitHub Codespaces realmente destaca como un entorno más completo: devcontainer de VS Code, capacidades de red normales, trabajo familiar con gestores de paquetes y servicios externos. Pero incluso allí he visto escenarios donde la sesión se duerme o la conexión se corta, y esto debe tenerse en cuenta en la arquitectura del flujo de trabajo.
Business & Automation Impact
No veo esto como una molestia para el desarrollador, sino como una limitación directa para la automatización con IA en las cadenas de ingeniería. Si un agente no puede instalar dependencias y acceder a sistemas externos, se convierte en un "editor inteligente" en lugar de un ejecutor de tareas autónomo.
Quienes más ganan son los equipos que ya tienen la compilación y las pruebas empaquetadas en un pipeline predecible: archivos lock, espejos de paquetes privados, artefactos, cachés, infraestructura como código. Pierden aquellos que cuentan con "internet como un hecho" y la instalación en vivo de todo sobre la marcha.
En implementaciones reales, considero esta limitación de inmediato. En los proyectos de Nahornyi AI Lab, a menudo separamos los entornos: el agente web trabaja en un entorno "estéril" para generar cambios, mientras que la ejecución (compilación/prueba/escaneo) va a un runner controlado: Codespaces, GitHub Actions self-hosted, GitLab Runner o trabajo de Kubernetes, donde la red, los secretos y las políticas de acceso están configurados explícitamente.
Si el negocio quiere hacer automatización con IA "llave en mano" —desde el ticket hasta el pull request con CI en verde— no se pueden evitar compromisos arquitectónicos. Aquí se necesita una arquitectura de soluciones de IA que considere la seguridad, el costo de cómputo, los límites de la plataforma y los requisitos de cumplimiento.
Strategic Vision & Deep Dive
Espero que "sin internet en el contenedor" se convierta en el estándar para los IDE de IA masivos, no en una fase temporal. La razón es simple: tan pronto como le das a un agente salida libre, obtienes una nueva clase de riesgos: desde fugas de claves y SSRF hasta el abuso automatizado de servicios de terceros.
Por lo tanto, diseño soluciones para que el agente no necesite internet externo para la mayoría de las operaciones. Un patrón práctico que encaja bien en la adopción de IA: imágenes de desarrollo preconstruidas con dependencias, registros internos, proxies con listas de dominios permitidos y, para integraciones, "puertas de enlace de integración" delgadas con auditoría y límite de velocidad.
Otra conclusión de mis proyectos: cuanto más autonomía del agente desees, más necesitas un "plano de ejecución" gestionado. Esto puede ser Codespaces para equipos que ya están en el ecosistema de GitHub, o un clúster aislado separado para empresas con mayores requisitos. En ambos casos, prefiero una integración de IA explícita con CI/CD y almacenes de secretos, en lugar de intentar "forzar" un IDE web al nivel de un runner de producción.
Si te parece una complicación, propongo otra perspectiva: simplemente estás trasladando la disciplina de la infraestructura de producción al circuito de desarrollo. Y es precisamente ahí donde ocurre ahora la batalla por la velocidad: no "quién escribe mejor código", sino "quién ejecuta los cambios más rápido y de forma más segura".
Lo que recomiendo hacer ahora mismo
- Separar generación y ejecución: el agente genera cambios, mientras que la compilación/pruebas van a un runner de confianza con red controlada.
- Eliminar la dependencia de internet público: cachés, espejos, imágenes de desarrollo, artefactos, registros privados.
- Formalizar la política de red: listas permitidas, proxies, auditoría, derechos mínimos para tokens.
- Configurar la "vitalidad" de los entornos: para que las sesiones no mueran en medio de tareas largas y rompan el flujo de trabajo.
Este análisis fue preparado por Vadim Nahornyi — practicante líder en Nahornyi AI Lab para la implementación de IA y automatización de procesos de ingeniería basados en agentes de IA. Puedo evaluar rápidamente tu proceso de desarrollo actual, proponer una arquitectura de IA objetivo y armar un circuito de trabajo: desde un plano de ejecución seguro hasta un pipeline "ticket → PR → CI → deploy". Contáctame y analizaremos tu caso con las limitaciones específicas de tus herramientas e infraestructura.