Ingeniero de Cloudflare propone aplicaciones web cuyos usuarios generan las funciones faltantes
Jeremy Morrell sostiene que las extensiones escritas por LLM y los entornos de ejecución en sandbox podrían atender flujos de trabajo demasiado específicos para una hoja de ruta de producto convencional.
By RuntimeWire Staff · Published
Primary source: Jeremy Morrell
Why it matters
LLMs can write niche features on demand, but the larger opportunity belongs to platforms that can run that code safely inside products holding real customer data.
Jeremy Morrell, un ingeniero principal en Cloudflare, quiere que las aplicaciones web permitan a los usuarios generar las funciones que los equipos de producto nunca tendrán tiempo de construir.
En un ensayo publicado el 18 de agosto, Morrell expone un modelo para software web construido alrededor de un núcleo estable y responsable y puntos de extensión controlados. Un usuario podría describir un flujo de trabajo especializado en lenguaje natural, pedirle a un LLM que escriba el código necesario y ejecutarlo dentro de un entorno aislado gestionado por la aplicación anfitriona.
Esa estructura aborda un problema de producto familiar. Los equipos de software priorizan las funciones que sirven a los grupos más numerosos de clientes. Las solicitudes más abajo en la curva de demanda esperan, permanecen manuales o nunca se lanzan. Añadir cada función solicitada eventualmente dejaría la interfaz cargando las preferencias acumuladas de miles de usuarios no relacionados.
La propuesta de Morrell ofrece a esos usuarios otra opción: pedir a la aplicación que les haga la pieza que falta.
Sus ejemplos son deliberadamente ordinarios. Un servicio para leer después podría enviar cada artículo guardado con más de 4,000 palabras a un lector electrónico. Una herramienta de investigación podría encontrar cada semana nuevos artículos en un campo muy específico y añadir resúmenes. Un usuario podría pedirle a un agente que repare un parser que maneja de forma incorrecta de forma consistente una publicación.
Cada solicitud es demasiado particular para justificar un lugar en una hoja de ruta de producto amplia. Juntas, forman una gran clase de demanda insatisfecha.
A platform engineer follows the problem down the stack
Morrell trabajó en Heroku de 2019 a 2024, donde fue responsable de la experiencia de Node.js y más tarde dirigió un equipo de observabilidad, y se unió a Cloudflare en noviembre de 2024. Antes, trabajó como ingeniero frontend en Facebook y Recurly. Estudió matemáticas computacionales y aplicadas en Rice University.
Ese trasfondo ayuda a explicar por qué su ensayo dedica menos tiempo a celebrar la generación de código que a examinar lo que ocurre después de que el modelo produce código. Las preguntas difíciles involucran despliegue, permisos, límites de recursos, depuración y aislamiento entre inquilinos.
La propuesta de Morrell depende de un runtime que pueda mantener el código generado dentro de un límite controlado mientras aún le permite realizar acciones útiles. La aplicación anfitriona conservaría la responsabilidad del acceso, la fiabilidad y los datos a los que se expone una extensión.
Un estudio de seguridad de junio de 2026 encontró vulnerabilidades recurrentes en aplicaciones producidas mediante programación en lenguaje natural, incluyendo secretos expuestos, entrada sin filtrar y lógica de marcador de posición. Mejores modelos y prompts redujeron problemas en las pruebas de los investigadores sin eliminar los riesgos subyacentes.
Pi shows what self-extending software looks like
Morrell señala a Pi como su ejemplo funcional más claro. Pi es un entorno de agente de codificación para terminales de código abierto publicado bajo Earendil Works (https://github.com/earendil-works/pi?ref=runtimewire). Expone ganchos para herramientas, comandos, eventos y su interfaz de terminal. Los usuarios pueden pedirle a Pi que escriba una extensión en TypeScript, recargarla durante una sesión y empaquetar el resultado para otros.
El diseño de Pi trata las funciones como módulos opcionales en lugar de adiciones permanentes al núcleo. Esa estructura permite a los usuarios personalizar el software sin exigir que cada extensión se convierta en una función oficial.
OpenCode se mueve en una dirección similar con una arquitectura interna de plugins. Estos proyectos actualmente esperan que los usuarios estén cómodos ejecutando código localmente, inspeccionando permisos y aceptando los riesgos que ello conlleva. La oportunidad mayor de Morrell está fuera de ese público técnico.
Contadores, médicos, abogados y personal de soporte pueden tener flujos de trabajo muy específicos, pero no se puede exigir razonablemente que administren código local arbitrario. Alcanzarlos requiere que la aplicación anfitriona absorba la carga de seguridad y operativa.
Esa es la brecha que describió Pete Koomen, el cofundador de Optimizely que ahora es socio general de Y Combinator, bajo la etiqueta "Small Software". En una publicación del 22 de julio, Y Combinator argumentó que los agentes habían facilitado la creación de herramientas personales, mientras que el despliegue, la seguridad y el compartir seguían siendo considerablemente más difíciles.
Morrell traslada ese argumento al interior de productos existentes. En lugar de pedir a cada usuario que cree y opere una aplicación separada, un proveedor SaaS podría suministrar los datos confiables, la interfaz y el runtime, y luego dejar que las extensiones generadas manejen la última milla peculiar.
Cloudflare has an infrastructure reason to like the thesis
Morrell identifica a Cloudflare Dynamic Workers como un ajuste particularmente bueno para el modelo que describe. El sistema es una forma posible de ejecutar código provisto en tiempo de ejecución dentro de un límite controlado.
Cloudflare también tiene una demostración concreta en Cloudflare OS, un entorno de productividad AI de código abierto desarrollado originalmente para uso dentro de Cloudflare. Su documentación describe una interfaz de chat para agentes, desarrollo en entornos aislados para pequeñas aplicaciones personales llamadas Gadgets, y un marco de seguridad llamado Gatekeepers que aplica salvaguardas a agentes y aplicaciones.
El proyecto suministra una versión temprana del comportamiento que describe Morrell, aunque su ensayo presenta la idea como una arquitectura de producto más amplia que un roadmap de Cloudflare.
The feature backlog becomes a runtime problem
Los LLMs podrían eliminar gran parte de la carga de autoría, mientras que los runtimes serverless, V8 isolates, microVMs y WebAssembly reducen el costo de ejecutar código de usuario. El trabajo difícil se desplaza hacia definir puntos de extensión seguros y decidir qué permitirá la aplicación anfitriona.
Para los fundadores, eso cambia la decisión de producto. Una solicitud de un segmento pequeño de clientes ya no tiene que convertirse en un elemento permanente del menú o en un webhook no soportado. Puede convertirse en una extensión acotada que el usuario genera y que la aplicación supervisa.
El tradeoff sigue siendo sustancial. Cada punto de extensión expande el modelo de seguridad, crea obligaciones de soporte e introduce comportamientos que el equipo de producto original no escribió. Un núcleo estable sigue necesitando límites claros, registros de auditoría y una forma de desactivar código que falla. Los LLMs abaratan la personalización; no hacen que el anfitrión sea menos responsable.
La apuesta de Morrell es que la economía se ha movido lo suficiente como para justificar asumir ese trabajo. Si está en lo correcto, la próxima generación de productos SaaS enviará menos supuestos sobre cómo debe trabajar cada cliente. Su función más importante podría ser un lugar seguro para que los usuarios construyan el resto.