Jeremy Morrell argues LLM-written extensions and sandboxed runtimes could serve workflows too specific for a conventional product roadmap.
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, a principal engineer at Cloudflare, wants web applications to let users generate the features that product teams will never have time to build.
In an essay published August 18, Morrell lays out a model for web software built around a stable, accountable core and controlled extension points. A user could describe a specialized workflow in plain English, have an LLM write the necessary code, and run it inside a sandbox managed by the host application.
That structure addresses a familiar product problem. Software teams prioritize features that serve the largest groups of customers. Requests farther down the demand curve wait, remain manual, or never ship. Adding every requested feature would eventually leave the interface carrying the accumulated preferences of thousands of unrelated users.
Morrell's proposal gives those users another option: ask the application to make the missing piece for them.
His examples are deliberately ordinary. A read-it-later service could send every saved article longer than 4,000 words to an e-reader. A research tool could find new papers in a narrow field each week and add summaries. A user could have an agent repair a parser that consistently mishandles one publication.
Each request is too particular to justify a place on a broad product roadmap. Together, they form a large class of unmet demand.
A platform engineer follows the problem down the stack
Morrell worked at Heroku from 2019 to 2024, where he owned the Node.js language experience and later led an observability team, and joined Cloudflare in November 2024. Earlier, he worked as a frontend engineer at Facebook and Recurly. He studied computational and applied mathematics at Rice University.
That background helps explain why his essay spends less time celebrating code generation than examining what happens after the model produces code. The difficult questions involve deployment, permissions, resource limits, debugging and tenant isolation.
Morrell's proposal depends on a runtime that can keep generated code within a controlled boundary while still allowing it to perform useful actions. The host application would retain responsibility for access, reliability and the data exposed to an extension.
A June 2026 security study found recurring vulnerabilities in applications produced through natural-language coding, including exposed secrets, unfiltered input and placeholder logic. Better models and prompts reduced problems in the researchers' testing without eliminating the underlying risks.
Pi shows what self-extending software looks like
Morrell points to Pi as his clearest working example. Pi is an open-source terminal coding-agent harness published under Earendil Works. It exposes hooks for tools, commands, events and its terminal interface. Users can ask Pi to write a TypeScript extension, reload it during a session and package the result for others.
Pi's design treats features as optional modules rather than permanent additions to the core. That structure lets users customize the software without requiring every extension to become an official feature.
OpenCode is moving in a similar direction with an internal plugin architecture. These projects currently expect users to be comfortable running code locally, inspecting permissions and accepting the risks that follow. Morrell's larger opportunity lies outside that technical audience.
Accountants, doctors, lawyers and support staff may have highly specific workflows, but they cannot reasonably be expected to administer arbitrary local code. Reaching them requires the host application to absorb the security and operational burden.
That is the gap Pete Koomen, the Optimizely co-founder who is now a Y Combinator general partner, described under the label "Small Software." In a July 22 post, Y Combinator argued that agents had made personal tools easier to create while deployment, security and sharing remained considerably harder.
Morrell moves that argument inside existing products. Instead of asking every user to create and operate a separate application, a SaaS provider could supply the trusted data, interface and runtime, then let generated extensions handle the peculiar last mile.
Cloudflare has an infrastructure reason to like the thesis
Morrell identifies Cloudflare Dynamic Workers as a particularly good fit for the model he describes. The system is one possible way to execute runtime-supplied code within a controlled boundary.
Cloudflare also has a concrete demonstration in Cloudflare OS, an open-source AI productivity environment originally developed for use inside Cloudflare. Its documentation describes an agent chat interface, sandboxed development for small personal applications called Gadgets, and a security framework called Gatekeepers that applies guardrails to agents and applications.
The project supplies an early version of the behavior Morrell describes, although his essay presents the idea as a broader product architecture rather than a Cloudflare roadmap.
The feature backlog becomes a runtime problem
LLMs could remove much of the authoring burden, while serverless runtimes, V8 isolates, microVMs and WebAssembly reduce the cost of executing user code. The hard work shifts toward defining safe extension points and deciding what the host application will permit.
For founders, that changes the product decision. A request from a small customer segment no longer has to become a permanent menu item or an unsupported webhook. It can become a bounded extension that the user generates and the application supervises. The tradeoff remains substantial. Every extension point expands the security model, creates support obligations and introduces behavior the original product team did not write. A stable core still needs clear limits, audit trails and a way to disable failing code. LLMs make customization cheaper; they do not make the host less accountable.
Morrell's bet is that the economics have moved far enough to justify taking on that work. If he is right, the next generation of SaaS products will ship fewer assumptions about how every customer should work. Their most important feature may be a safe place for users to build the rest.