I’m building one of these Podda [1], though pointed at households/small communities rather than companies, so ordinary people can keep the apps they’ve made by talking to Claude or ChatGPT and share them with their friends.
Passing code only the things it’s allowed to use works on the server because you start from zero, so our generated code holds no credentials at all and its only way out is a proxy that allows exact origins and methods.
You can’t really do that in the browser. CSP only restricts which origins the code can reach, not the method or the path, so approving one destination means anything the code can read can go anywhere there. The difficult part is that if we're writing an honest consent prompt to our users then it has to say that, and it sounds a lot worse than "allow network access?". This is hard especially when our target users are non/less-technical. There are other versions of the same problem everywhere, like revoking an origin not actually taking effect until a refresh.
We (Cloudflare OS) run an app's client-side code in a null-origin iframe sandbox that is denied access to everything that we can possibly deny access to. Its only communication line to the outside world is via a Cap'n Web RPC session over postMessage() to the parent frame, which in turn forwards the session on to the app's own server, which runs in a Dynamic Worker sandbox on its end. So the app client can only talk to the app server and nothing else.
Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.
So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.
(We would love to get those CSP holes plugged, though...)
This is the right general idea, but it does read as an ad for Cloudflare OS.
Every tech company is scrambling to be the stable foundation for people in enterprise to build cute little one-off apps safely. It's a perfectly fine pattern, but it's hard to imagine a world where Cloudflare becomes the default. Much easier to imagine Google or Microsoft adopting whatever UI/UX patterns work well and tying into enterprise data natively.
As the author I’d say it’s more of an ad for sandboxes + the idea of OCaps
Unless I’ve missed something obvious in my research, Dynamic Workers are the main product implementing this pattern today, but I expect there will be others for all the reasons I laid out in the article.
The doc does read like an ad disguised as an educational content.
DeepSeek is taking on the "OS" (double quoted cuz of a dumb comment in this thread) role with DSH (deepseek harness) for the apps with plugin architectures.
We have reached the point where people want to create frameworks/infrastructures as it was all the rage (actually that comes up ever other year).
By only providing the ideas here, people want to take credits for later is my take on docs like this.
- they can only say, "I was wrong".
I hate that they called it that. I hope they change the name, to me an OS implies... an OS. I don't want to hear marketing excuses about that, I don't need every other company copying CloudFlare butcher a useful descriptor and now we have a bunch of "AI OS" type apps out there. Just call it what it is... an Agent Workspace. They could have called it CloudFlare Agents or something to that effect?
I am the lead engineer on Cloudflare OS (and Cloudflare Workers).
I am also the creator of Sandstorm.io.
And I'm the one calling it a successor. Wasn't some marketing decision -- that's directly from me.
Honestly really interested to know why you feel this isn't accurate.
FWIW, I didn't choose the name Cloudflare OS -- but I did frequently describe Sandstorm as being an OS, back in the day. Sure, it layers on top of Linux, but it's an environment where you install apps and run them, with the platform managing the execution environment, permissions, resource management, etc. That's sort of what an OS does. Cloudflare OS does all that as well.
Awww, I was hoping GP would respond before they realized who they were responding to, could have been a classic exchange in the vein of https://news.ycombinator.com/item?id=35079
I didn't know about Sandstorm, but you might have an easier way conveying this by stating "Created and inspired by Sandstorm.io and its creator." I think the "inspired by" remark is easier for most to understand, and it sells it more if you point out that you're its author.
As for the name, yeah, not really a fan as I noted above.
We're building a collaborative IDE but for notes/tasks as a local-first web app [1], built to be malleable with plugins. In terms of tradeoffs we're taking a middle road I guess: the app is malleable, but plugins stay contained within the web app.
Because of end-to-end-encryption and privacy/ownership concerns, we can't run plugin code on a server node somewhere. But for some types of apps, server-side extensions alone also feel too restrictive. An advantage of a malleable app over just one-shotting a completely custom app (and to be clear I think both will be popular!) is that extending and customizing something is often exactly what you want vs starting over, but you can't really do that when you can't do things like deeply customizing the UI. So you can just ask a (local) agent "add me this functionality" and it will likely be possible.
It's still sandboxed inside the browser though, so this way you can do things like permissions, allowing admins to restrict who installs team plugins and so on (which is also important for malleable multiplayer apps).
As I said elsewhere: The future of tools like github is a platform for manual testing, where you write a prompt, the AI proposes a change and you can experiment with the UI and attach notes for the next iteration. AI can take user requests, prioritize, aggregate into tickets, and turn them into pull requests.
For a lot of end users, this may be enough, no programmers will be needed to get software built and shipped. For the rest, it lets programmers fill the remaining gaps, doing the manual testing to make sure the system works correctly, test for regressions and make sure the LLMs add those to the test suite, and then manage monitoring the rollouts. The bulk of development work going forward is manual verification that the LLM understood the user request correctly.
I'm not as sure that this idea of plugins will pan out; AI will want to make changes to support what it produces.
I built a Lisp interpreter and hosted it on an OCaml http core, and it does exactly this for me.
I've been using it for the last three months for basically all my computing. I always wanted a Smalltalk type environment, and this finally scratches this itch.
Creating an endpoint is just defining a lisp function.
There's still a billion things to clean up but it works really well.
My LLMs say that if you followed this same pattern in pure clojure or racket it would be comfortably <10k lines of code.
That said, I do enjoy implementing my own lisp and I think the OCaml core gives it some stability and security.
I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
Maybe it won't be a program, but just some LLM context as some data dump.
This program or context will take up the role of a PM. Developers will refer to the program, or ask context for clarifications and the developer will build the actual program with or without the help from LLMs.
I expect this to be automated too, and in the end boil down to paying for more tokens to fix the program.
Code too messy to be editable by an LLM is already too horrible for humans to touch. Fixing vibecoded software as a service will boil down to reverse-engineering requirements from the messed up program, and prompting a better model to design it properly and rewrite.
Eventually models will be trained to do this themselves, so it won't be a service you ask a dev for, it will be an extra charge on your AI subscription.
1. In "verifiable" domains ML is not limited by training data any more. Models can help generate the training data and/or learn the objective through reinforcement learning.
2. Yes, because the most capable model is the only one that can charge a premium. The rest is a commodity.
> I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
That's not gonna happen :-/ I've already had clients tell me they only want it modified, and their expectation is that it's only a days worth of work to make it work.
Who knows. I don't take on any dev work anymore that involves modifying existing applications, anyway. Too many have been of the form "Look, we did 99% of it, we just need you to do the 1% remaining" with the expectation that finding and fixing bugs in a vibed 90kSloC application is only a few minutes to a few hours of human labour.
In reality, if you bring me something that Claude Code itself can't make changes to without breaking, it's going to be at least a week of billable hours before I know where to start.
That is sad. But if what I imagine is true, they will grow wiser after they have lost enough $$$ with scammers who agree to do it in a day and pocket the funds and give back an even more broken program.
How is what you're describing technically different than the quoted section? GP was correct, they just didn't realize that they were describing something bad instead of something good.
the program itself is kind of useless. the client will send it anyway to demonstrate a proof of concept but hopefully the dev will build from scratch
what's important is the spec. the poc isn't a spec because the dev is being hired exactly because that software doesn't solve the problem fully - whatever it has missing is the important bits
this spec will probably be generated by a llm, but there is some noise added. if the client can send their prompt, alongside the whole llm session (maybe with sensitive tool calls redacted), the dev would have everything
> It took me thirty minutes with Codex and GPT-Sol. The thing is fast, it does not ask me for anything, and it does the one job I wanted: it launches applications.
This is quite funny, actually. When I wanted something similar (just play MP3s, without playlists, special indexes, etc), it also took me 30 minutes.
In 2002.
I still use it daily - a wish application displays entries matching the filter using the locatedb to get a list of all MP3s to find them and mpg123 to play them. This is the application that I have used the longest in my life, unchanged and unmodified from day 1, and it still tickles me that it took 30m.
I'm pretty certain, had LLMs not existed, that I can make an application finder using locatedb (perhaps store a private index as well) and a GUI in about 30m using wish as the front-end.
(Just for reference, here's my no-frills MP3 player)
---------------------------------------------
I assume the 30 minutes didn't involve learning how to use wish.
There are tons of apps I could build in 30 minutes using a development environment I'm familiar and productive with already, but LLMs don't have that restriction.
> I assume the 30 minutes didn't involve learning how to use wish.
>
> There are tons of apps I could build in 30 minutes using a development environment I'm familiar and productive with already, but LLMs don't have that restriction.
Here's the thing - if you never learned to use $FOO, it is closed off as an option to you forever, even with LLM help.
I'm going to be a lot better at designing personal-use software via an LLM than someone who doesn't have 30 years of experience writing software for money, because I learned things (like wish) which can be leveraged via LLMs to produce the output artefact faster and more reliably.
For personal-use software, if all you know is HTML, CSS and Javascript, then all you can produce is electron-based crap as the smallest unit of software. Someone like me, OTOH, can produce small and tight software because I programmed in Delphi (now Lazarus), Qt, Tcl/Tk, etc in the past, and they are still viable.
I recall seeing an electron-based vibed app recently on a ShowHN that, I thought at the time, could have be completed using a small bash script calling Zenity.
The problem is what happens when people like myself (and yourself, too) are no longer around?
All the software is going to converge towards being crap; if there is no one telling the LLM that a specific task can be completed using Lazarus with zero 3rd party deps, all tasks are going to get completed using Rust with a few thousand create deps talking to an electron-based app that has a few thousand JS deps (and maybe some CSS frameworks thrown in for good measure).
I doubt that future. Traditionally, only hardcore power users are interested in extending software. Normal end users want reliable software that does what they want it to do. Some of them also want a certain amount of shiny buttons and UI effects to look at. I'm not saying there is no market for heavily personalized software, just that it is not going to be big. Of course, people also want AI that acts like a friend or expert and does amazing things. However, I don't believe the two worlds mix well. IMHO, AI substitutes a person working for you whereas traditional software is a tool that persons and AI use.
The experience can be vastly different than deeply configuring a system like a power user. My nontechnical, 87-years-old grandfather is putting together apps to help him with his language practice. He uses Google iirc. The chatbot is a familiar interface since his time working did overlap with IRC, email, early internet, yada yada.
I don’t want to necessarily argue about merit or quality, but I have seen that custom software can be accessible to a general audience.
This is exactly what I did a few days ago: I created my own "small software" to solve my own need: https://news.ycombinator.com/item?id=49330939. Let me tell you: it works, it works really well, and I don't feel like, "Hey, the options out there are better."
In fact, the options available are outdated in terms of frameworks and bloated with features to please all kinds of customers. They try to do everything but end up doing everything poorly.
I’m building one of these Podda [1], though pointed at households/small communities rather than companies, so ordinary people can keep the apps they’ve made by talking to Claude or ChatGPT and share them with their friends.
Passing code only the things it’s allowed to use works on the server because you start from zero, so our generated code holds no credentials at all and its only way out is a proxy that allows exact origins and methods.
You can’t really do that in the browser. CSP only restricts which origins the code can reach, not the method or the path, so approving one destination means anything the code can read can go anywhere there. The difficult part is that if we're writing an honest consent prompt to our users then it has to say that, and it sounds a lot worse than "allow network access?". This is hard especially when our target users are non/less-technical. There are other versions of the same problem everywhere, like revoking an origin not actually taking effect until a refresh.
[1] https://podda.app
For client side there is https://hardenedjs.org/
And Cloudflare OS does some fancy things with iframes + capnweb iirc
Will take a deeper look into the Cloudflare OS source - thanks!
We (Cloudflare OS) run an app's client-side code in a null-origin iframe sandbox that is denied access to everything that we can possibly deny access to. Its only communication line to the outside world is via a Cap'n Web RPC session over postMessage() to the parent frame, which in turn forwards the session on to the app's own server, which runs in a Dynamic Worker sandbox on its end. So the app client can only talk to the app server and nothing else.
Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.
So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.
(We would love to get those CSP holes plugged, though...)
WebRTC is coming down the pipe into CSP hopefully soon: https://www.w3.org/TR/CSP3/#directives-other
This is the right general idea, but it does read as an ad for Cloudflare OS.
Every tech company is scrambling to be the stable foundation for people in enterprise to build cute little one-off apps safely. It's a perfectly fine pattern, but it's hard to imagine a world where Cloudflare becomes the default. Much easier to imagine Google or Microsoft adopting whatever UI/UX patterns work well and tying into enterprise data natively.
As the author I’d say it’s more of an ad for sandboxes + the idea of OCaps
Unless I’ve missed something obvious in my research, Dynamic Workers are the main product implementing this pattern today, but I expect there will be others for all the reasons I laid out in the article.
The doc does read like an ad disguised as an educational content.
DeepSeek is taking on the "OS" (double quoted cuz of a dumb comment in this thread) role with DSH (deepseek harness) for the apps with plugin architectures.
We have reached the point where people want to create frameworks/infrastructures as it was all the rage (actually that comes up ever other year).
By only providing the ideas here, people want to take credits for later is my take on docs like this. - they can only say, "I was wrong".
> Cloudflare OS
I hate that they called it that. I hope they change the name, to me an OS implies... an OS. I don't want to hear marketing excuses about that, I don't need every other company copying CloudFlare butcher a useful descriptor and now we have a bunch of "AI OS" type apps out there. Just call it what it is... an Agent Workspace. They could have called it CloudFlare Agents or something to that effect?
It's not ready yet, but I vibe on an os flavor for agents and humans (and local ai) based on debian.
plebian-os.com
Well that's an actual OS, though you might be better off making packages to install your solution on to standard Debian / Ubuntu?
It isn't the only wrong thing they're calling it. They're also calling it a successor to sandstorm.io, which it clearly is not.
Eh? Why do you feel it's inaccurate to call it a successor to sandstorm.io?
For the record.
I am the lead engineer on Cloudflare OS (and Cloudflare Workers).
I am also the creator of Sandstorm.io.
And I'm the one calling it a successor. Wasn't some marketing decision -- that's directly from me.
Honestly really interested to know why you feel this isn't accurate.
FWIW, I didn't choose the name Cloudflare OS -- but I did frequently describe Sandstorm as being an OS, back in the day. Sure, it layers on top of Linux, but it's an environment where you install apps and run them, with the platform managing the execution environment, permissions, resource management, etc. That's sort of what an OS does. Cloudflare OS does all that as well.
Awww, I was hoping GP would respond before they realized who they were responding to, could have been a classic exchange in the vein of https://news.ycombinator.com/item?id=35079
I didn't know about Sandstorm, but you might have an easier way conveying this by stating "Created and inspired by Sandstorm.io and its creator." I think the "inspired by" remark is easier for most to understand, and it sells it more if you point out that you're its author.
As for the name, yeah, not really a fan as I noted above.
FWIW none of Cloudflare's marketing material mentions the Sandstorm connection, it was something I said in personal tweets:
https://x.com/KentonVarda/status/2084990137180590572
We're building a collaborative IDE but for notes/tasks as a local-first web app [1], built to be malleable with plugins. In terms of tradeoffs we're taking a middle road I guess: the app is malleable, but plugins stay contained within the web app.
Because of end-to-end-encryption and privacy/ownership concerns, we can't run plugin code on a server node somewhere. But for some types of apps, server-side extensions alone also feel too restrictive. An advantage of a malleable app over just one-shotting a completely custom app (and to be clear I think both will be popular!) is that extending and customizing something is often exactly what you want vs starting over, but you can't really do that when you can't do things like deeply customizing the UI. So you can just ask a (local) agent "add me this functionality" and it will likely be possible.
It's still sandboxed inside the browser though, so this way you can do things like permissions, allowing admins to restrict who installs team plugins and so on (which is also important for malleable multiplayer apps).
[1] https://thymer.com
As I said elsewhere: The future of tools like github is a platform for manual testing, where you write a prompt, the AI proposes a change and you can experiment with the UI and attach notes for the next iteration. AI can take user requests, prioritize, aggregate into tickets, and turn them into pull requests.
For a lot of end users, this may be enough, no programmers will be needed to get software built and shipped. For the rest, it lets programmers fill the remaining gaps, doing the manual testing to make sure the system works correctly, test for regressions and make sure the LLMs add those to the test suite, and then manage monitoring the rollouts. The bulk of development work going forward is manual verification that the LLM understood the user request correctly.
I'm not as sure that this idea of plugins will pan out; AI will want to make changes to support what it produces.
I built a Lisp interpreter and hosted it on an OCaml http core, and it does exactly this for me.
I've been using it for the last three months for basically all my computing. I always wanted a Smalltalk type environment, and this finally scratches this itch.
Creating an endpoint is just defining a lisp function.
There's still a billion things to clean up but it works really well.
My LLMs say that if you followed this same pattern in pure clojure or racket it would be comfortably <10k lines of code.
That said, I do enjoy implementing my own lisp and I think the OCaml core gives it some stability and security.
I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
Maybe it won't be a program, but just some LLM context as some data dump.
This program or context will take up the role of a PM. Developers will refer to the program, or ask context for clarifications and the developer will build the actual program with or without the help from LLMs.
I expect this to be automated too, and in the end boil down to paying for more tokens to fix the program.
Code too messy to be editable by an LLM is already too horrible for humans to touch. Fixing vibecoded software as a service will boil down to reverse-engineering requirements from the messed up program, and prompting a better model to design it properly and rewrite.
Eventually models will be trained to do this themselves, so it won't be a service you ask a dev for, it will be an extra charge on your AI subscription.
>Eventually models will be trained to do this themselves
That is what I wonder. Two things.
1. Is there enough training data in that format, to do it?
2. Is there enough incentive for the LLM companies to do it? I mean they got to charge the client for the tokens upto that point..so..
1. In "verifiable" domains ML is not limited by training data any more. Models can help generate the training data and/or learn the objective through reinforcement learning.
2. Yes, because the most capable model is the only one that can charge a premium. The rest is a commodity.
> I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
That's not gonna happen :-/ I've already had clients tell me they only want it modified, and their expectation is that it's only a days worth of work to make it work.
Did they end up getting what they wanted?
This LLM stuff is still quite new; I wouldn’t be surprised if people are still asking for your help wrong.
> Did they end up getting what they wanted?
Who knows. I don't take on any dev work anymore that involves modifying existing applications, anyway. Too many have been of the form "Look, we did 99% of it, we just need you to do the 1% remaining" with the expectation that finding and fixing bugs in a vibed 90kSloC application is only a few minutes to a few hours of human labour.
In reality, if you bring me something that Claude Code itself can't make changes to without breaking, it's going to be at least a week of billable hours before I know where to start.
That is sad. But if what I imagine is true, they will grow wiser after they have lost enough $$$ with scammers who agree to do it in a day and pocket the funds and give back an even more broken program.
How is what you're describing technically different than the quoted section? GP was correct, they just didn't realize that they were describing something bad instead of something good.
the program itself is kind of useless. the client will send it anyway to demonstrate a proof of concept but hopefully the dev will build from scratch
what's important is the spec. the poc isn't a spec because the dev is being hired exactly because that software doesn't solve the problem fully - whatever it has missing is the important bits
this spec will probably be generated by a llm, but there is some noise added. if the client can send their prompt, alongside the whole llm session (maybe with sensitive tool calls redacted), the dev would have everything
> It took me thirty minutes with Codex and GPT-Sol. The thing is fast, it does not ask me for anything, and it does the one job I wanted: it launches applications.
This is quite funny, actually. When I wanted something similar (just play MP3s, without playlists, special indexes, etc), it also took me 30 minutes.
In 2002.
I still use it daily - a wish application displays entries matching the filter using the locatedb to get a list of all MP3s to find them and mpg123 to play them. This is the application that I have used the longest in my life, unchanged and unmodified from day 1, and it still tickles me that it took 30m.
I'm pretty certain, had LLMs not existed, that I can make an application finder using locatedb (perhaps store a private index as well) and a GUI in about 30m using wish as the front-end.
(Just for reference, here's my no-frills MP3 player) ---------------------------------------------
I assume the 30 minutes didn't involve learning how to use wish.
There are tons of apps I could build in 30 minutes using a development environment I'm familiar and productive with already, but LLMs don't have that restriction.
> I assume the 30 minutes didn't involve learning how to use wish.
>
> There are tons of apps I could build in 30 minutes using a development environment I'm familiar and productive with already, but LLMs don't have that restriction.
Here's the thing - if you never learned to use $FOO, it is closed off as an option to you forever, even with LLM help.
I'm going to be a lot better at designing personal-use software via an LLM than someone who doesn't have 30 years of experience writing software for money, because I learned things (like wish) which can be leveraged via LLMs to produce the output artefact faster and more reliably.
For personal-use software, if all you know is HTML, CSS and Javascript, then all you can produce is electron-based crap as the smallest unit of software. Someone like me, OTOH, can produce small and tight software because I programmed in Delphi (now Lazarus), Qt, Tcl/Tk, etc in the past, and they are still viable.
I recall seeing an electron-based vibed app recently on a ShowHN that, I thought at the time, could have be completed using a small bash script calling Zenity.
The problem is what happens when people like myself (and yourself, too) are no longer around?
All the software is going to converge towards being crap; if there is no one telling the LLM that a specific task can be completed using Lazarus with zero 3rd party deps, all tasks are going to get completed using Rust with a few thousand create deps talking to an electron-based app that has a few thousand JS deps (and maybe some CSS frameworks thrown in for good measure).
I doubt that future. Traditionally, only hardcore power users are interested in extending software. Normal end users want reliable software that does what they want it to do. Some of them also want a certain amount of shiny buttons and UI effects to look at. I'm not saying there is no market for heavily personalized software, just that it is not going to be big. Of course, people also want AI that acts like a friend or expert and does amazing things. However, I don't believe the two worlds mix well. IMHO, AI substitutes a person working for you whereas traditional software is a tool that persons and AI use.
The experience can be vastly different than deeply configuring a system like a power user. My nontechnical, 87-years-old grandfather is putting together apps to help him with his language practice. He uses Google iirc. The chatbot is a familiar interface since his time working did overlap with IRC, email, early internet, yada yada.
I don’t want to necessarily argue about merit or quality, but I have seen that custom software can be accessible to a general audience.
This is exactly what I did a few days ago: I created my own "small software" to solve my own need: https://news.ycombinator.com/item?id=49330939. Let me tell you: it works, it works really well, and I don't feel like, "Hey, the options out there are better."
In fact, the options available are outdated in terms of frameworks and bloated with features to please all kinds of customers. They try to do everything but end up doing everything poorly.