Software's death spiral: users file requests, and years later, zero features ship

The talk didn't open with the product. It opened with a story that hits home for anyone who has ever worked at a software company.

A developer ships an app to users. Some are happy; others say it's not quite there without an extra feature. The user goes to the developer's stand-in, the product manager, who files the request into Jira — where it promptly sinks without a trace.

Every once in a while, a PM wants the feature themselves, so it makes it onto a roadmap. The developer builds these things one by one, and each one serves only a tiny handful of people. Each also crams a few more if-statements into the code. The code gets messier, and the features get more boring.

Then the developer says: we need a rewrite. We need a new architecture with a plugin system, so every feature becomes a plug-in and the core stays clean. Work begins on the new architecture. Requests keep coming in, and the reply becomes: “Well, once the plugin system is ready, this will be easy. Doing it now would just mean redoing it later.”

This story is the foundation of the entire talk. The loop doesn't stop because of anyone's lack of effort. Its root cause is a single codebase having to accommodate everyone's needs — a premise that can now be overturned.

Letting AI modify software for everyone hits two walls: locked-down phones, and web apps with only one version

If a user could just tell their own AI agent to write a feature and add it, the loop above wouldn't need to spin. Everyone gets what they need, nobody is held back by someone else's requirements, and the developer's core code stays clean.

So why hasn't this happened yet? Because the foundation we build software on today was never designed with this in mind.

The web did get around Apple and Google, and none of the disasters they keep warning about actually happened. But the web has its own problem: the cloud architecture of the past 25 years has been heading in the direction of “one blessed version, served to everyone.” That's convenient for developers, but it means the user can never change what's in their hands.

How Gadgets works: like Google Docs, but every “document” is a full app

Don't think of this as another vibe coding platform. The closer analogy is an office suite.

Open Google Docs. Hundreds or thousands of documents. You click one, edit it, share it. This is exactly the same — except the documents are called gadgets, and each gadget is a full app with code inside.

He gets a lot of emails in Spanish but doesn't speak it, so he built a little tool to filter them. He needed to keep an eye on code awaiting his review on GitHub, so he built a tracker. These aren't products. They're made to be used once, possibly never opened again.

Blueprint: export the code, and others run their own copy

If you build something useful, you can export it as a Blueprint. The export contains code only — no data. Whoever receives it spawns their own copy, and from then on, you each go your own way.

There's another design detail worth calling out: a gadget is tied to one slide deck. If you need three decks, you spawn three instances. This was a deliberate choice. Every gadget can be shared and collaborated on, and since sharing and access control are handled by the platform, not the app, the app itself has no way to mess up the permissions.

To draw one image, Claude first added a feature to the slides app that no human would use

The slides for this talk were generated by a slide deck tool built by his colleague, Phillip — a PM at Cloudflare. According to Kenton, Phillip had an AI build the whole thing in an afternoon.

Kenton gave Claude a Google Doc link containing all the slides he wanted. Then he added one sentence. And that sentence is the key:

If you need to make new features to the slide application itself in order to support these slides, then feel free to do that.

The original instruction, as recounted in the talk

Claude actually did it. It read the app's entire codebase and the document, then added two small features first: slide three needed strikethrough formatting, which the app didn't have, so it added it. Some slides needed centered text. Kenton's taste, unlike Phillip's, is fine with centering, and he wanted it — so Claude added that too.

The most interesting part was slides five and six. He wanted a hand-drawn looking cloud diagram, but the app only supported boxes and arrows — no freeform shapes. Claude's solution? It added a feature to the app that lets you paste an SVG into a slide.

“Paste an SVG into a slide” is a feature that's almost useless to a human. Who hand-writes SVG? But for Claude, it was invaluable. It immediately generated the image it needed.

This moment is the clearest illustration of what “personal software” actually means. Software goes from something you receive as a finished product to something you can reshape in the middle of using it — even if the one reshaping it is an AI.

Why it's safe to let an AI change code: two sandboxes, so even broken code can't leak data

But letting an AI paste SVG into a page? Anyone who knows the web will have the same first thought: SVG can contain JavaScript. Isn't that just a security hole?

The answer is, it doesn't matter. The environment is built so that it can't matter.

The result is this: an AI-written UI and an AI-written server. They can talk to each other, and together they render the UI for you. Even if there's a vulnerability in there, there's nothing it can leak to.

There are no significant security holes in this code.

His words from the talk, referring to the sandboxed app code

That sentence is what makes the whole design work. Because a broken change can't cause damage, you can afford to hand the entire job of changing code over to an AI.

The demo hit an error, and accidentally revealed that Cloudflare OS runs on his laptop

So if the security story holds up, where does this thing actually run? His live demo hit an error, and that's where the answer slipped out.

He typed a prompt asking the system to make a “silly counter app.” An error popped up. No network in the venue. He was unbothered — because the whole stack was running on his own laptop. No internet needed.

Worth pausing on his résumé here: Workers has millions of developers and serves trillions of requests a day. This whole foundation is the project he started when he joined Cloudflare in 2017, and the one he's still leading.

What makes this possible is workerd — the open-source runtime behind Cloudflare Workers. You can install it on your own machine or server and run it there. Every part of Cloudflare OS, except the LLM itself, runs on Workers.

What he's genuinely excited about is very specific: he's already integrated Home Assistant and Spotify. He wants to move the whole stack into his basement and run his home automation with it.

The plan was to open-source right after the talk. One week before, the CTO pulled the plug. It shipped 5 weeks later.

So when can you get your hands on it? That's what he apologized for at the end of the talk.

When he submitted the talk proposal months ago, this was a side project. The plan was to come, give the talk, and then throw the code up on GitHub on the way home. Anyone could download it and play.

But in the weeks before the talk, the project gained serious momentum inside Cloudflare. It became an official project. One week before the talk, on a Thursday, Cloudflare's CTO, Dane, called him into a room and said: don't just throw this out there. The launch needs to be more deliberate. Hold it a few weeks.

He was annoyed — the talk abstract already promised open-sourcing. So he had to stand on stage and say: sorry, I can't release this today, but it's coming very soon.

The talk was on June 30. Cloudflare OS was open-sourced on August 5. Almost exactly five weeks apart.

If a user could just have their own AI add the feature they need, that whole loop would stop spinning. The problem is two walls in the way. Apple and Google have held the first for 15 years — there are now only five companies on earth that can ship mobile apps. In his words, in the US it's easier to buy a gun than to install an unsigned app on your own phone. The web got around the first wall, but ran into the second:

The whole thing feels like an online document tool. Each gadget you open is a standalone app that runs code. Finished something? Share the code (not the data). The recipient spawns their own copy, and from then on you each go your own way. Who can see and edit is enforced by the platform — the app never touches that layer.

The slides for this talk were made by giving Claude a link to a Google Doc. He added one sentence: if you need to add features to the app itself to support these slides, feel free. Claude read the entire codebase and the doc, then added strikethrough and centered text. The best part was the hand-drawn cloud. The app only supported boxes and arrows.

SVG can contain JavaScript. So isn't that a vulnerability? His answer: it doesn't matter. The environment is built so a vulnerability can't get out.

The live demo of a counter app errored out. The venue had no network. He wasn't bothered, because the entire system was running on his own laptop, using workerd — the open-source Workers runtime that can run on any machine. Apart from the LLM, everything runs on Cloudflare Workers. No databases; state lives in Durable Objects. No long-running containers; everything uses Dynamic Workers.

The original plan was to put the code on GitHub right after the talk. A week before, the CTO Dane called him in and said the launch needs to be more deliberate — hold it a few weeks. He apologized on stage and said it would be out soon. The talk was June 30. Cloudflare OS shipped August 5. About 5 weeks apart.