Los contenedores son demasiado lentos para aislar código generado por IA. No un poco lentos, sino lentos en varios órdenes de magnitud. Segundos para arrancar, cientos de megabytes por instancia, y cuando necesita mil sandboxes simultáneos, tiene ante sí un proyecto de infraestructura que se come un trimestre entero.
Esa es la versión corta de lo que trata este artículo, y si ya ha llegado a la misma conclusión, puede saltar directamente a la sección sobre Dynamic Workers más abajo.
El enfoque habitual para ejecutar código no confiable es levantar un contenedor Docker con un sistema de archivos y una red aislados. Funciona. Para una herramienta interna donde el agente atiende 50 solicitudes al día, va bien. Para un producto de cara al cliente con miles de sesiones simultáneas que generan y ejecutan código, se desmorona rápido. Solo el tiempo de arranque arruina la experiencia de usuario, y orquestar miles de contenedores con Kubernetes es un proyecto en sí mismo.
Nos topamos con esto en un proyecto de cliente en el primer trimestre, mientras construíamos un agente que genera TypeScript a partir de lenguaje natural y lo ejecuta de inmediato. El modelo era la parte fácil. ¿Dónde se ejecuta realmente el código generado? «En el mismo servidor que todo lo demás» no es una respuesta, es un incidente de seguridad esperando una excusa.
El 24 de marzo, Cloudflare lanzó el Dynamic Worker Loader en beta abierta. Me parece el lanzamiento de infraestructura más interesante de este trimestre. La idea es sencilla. En lugar de contenedores, se usan aislados de V8. V8 mueve Chrome y Node.js. Un aislado es un contexto de ejecución independiente dentro del mismo proceso, con su propio heap, su propio stack y cero acceso al host. Arranca en milisegundos.
Cloudflare publicó estas cifras. Arranque 100 veces más rápido que los contenedores, 10 a 100 veces menos memoria, sandboxes simultáneos ilimitados (afirman que millones de solicitudes por segundo), latencia cero porque el aislado se ejecuta en la misma máquina que el Worker padre.
Me tomo los benchmarks de Cloudflare con cautela, porque Cloudflare vende Cloudflare. Pero incluso con la mitad de esas cifras, es un salto enorme respecto a los contenedores.
Así es el flujo. Su Worker principal recibe una solicitud, un modelo de IA genera una función TypeScript, el Worker llama al Dynamic Worker Loader, que crea un aislado de V8, carga el código, lo ejecuta y devuelve el resultado. Tras la respuesta, el aislado se descarta. Sin estado, sin residuos, sin acceso al proceso padre.
Hay un patrón que Cloudflare llama Code Mode y que me parece realmente interesante. En lugar del protocolo habitual de tool calling (el modelo genera JSON, el runtime ejecuta, el modelo analiza el resultado, llama a la siguiente herramienta), el agente escribe una única función TypeScript que encadena todo el flujo de trabajo.
Según la medición de Cloudflare, el consumo de tokens baja un 81% frente a las tool calls. No lo he comprobado por mi cuenta, pero en cuanto a la tendencia tiene sentido. Menos idas y vueltas, menos ventana de contexto gastada en resultados intermedios.
Supongamos que el agente recibe «crea una factura en Stripe para el cliente X con las partidas Y». En lugar de cuatro tool calls separadas, escribe una función que hace todo el flujo en una sola pasada.
Solo V8. Es decir, TypeScript y JavaScript, no Python, no Go, no binarios nativos. Tampoco está pensado para tareas de larga duración. Un aislado procesa una solicitud y se descarta. El precio es de 0,002 $ por Worker único al día, más los cargos habituales de CPU e invocaciones (condonados durante la beta).
Si está construyendo agentes que generan y ejecutan código, el aislamiento no es opcional. Los Dynamic Workers son una buena respuesta. Rápidos, baratos, y escalan. Pero no la única. A veces sigue necesitando un contenedor. A veces basta con una restricción en el API gateway. Depende de lo que haga el agente y de con qué datos trabaje.
La pregunta más difícil, que Cloudflare no responde (ni debería), es cómo diseñar la frontera entre el código confiable y el no confiable en un sistema de agentes. El sandbox es solo la capa de ejecución. Qué entra en él, a qué se le permite llamar y cómo se valida su salida. Ese es el problema de arquitectura. Si está lidiando con ello, hemos escrito sobre la decisión entre agente y automatización y sobre estrategias multimodelo que tocan este tema.
Si está construyendo un agente que ejecuta código generado por usuarios y quiere hablar de arquitectura, póngase en contacto.
Fundador y responsable técnico de Rise.sk. Diseña y entrega aplicaciones web, sistemas de datos y automatizaciones, y escribe sobre decisiones de software, IA y servicios digitales.
MCP conecta un agente con herramientas y datos. A2A conecta agentes independientes. Aquí verá dónde encaja cada protocolo y qué controles de seguridad siguen siendo su responsabilidad.
OpenAI dice que GPT-5.6 Sol supera a Claude Fable 5 en programación por un tercio del coste. Anthropic dice que Fable 5 lidera en capacidad bruta. Ambos tienen razón. Aquí tiene qué modelo gana qué trabajo.
Los tokens de API pueden costar menos que una hora de desarrollador, pero no son todo el proyecto. Una comparación práctica del uso del modelo, la revisión, las pruebas y los costes operativos.
Su contexto determina la respuesta
