Skip to content

Build Independently confirmed2 publishers 3 min read Published

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

Send 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.

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 [5]. 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 [6]. Shipping all of them would leave the interface carrying the accumulated preferences of thousands of unrelated users [7]. 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 [8]. 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 [9][10]. The open questions he lists are deployment, permissions, resource limits, debugging and tenant isolation [11]. 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" [3][12]. 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 [23]. 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 [24]. Both currently assume users comfortable running code locally, inspecting permissions and accepting the risks [16]. 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 [17]. 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 [18][19]. 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 [20]. 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 [21][22]. Runtimewire also notes Cloudflare has an infrastructure reason to like the thesis, which is worth holding in mind when reading it [4]. 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 [11].

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence44
Adoption21
Hype gap+24
Incentives68
Confidence52
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    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.

    Reported SupportedView cited source
  2. [2]

    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.

    Reported SupportedView cited source
  3. [3]

    Morrell wrote: "LLMs radically lower the cost of authoring extensions, and modern sandbox primitives lower the deployment cost and provide good security boundaries. We can build our app as a solid, accountable core, and allow users to safely extend it in many directions by having LLMs fill in the missing pieces."

    Reported SupportedView cited source
  4. [4]

    Runtimewire's account of the essay states under a section heading that Cloudflare has an infrastructure reason to like Morrell's thesis; the supplied text is cut off before the explanation.

    Reported SupportedView cited source
  5. [5]

    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.

    Reported SupportedView cited source
  6. [6]

    Software teams prioritize features that serve the largest groups of customers; requests farther down the demand curve wait, remain manual, or never ship.

    Reported SupportedView cited source
  7. [7]

    Adding every requested feature would eventually leave the interface carrying the accumulated preferences of thousands of unrelated users.

    Reported SupportedView cited source
  8. [8]

    Morrell's examples include a read-it-later service sending every saved article longer than 4,000 words to an e-reader, a research tool finding new papers in a narrow field each week and adding summaries, and an agent repairing a parser that consistently mishandles one publication.

    Reported SupportedView cited source
  9. [9]

    Morrell's proposal depends on a runtime that can keep generated code within a controlled boundary while still allowing it to perform useful actions.

    Reported SupportedView cited source
  10. [10]

    The host application would retain responsibility for access, reliability and the data exposed to an extension.

    Reported SupportedView cited source
  11. [11]

    The difficult questions in Morrell's essay involve deployment, permissions, resource limits, debugging and tenant isolation.

    Reported SupportedView cited source
  12. [12]

    Simon Willison's post quoting Morrell's essay is dated 19th August 2026, one day after the essay's August 18 publication.

    Derived SupportedView cited source
  13. [13]

    Pi, which Morrell points to as his clearest working example, is an open-source terminal coding-agent harness published under Earendil Works.

    Reported SupportedView cited source
  14. [14]

    Pi exposes hooks for tools, commands, events and its terminal interface, and users can ask Pi to write a TypeScript extension, reload it during a session and package the result for others.

    Reported SupportedView cited source
  15. [15]

    Pi's design treats features as optional modules rather than permanent additions to the core.

    Reported SupportedView cited source
  16. [16]

    Projects such as Pi and OpenCode currently expect users to be comfortable running code locally, inspecting permissions and accepting the risks that follow.

    Reported SupportedView cited source
  17. [17]

    Accountants, doctors, lawyers and support staff may have highly specific workflows but cannot reasonably be expected to administer arbitrary local code, so reaching them requires the host application to absorb the security and operational burden.

    Reported SupportedView cited source
  18. [18]

    Pete Koomen, the Optimizely co-founder who is now a Y Combinator general partner, described the gap under the label "Small Software".

    Reported SupportedView cited source
  19. [19]

    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.

    Reported SupportedView cited source
  20. [20]

    Morrell moves the Small Software argument inside existing products: a SaaS provider could supply the trusted data, interface and runtime, then let generated extensions handle the peculiar last mile.

    Reported SupportedView cited source
  21. [21]

    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 was a frontend engineer at Facebook and Recurly.

    Reported SupportedView cited source
  22. [22]

    Morrell's Heroku tenure lasted about five years.

    Derived SupportedView cited source
  23. [23]

    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.

    Reported InsufficientView cited source
  24. [24]

    OpenCode is moving in a similar direction with an internal plugin architecture.

    Reported InsufficientView cited source

Sources

2 independent publishers whose own reporting we read for this story.

  1. runtimewire.com

    1 article · August 19, 2026

    Cloudflare engineer proposes web apps whose users generate the missing features
  2. simonwillison.net

    1 article · August 19, 2026

    Quoting Jeremy Morrell

Topics and entities

Topics

  • AI-Generated Code Security
  • SaaS Product Architecture and Roadmap Strategy
  • Sandboxing and Tenant Isolation
  • Coding Agent Harnesses
  • LLM-Extensible Software

Entities