The entrepreneurial venture that lost its bet 10 years ago has been revived by AI, and in the future everyone will be able to modify their own apps.

All the long articles I have bookmarked are synced to my e-reader.

I scan arXiv every week, save all papers related to my research direction, and tag them properly.

The websites I visit frequently always return garbled text when scraped, so I write a dedicated parser for it.

This is the "exclusive requirement" of Jeremy Morrell, Chief Engineer at Cloudflare, none of which can be fulfilled by the reading app he currently uses.

What he wants is that, after he says these few words, an AI bot can generate the corresponding snippets of code, attach them to the pre-reserved extension points of the software, and make them run automatically.

After the development is done, the extension can be shared easily, and anyone who needs it can take it for use.

This is exactly what an ideal software looks like in his mind: Extensible Software.

Morrell believes that the vast majority of web software we use today is static.

This "static" does not refer to web page technology, but means that you cannot modify its underlying logic.

All features are finalized on the release date, users can only use them as they are, with no room for modification.

AI has changed all of this.

It is no longer a dream that everyone can modify their own apps.

The user says "add the feature I need", the computer adds it on the spot, and the user replies "nice". Morrell says this is exactly the software he wants.

Why those features you have been craving for are never developed

Because you are the only person in the whole world who wants that feature.

Developers have limited time and attention, so they only develop features that serve the largest user groups.

Sometimes, even if they want to develop all the features, they cannot make it.

There is an upper limit to the complexity of the interface. Every additional feature will cause unnecessary trouble for users who do not need it.

If the audience of this feature is only a few hundred people, it will instead make the product harder to use for the remaining millions of users.

These two constraints have been a dead knot that product managers have struggled to untangle for the past two decades.

User requirement distribution of map software. The left side shows navigation questions that all users ask, and the long tail on the right side refers to niche requirements that vary from person to person.

The small feature you want in a certain app is not impossible to develop, but it is not cost-effective to make it.

In the past year, since users gained the vibe coding capability, everything has changed.

The cost of making a tool that only serves one single person has become so low that it is negligible.

Pete Koomen from Y Combinator calls this kind of tools "Small Software".

Y Combinator talks about small software: this kind of tool usually serves only one person or a small group of people.

Accountants, doctors, lawyers, and thousands of other professions can all have their own handy "small software".

Obviously, if you want more people to use AI agents, you cannot expect to turn all of them into engineers.

It is the software that needs to be modified.

The cost of writing extensions has dropped to zero, but there is no proper place to host them yet

As code becomes easier to write, a problem arises: where to put the code after it is finished.

Many web products today leave webhooks as the entry point for users, which has an unreasonably high threshold: you have to run a whole set of independent services on your own, and deal with all kinds of unexpected troubles in the delivery process.

Morrell believes that to truly run untrusted code in your system, you need to go through five stages.

The first stage is cost.

Assume that there are one million users, each running their own few lines of code. If you open a separate container for each user, the cost will be completely unaffordable.

The standard given by Morrell is: when the code is not called, the cost is approximately zero; each call only costs a fraction of a cent.

In addition to compilation, file storage and log collection, the maximum number of users that a single machine can host depends entirely on one indicator: memory overhead.

The second stage is cold start.

The user code runs on the critical path of responding to requests, and users cannot wait a minute for the container to start. The ideal cold start latency should be at the level of single-digit milliseconds. The requirement can be relaxed for tasks that only run scheduled jobs or event callbacks.

The third stage is quota limit.

You can never guess what users will write. Morrell shared a true story he heard at Heroku.

Back then, there was a very popular beginner tutorial that taught newbies to deploy their first program online step by step. The program in the tutorial only had two lines of code: an infinite loop that kept printing "hello world".

An application appeared out of nowhere, spitting millions of lines of logs per second from the very first second it was born, and it would never stop.

The newbie who followed the tutorial had no idea about this, and was still viewing the real-time logs, expecting normal content to scroll on the screen.

Therefore, every indicator must have a hard upper limit, including how much CPU is used, how much memory is occupied, how many network requests can be sent out, the size of each request, how much content is returned, and how many logs can be written per second.

The fourth stage is isolation, which has two layers.

Crashes, infinite loops, and crazy memory application must not affect any other users. Malicious code cannot escape, cannot snoop on other tenants, and must be able to defend against speculative execution attacks such as Spectre.

The fifth stage is that the code must be able to actually work. Code that cannot touch any resources is useless.

From giving keys to giving a door that can be pushed open

How to make untrusted code work without giving away all your core assets.

Morrell broke down the three generations of solutions in the industry.

The first generation solution is to directly give API keys.

Morrell believes that this kind of flexibility is very dangerous. The code that gets the key can send data to a third party via POST immediately; even if it does not steal data, your infrastructure can be used to launch DoS attacks on others at any time.

The second generation solution adds a proxy layer.

Users get an opaque token that is only meaningful to the proxy; after the proxy verifies the token, it replaces it with the real credential and forwards the request, and implements whitelist and rate limiting at the same time.

This is indeed much safer than the first generation, but the cost lies in maintenance. If you want to narrow the permission to only allow part of the operations, you have to write filtering logic in the proxy, and keep modifying it as the upstream API evolves.

Morrell attached a code example in his article. Even for a single operation of "reading an approved email", the code is already very long and difficult to test.

Moreover, it is almost impossible to cover all possible scenarios of this kind of logic. You can never guess what users will do.

The third generation is the key: capability.

Instead of giving keys or addresses, you directly hand over a ready-made function. For example, the function of "retrieve that approved email" can only complete this single action, and cannot do anything else.

The user's code only has access to these few functions. The credential never enters its scope. Even if it gets the data, there is no channel to send the data out.

The first two lines are the code of the platform itself, where the key is stored. The function below is the code written by the user, who never even sees what the key looks like.

There is an additional benefit: passing a TypeScript capability definition to the large model saves more tokens and is more accurate than dumping a bunch of JSON in OpenAPI format.

Therefore, the real threshold is not to let AI write code, but to decide what resources this code can access.

There are four paths, none of which is free

The question of whether extensions can be written has had an answer 20 years ago. What the large model changes is who can write them.

Morrell listed four paths:

The lightest one is the embedded interpreter: Lua, QuickJS, or even a self-developed one.

The next level is V8 Isolates.

Google has invested a huge amount of money and manpower in the security hardening of V8, so directly using it can save you the trouble of reinventing the wheel.

Products on this path include Cloudflare Dynamic Workers, Node's isolated-vm, and Rivet's secure-exec.

The third level is MicroVM.

It removes all the emulation of USB, graphics card and disk in the full virtual machine, leaving only the skeleton. It has the strongest isolation capability, can run binaries, and has complete POSIX support, but the cost is significantly higher.

Firecracker and libkrun both belong to this level.

The fourth level is WASM plus WASI.

WebAssembly was a blank sheet of paper from the very beginning, it does not even have modules for sending HTTP requests or reading environment variables, and all permissions are explicitly granted by the host.

From a security perspective, this is the most perfect starting point, but the cost is that the toolchain is much more complex.

These four paths are not mutually exclusive.

WASM can run in V8 Isolates, and can also run in MicroVM. Even if you use V8 Isolates or WASM as the isolation boundary, MicroVM is still useful in links such as compilation, packaging, and extension testing.

Morrell tested this set of architecture himself. He transformed his static blog into a demo, and joked that it is "the world's smallest vibe coding platform".

Essentially, it is a customizable scraper: given a URL, it fetches the content, and hands it over to the user code together with several pre-granted tools, so that you can directly modify the source code and run it.

The idea that lost the bet 10 years ago was revived by AI

Ten years ago, Kenton Varda, now the technical lead of Cloudflare Workers, launched a startup project called Sandstorm.io.

Its proposition sounded a bit strange back then: every document you open runs in its own sandbox instance; the program cannot access anything that you do not manually pass to it. No keys are issued, only capabilities are issued.

This project did not succeed.

Varda later reviewed the reasons for the failure: no one had the patience to manually package the software one by one into that form.

Ten years passed. On August 5, 2026, Cloudflare re-open sourced this set of architecture under the Apache 2.0 license, named Cloudflare OS.

Cloudflare OS, open sourced under Apache 2.0 license on August 5, 2026. The bet Sandstorm.io made ten years ago is back in a new shell.

Varda wrote on X that day: this is almost the culmination of my ten-year secret grand plan.

The patience he lacked back then has been supplemented by AI.

Software is really going to become "soft"

OpenAI open sourced the Codex agent framework in "Codex as a Platform", which talks about almost the same thing:

Rather than letting every team move their work to a general-purpose coding assistant, it is better to embed the agent into the software they are already using.

It can be embedded in engineering workflows, operation and maintenance dashboards, security investigation tools, customer service consoles, and many other scenarios.

The division of labor is also very clear: the interface, business context, tools and approval boundaries belong to the application side, and the agent loop and sandbox execution belong to the framework.

In their sample application Relay, an agent is placed next to the freight dashboard, connected to the application's own MCP tools, and manual approval is required before modifying the waybill.

Now many companies are encouraging their employees to develop tools via vibe coding, which is the right direction, but the trouble will come later.

Who will maintain hundreds or thousands of such applications? How to ensure that it only accesses the data it is supposed to get? Who sets the permission scope of the access token, and who will perform token rotation? Will the customer information be accidentally written into third-party logs? What about GDPR compliance?

The answer given by Morrell is: give them a deployment environment where there are no tokens that can be leaked at all, and let the platform team take full control of data access to ensure compliance.

If this thing really succeeds, the work of product managers will change.

You do not have to cover all long-tail requirements, but you must design stable extension points, capability interfaces, and make long-term commitments to compatibility. If the vendor does not actively open this entry, users cannot extend the software at all.

Morrell has been working in the platform industry for almost ten years, and he