Build2 publishers3 min readPublished
The sandbox is the product: what user-generated features actually require
A Cloudflare engineer argues web apps should let users generate their own missing features. The hard part is not the code generation, it is running that code beside live customer data.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- Jeremy Morrell is a principal engineer at Cloudflare who wants web applications to let users generate the features 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, in which a user describes a workflow in plain English, an LLM writes the code, and it runs inside a sandbox managed by the host application.
- 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.
- 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.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Jeremy Morrell, a principal engineer at Cloudflare, published an essay on August 18 proposing that web applications let users generate the features product teams will never get around to building, with a stable accountable core and controlled extension points [1][2]. The consequential claim is not that a model can write the code; it is that the opportunity belongs to platforms able to run that code safely inside products holding real customer data, which promotes sandboxing from an infrastructure detail to a thing the product has to sell [3]. Morrell's diagnosis of the product problem is ordinary, which is its strength. Teams prioritise features serving the largest groups of customers, so requests further down the demand curve wait, stay manual, or never ship [4]. Shipping all of them would leave the interface carrying the accumulated preferences of thousands of unrelated users [5]. His examples stay small: a read-it-later service forwarding every saved article longer than 4,000 words to an e-reader, a research tool that finds new papers in a narrow field weekly and adds summaries, an agent that repairs a parser which keeps mishandling one publication [6]. The essay earns its keep after the model returns code. Morrell's model depends on a runtime that keeps generated code inside a controlled boundary while still letting it perform useful actions, with the host application retaining responsibility for access, reliability and the data an extension can see [7][8]. The open questions he lists are deployment, permissions, resource limits, debugging and tenant isolation [9]. In the passage Simon Willison quoted a day later, Morrell splits the credit evenly: "LLMs radically lower the cost of authoring extensions, and modern sandbox primitives lower the deployment cost and provide good security boundaries" [10][11]. There is a reason to be strict about that boundary. A June 2026 security study found recurring vulnerabilities in applications produced through natural-language coding, including exposed secrets, unfiltered input and placeholder logic, and better models and prompts reduced the problems in the researchers' testing without eliminating the underlying risk [12]. Any host that accepts user-generated extensions is accepting that failure rate as steady-state input. Working prior art exists, but for a narrow audience. Pi, an open-source terminal coding-agent harness published under Earendil Works, is Morrell's clearest example: it exposes hooks for tools, commands, events and its terminal interface, and a user can ask it to write a TypeScript extension, reload it during a session and package the result for others [13][14]. Pi treats features as optional modules rather than permanent additions to the core [15]. OpenCode is moving similarly with an internal plugin architecture [16]. Both currently assume users comfortable running code locally, inspecting permissions and accepting the risks [17]. That assumption is the whole gap. Accountants, doctors, lawyers and support staff have highly specific workflows and cannot reasonably be expected to administer arbitrary local code [18]. Pete Koomen, the Optimizely co-founder now a general partner at Y Combinator, described the adjacent problem as "Small Software"; a July 22 Y Combinator post argued agents had made personal tools easier to create while deployment, security and sharing stayed considerably harder [19][20]. Morrell relocates that argument inside existing products: the SaaS provider supplies the trusted data, interface and runtime, and generated extensions handle the peculiar last mile [21]. His background is platform plumbing rather than model research: roughly five years at Heroku from 2019 to 2024, owning the Node.js language experience and later leading an observability team, then Cloudflare from November 2024 [22][23]. Runtimewire also notes Cloudflare has an infrastructure reason to like the thesis, which is worth holding in mind when reading it [24]. What to watch: the first mainstream SaaS vendor to publish a permission model and an isolation boundary for user-authored extensions, rather than describing one in a blog post [9].