> It’s become readily apparent that LLMs are really quite excellent at building Software for One. Personal apps that side-step all of the complexity and accountability of enterprise software and are custom fit for a single person’s workflow.
> …
> However most of our existing examples of pluggable software are local software: AI agents, developer IDEs, mods for video games, Blender add-ons, CAD extensions. These tend to be professional tools with a high barrier to entry. The web is the most successful software distribution system in the world. It shouldn’t be left behind. My hypothesis is that there is a new opportunity for Extensible Software on the web.
I don't follow. If this is really supposed to be "software for one", why would it need to be on the Internet? Why does it need a client/server model? Why do I care about "distribution"? People develop for web because native development gets painful when there are many flavours of "native". But you only use one of them yourself, and the LLM isn't bothered by its quirks.
Why not just work on designing pluggable local software that isn't so "professional"?
Data point of 1 but I prefer all my personal software to be web based so I can easily access it from my phone, laptop, and desktop and not worry about syncing things or installing or updating when I switch devices. Also makes it trivial to extend access to family members as needed.
It's very rare that I reach for local software these days.
I run all my apps on my desktop and access them over tailscale. All web apps and I install on phones as PWAs. Super ergonomic.
As for this:
> Local software runs faster
What? Why? Is this some assumption about network requests?
None of my personal software ever has a loading spinner or lag. If it's designed well, each interaction should fit in a single TCP packet so network round trip is imperceptible.
If your web software is slow, that's a choice you've made. Plenty of slow local software around to balance the scales too.
EDIT: Using local files with a web stack is also easy these days. The only con of web software is lacking that native aspect. But native appearance is rare anyway these days with every company just shipping electron bloatware.
No. It’s a claim about the amount of work the computer has to do to show UI. Native programs are simply mmapped into memory then executed. They can start instantly. Web software needs a browser engine. And a JS runtime. And a dom. And - usually - needs to wait for a bunch of network round trips.
Tauri - a rust web view wrapper - once bragged that it only needed 25 thousand syscalls to run hello world, vs the 100 thousand that electron needs. I think they’re both totally nuts. Modern computers are fast enough to absorb the necessary performance hit. But why make the UI slow for no reason?
With websites, the UI still usually ends up looking kinda bad. You can make much nicer UIs by using native controls. And you have access to more APIs! I made a conference schedule iOS app the other day which integrates with the native iPhone calendar. You star an event and it gets automatically added to your system calendar. Beautiful.
The only downside is the native ui frameworks aren’t as good. And they force you to rewrite your app N times for N platforms. But that’s just a tooling problem. I’m a big fan of frameworks like day which let me write once and deploy everywhere, while using system UI components. https://daybrite.dev/
Ah ok. When I talk about fast I am usually referring to user perception rather than clock cycles spent. Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.
For me, it's a law of diminishing returns thing. I would (and have) hand roll assembly if I want actual speed.
But we are talking about personal software. Write once, run everywhere browser's exist with essentially no tooling or complexity or deployment concerns.
What does writing everything in rust get me instead that is worth the significant increase in effort and dev time and deployment?
> Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.
I just don't see any software made with web tech that loads in less than 100ms. Here in Australia, it usually takes longer than that for a single packet to get to the US and back.
The Fastmail iOS app is an embedded web app. A fresh launch on my iphone takes about 3 seconds before emails become visible on screen. On my desktop computer, Spotify loads in about 3 seconds. Discord loads in ~12 seconds. These are all packaged web applications, which can store and cache whatever data they want. And we're talking startup times of several seconds.
There's also ram usage. I just opened spotify out of curiosity on windows. Spotify - as I understand it - uses the platform native browser. Just being open - not even playing anything - spotify sits at about 650-800mb of ram. The DDR5 ram sticks I have currently cost about $30 AUD per gigabyte. So, spotify is reserving about $20 worth of my ram the whole time its open. I can afford that. But I didn't buy all this ram so spotify engineers could be slobs with it. According to a quick google search, Winamp 2 used 4-10mb.
There exist pure native apps which also launch slowly and use a lot of ram. Davinci resolve also takes several seconds to launch. So does intellij. But these are much more complex programs than a music player or chat app.
If you're making tiny apps for yourself, I can definitely see the appeal of using web technology from a deployment standpoint. But if it were up to me, we'd port the web's software deployment model to work with native programs. Make native software as good as web dev and cut the browser out of the picture entirely. If ram costs 5x as much, I wanna see my software start using 5x less RAM when it runs. I just don't see that happening in the browser.
In my case it's "software for the home" but then I work from home and it's stuff I actually use to help me in my day to day work.
And I had "software only for the home" way before coding with LLMs were a thing and... It's just convenient when it's in a browser. Especially now with technologies like SSE push (where I hardly need any JavaScript anymore).
Also "software for one" can be "software for the home" but also "software for the SME" and the home has Linux PCs, an iOS tablet, an Android tablet, Android phones and the wife is on a Mac Mini.
Also even if it was really "just for me", something has to be said about an app one can access when not at home (which is easy to do when it's a webapp).
> Why does it need a client/server model?
I just use SSE push now: hardly any JavaScript and it works totally fine. Sure it's technically client/server but it's not crazy complicated either.
I've worked on medium-sized desktop Java apps (a few hundreds of thousands of lines of code) that were running on the three usual suspects: Linux, OS X and Windows.
Well... I much prefer to write webapps.
Wife and I have got a SME we run together and we use a Webapp I made to do so (now with the help of LLMs too, but I made the app before LLMs).
Don't get me wrong: I consider JavaScript to be one of the suckiest language ever invented and the amateurism of its ecosystem makes me want to vomit. It's not a love-letter to JavaScript: but browsers are very convenient.
Smalltalk also had extensibility for one. But it largely missed the explosion of collaboration when open source code became shareable and people can work on it together.
People also shared Hypercard apps.
I think it is less about client/server and more about how ideas can be shared. Sometimes, data might be shared.
Because there is no matchmaker- someone who finds people who have the same problem- and would be happy to buy it from you- on the condition it works for them so a refund is possible.
No huge company, no huge PR department, just one hobbyist/professional selling a ugly, rough around the edges tooling to other hobbyist/professionals.
I think the real thing is that software for one _business_ is very much in demand (and a bunch of SaaS exists as a release valve for those use cases). And that stuff is hard to get working
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.
FWIW I saw the original posts, knew who wrote them, and know that Cloudflare OS is open source. It's because Sandstorm is about running anyone's apps, while where you introduce it you say this:
> the AI cannot introduce a significant security bug
The AI-authored apps aspect is obviously something that Sandstorm didn't have.
But Cloudflare OS also supports a concept of "blueprints", where, once you've built your app, you create a "blueprint" (a copy of the code) and share it with others, from which they can create their own instances of the app. So it is still very much about sharing apps and running other people's apps, and the sandbox makes this safe and compliant even if you're not sure the app developer knows what they're doing.
I've been saying it to anyone who cares to listen: Salesforce is basically the biggest "Smalltalk" deployment out there. Super malleable, has a lot of ... decent rules for how to get software out into the world, every environment is basically its own universe at one point.
Someone should really attack SFDC from the "malleable Business OS" side of things. Unfrotunately everyone seems to attack it from the CRM side of things and lose the plot a bit.
Def agree that "have the thing I just came up with running in some environment that is sharable" is still a pretty gnarly problem, and LLM stuff doesn't... I don't think they've really made much progress on it.
At one point someone really needs to make an easy to manage box metaphor for all the stuff. It's not Docker. Google scripts is almost there but you really want to have the database be a thing you can drag and drop as well (SQLite people: get excited!)
Dropbox for business apps. If anyone runs with this at least send me an email thanking you for the metaphor.
Having worked with Salesforce deployments over the last two years. I'd only call it malleable as long as you fit in its definition of what's malleable. I'm half-expecting it to have its own definition of a wheel at this point.
Don't you feel like it's still fairly far ahead of other systems, if you buy into the model?
I think there are other systems that kinda get there but SFDC is the only one of these kinds of systems that give you a lot of options on the backend and frontend side of things to just ship your own things and have them be integrated.
Maybe. Honestly, it's just been the number one source of deployment issues in our stack, by a large margin, so that may be the frustration talking. It basically requires us to treat our Salesforce environments very differently from the rest of our technological stack in ways that can be pretty alien to what's pretty standard development best practices in the rest of the industry. To give one specific example, the way some things cannot be expressed through metadata or updated through API makes it very hard to have any kind of repeatability between environments, making things like e2e testing and CD a lot trickier to deal with.
As for your specific question, I'll be honest, I'm not familiar enough with what the competition has to offer, because I tend to avoid these behemoth monolithic locked-in platforms like the plague if I can help it, and my experience with Salesforce so far isn't really making it easy for me to change my mind on the subject.
That's fair, at a previous place I worked at we had SFDC integration and there was definitely a lot of restrictions and pain points there. Especially if you're integrating, it's an uphill battle.
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.
They can, but I don't think they will be of sufficient quality. It is a fundamental thing. You can't generate new information from existing information. It has to come from the real world.
Generating training data using existing models will only help the model to capture the exiting patterns more thourly.
Ultimately the new data, the slight incrimental improvements to the body of code for training) will actually come from humans even though it was written by ais.
ais write 1000 bits of garbage code for 1000 different users one-offs, the users judge that most of those didn't work out but 2 did. Only those good results that humans approved becomes part of the growing body of reference code. The others either get thrown away, or even if they still exist, they are somehow known to be low quality, or at least, not known to be high value.
So an ai wrote some new code that worked and improved the total corpus that other/future ais reference, but it's not just ai output feeding ai input, it's ai output filtered through humans who nixed most of it.
(Maybe exists on github but not used by anyone. It isn't known to be bad, it's just ranked lower, but if nothing else fits as well, it's there to try. That way obscure code that's good eventually becomes known to be good.)
Yes, but how many working code bases do we have. I don't think we have enough number of such high quality code bases to act as training data.
Also, the shitty re-write should also match shitty real-world patterns. Which is quite limit less....So we back to square one. Lack of input from real world.
Clients come and show me their proof of concept, fully vibecoded, because they do not know / do not have the time to take it to prod. Other comments saying this will be automated in the future... may be. But even if that is the case, time and attention are still needed to make things happen.
With the extendended capabilities IA brings, having an IT person in-house makes more sense than ever, even for small shops.
> 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
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.
> Normal end users want reliable software that does what they want it to do.
But how does that contradicts the idea of extendable software? If anything, extendable software will better do what the user wants it to do.
It's just right now we think of extending the software as if it's a complex operation. It looks to me like the article envisions a future, where extending your software is as simple as, say, creating a new google doc or opening a link.
It is doubtable, however, that such level of ease of extendibility can be achieved at all. There might be enough essential complexity, like answering lots of questions, which, I agree, most users won't be doing.
The vast majority of users buy the software that does what they want it to do right from the start. If you reflect on it, you will likely find that this is also what you do. That behavior is not just normal for software, though, it's the standard for almost any product. You have a certain problem or need, look around until you find something that solves the problem or satisfies the need, and then you might buy it.
Think about cars for comparison. Some people like tinkering with them and tuning them. However, most people look for the features they need or desire and buy the car that satisfies their requirements and budget best.
Sometimes extensibility is part of the requirements to solve a problem or fulfill a desire but normally it isn't.
I think people who don't tune their cars also have some very specific requests on what they miss. It's just they never articulate their requests, because the only way to satisfy them would be to spend lot's of time and resources on tinkering.
However, I can see another counter-argument to my claim: not every consumer has specific requests for the product they're buying! Sometimes people are just not sure what they want. In that case, yes, I can agree that customization doesn't help. Moreover, having a limited set of pre-defined products helps to educate a consumer on what their options even are.
So, if a large part of consumers are the ones that don't know exactly what they want, then yes, you're right. I guess the distribution of “know-what-they-want” vs. “don't” depends on the product, although I think generally it tends to be that most people usually don't know.
Anyway, thanks for the good argument! Thinking about other products and industries, as cars, really helped, I missed that.
The long tail of unmet features is real. Most apps serve the common cases well, and LLM-generated extensions could fill that gap without bloating the core product.
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.
Extending software makes it more complex. As you keep adding extensions, the complexity grows until the app is unusable. Doesn't matter if it's built-in or a plugin, result is the same. But there is a proven alternative that works well.
Write completely separate small apps, and it's a different result. You get reliable functionality without an increase in complexity. Don't add a "file search extension" to your application (consider that if any other application wants this functionality, now they have to implement their own extension). Instead you make one completely separate app, called 'grep'. You then call that one 'grep' app, from any application.
It's a very old-fashioned idea to programmers who have only ever known custom-integrated REST APIs and microservices and giant monolithic frameworks. But this old-fashioned idea is the reason AI agents are even useful at all. They call those old-fashioned single-purpose external tools, and suddenly the agent has useful features, no custom extension needed.
Another thing you don't need: "a platform for platforms". There's already a platform designed to run interoperable applications. It's called an Operating System. It runs these little independent things called applications. They all have data object storage input-output access. Even internal communication between processes. And they're all compatible.
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...)
Tangent to the thread; I'm coming across your work after researching cloudflare os this evening, and I gotta say, I am super impressed.
I came across sandstorm a few years back too -- so my mind was blown to learn workers and CloudflareOS are a better implementation of that project.
Cloudflare becoming FedRAMP High recently is a big deal in my little world. I'm trying to learn everything I can about it for our little AI consultancy.
CloudflareOS looks like the sandboxing piece I was just starting to put together -- agents and MCPs behind real security boundaries. Sandboxing is so damn important in this space and most of the other providers ignore it completely or just give it lip service. I think the workers concepts are going to supercharge way more than folks are giving you credit for (in the HN thread a few weeks back there were a lot of dubious folks -- I see it more like the Dropbox announcement).
I hope our paths cross at some point soon. I would love to get more understanding of CF and the roadmap for COS.
I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.
The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).
What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().
For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.
Sandboxed execution is definitely one aspect... But IMO, this is still not secure enough for vibe coders. They will want to have data-driven apps to share among small groups of people, then the security of the sandbox doesn't matter if they expose some external endpoints and if the access control logic which guards data is flawed.
Even if each user gets their own sandbox, they will still want to configure different access rules for different kinds of data which they host.
That said the idea that each user could control and host their own data is interesting and could work. I imagine you could have apps which link data from many different user sandboxes via remote foreign keys.
You could have a centralized data schema controlled by the application owner but the data itself would be held/scattered across a large number of sandboxes.
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.
Me and a Cofounder are building something along these lines on top of K8s. The wisdom that "if give the LLM clear boundaries and you get better results" definitely holds IME, even with frontier models like fable. It's impossible to specify all the guardrails you need to keep models from violating priors without writing the code yourself, so the only move is to remove their ability to do so, or to even recognize that the option exists.
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).
> 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 think it all comes down to a dichotomy that wasn't extremely visible before LLMs: there are, broadly, two kinds of people – those for whom the journey and the learning are the most important, and those for whom those are mere obstacles on the way to the end product.
The two camps both speak as if the other side can't possibly exist. I think they've both always existed, it's just that LLMs have made the distinction plain as day.
I mean if you define anything using web-based technology as crap then sure, but someone could just as easily define Linux GTK apps as being old and janky and then where will we be? LLMs can write Zenity bash scripts just fine, it's up to the person driving it to ask for that instead. How's well does that Zenity bash script work on Android/iOS/windows/ChromeOS/Mac/esp32? We can shit all over people for using technologies we personally wouldn't choose, but it's not like they're aren't reasons for it. It's not 1990 anymore and my computer has gigabytes, not megabytes of ram.
> It's not 1990 anymore and my computer has gigabytes, not megabytes of ram.
And these gigabytes get used up really quickly when the LLM goes brrrr. And with this 500% surge in RAM prices, I don't think it's still enough to just buy more.
As far as that part goes, you're right. However, someone wanting to make $APP work on raspberry pi 1 level of hardware, and complain to the LLM that electron is so laggy as to be unusable, then I also imagine the LLM is capable of suggestion rewriting $APP with $FOO technology that is the tight low-memory CPU-sipping version of $APP. If TSMC falls and we can't make new hardware, that may have to happen, but until such time that it's forced to, it's not going to.
> However, someone wanting to make $APP work on raspberry pi 1 level of hardware, and complain to the LLM that electron is so laggy as to be unusable, then I also imagine the LLM is capable of suggestion rewriting $APP with $FOO technology that is the tight low-memory CPU-sipping version of $APP
I don't think I've ever seen someone's agentic loop actually decide to do a rewrite. Once it sets off down a path, due to how token generation works, it can't actually backtrack easily.
I really enjoy working on my inhouse orchestration tool because it brings me back to the days of working in Smalltalk image where I can tweak my development IDE as I go along.
> "code can only take actions via the references it has been passed"
The cool part is a move to capabilities composed in code brings back everything great about software itself: composability, encapsulation, type systems.
I've been working on this for SQL: instead of giving clients a handle to endpoints, you give them scoped query builders they can compose with (e.g., hand out a scoped `users` object and client can do `users.where(u => u.isActive()).orderBy(u => u.createdAt)`).
The result is you define a data-model (schema, computed columns, relations) and expose that instead of an endpoint per desired client query.
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.
> It’s become readily apparent that LLMs are really quite excellent at building Software for One. Personal apps that side-step all of the complexity and accountability of enterprise software and are custom fit for a single person’s workflow.
> …
> However most of our existing examples of pluggable software are local software: AI agents, developer IDEs, mods for video games, Blender add-ons, CAD extensions. These tend to be professional tools with a high barrier to entry. The web is the most successful software distribution system in the world. It shouldn’t be left behind. My hypothesis is that there is a new opportunity for Extensible Software on the web.
I don't follow. If this is really supposed to be "software for one", why would it need to be on the Internet? Why does it need a client/server model? Why do I care about "distribution"? People develop for web because native development gets painful when there are many flavours of "native". But you only use one of them yourself, and the LLM isn't bothered by its quirks.
Why not just work on designing pluggable local software that isn't so "professional"?
Data point of 1 but I prefer all my personal software to be web based so I can easily access it from my phone, laptop, and desktop and not worry about syncing things or installing or updating when I switch devices. Also makes it trivial to extend access to family members as needed.
It's very rare that I reach for local software these days.
Pity. Local software runs faster and feels native on the computer. And you can use local files.
I’m keen to build up a better local stack for building local programs more easily, running them over the internet without installing and syncing data.
I don’t want to need the cloud to make my computer work.
Who said anything about cloud?
I run all my apps on my desktop and access them over tailscale. All web apps and I install on phones as PWAs. Super ergonomic.
As for this:
> Local software runs faster
What? Why? Is this some assumption about network requests?
None of my personal software ever has a loading spinner or lag. If it's designed well, each interaction should fit in a single TCP packet so network round trip is imperceptible.
If your web software is slow, that's a choice you've made. Plenty of slow local software around to balance the scales too.
EDIT: Using local files with a web stack is also easy these days. The only con of web software is lacking that native aspect. But native appearance is rare anyway these days with every company just shipping electron bloatware.
> Is this some assumption about network requests?
No. It’s a claim about the amount of work the computer has to do to show UI. Native programs are simply mmapped into memory then executed. They can start instantly. Web software needs a browser engine. And a JS runtime. And a dom. And - usually - needs to wait for a bunch of network round trips.
Tauri - a rust web view wrapper - once bragged that it only needed 25 thousand syscalls to run hello world, vs the 100 thousand that electron needs. I think they’re both totally nuts. Modern computers are fast enough to absorb the necessary performance hit. But why make the UI slow for no reason?
With websites, the UI still usually ends up looking kinda bad. You can make much nicer UIs by using native controls. And you have access to more APIs! I made a conference schedule iOS app the other day which integrates with the native iPhone calendar. You star an event and it gets automatically added to your system calendar. Beautiful.
The only downside is the native ui frameworks aren’t as good. And they force you to rewrite your app N times for N platforms. But that’s just a tooling problem. I’m a big fan of frameworks like day which let me write once and deploy everywhere, while using system UI components. https://daybrite.dev/
Ah ok. When I talk about fast I am usually referring to user perception rather than clock cycles spent. Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.
For me, it's a law of diminishing returns thing. I would (and have) hand roll assembly if I want actual speed.
But we are talking about personal software. Write once, run everywhere browser's exist with essentially no tooling or complexity or deployment concerns.
What does writing everything in rust get me instead that is worth the significant increase in effort and dev time and deployment?
> Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.
I just don't see any software made with web tech that loads in less than 100ms. Here in Australia, it usually takes longer than that for a single packet to get to the US and back.
The Fastmail iOS app is an embedded web app. A fresh launch on my iphone takes about 3 seconds before emails become visible on screen. On my desktop computer, Spotify loads in about 3 seconds. Discord loads in ~12 seconds. These are all packaged web applications, which can store and cache whatever data they want. And we're talking startup times of several seconds.
There's also ram usage. I just opened spotify out of curiosity on windows. Spotify - as I understand it - uses the platform native browser. Just being open - not even playing anything - spotify sits at about 650-800mb of ram. The DDR5 ram sticks I have currently cost about $30 AUD per gigabyte. So, spotify is reserving about $20 worth of my ram the whole time its open. I can afford that. But I didn't buy all this ram so spotify engineers could be slobs with it. According to a quick google search, Winamp 2 used 4-10mb.
There exist pure native apps which also launch slowly and use a lot of ram. Davinci resolve also takes several seconds to launch. So does intellij. But these are much more complex programs than a music player or chat app.
If you're making tiny apps for yourself, I can definitely see the appeal of using web technology from a deployment standpoint. But if it were up to me, we'd port the web's software deployment model to work with native programs. Make native software as good as web dev and cut the browser out of the picture entirely. If ram costs 5x as much, I wanna see my software start using 5x less RAM when it runs. I just don't see that happening in the browser.
In my case it's "software for the home" but then I work from home and it's stuff I actually use to help me in my day to day work.
And I had "software only for the home" way before coding with LLMs were a thing and... It's just convenient when it's in a browser. Especially now with technologies like SSE push (where I hardly need any JavaScript anymore).
Also "software for one" can be "software for the home" but also "software for the SME" and the home has Linux PCs, an iOS tablet, an Android tablet, Android phones and the wife is on a Mac Mini.
Also even if it was really "just for me", something has to be said about an app one can access when not at home (which is easy to do when it's a webapp).
> Why does it need a client/server model?
I just use SSE push now: hardly any JavaScript and it works totally fine. Sure it's technically client/server but it's not crazy complicated either.
I've worked on medium-sized desktop Java apps (a few hundreds of thousands of lines of code) that were running on the three usual suspects: Linux, OS X and Windows.
Well... I much prefer to write webapps.
Wife and I have got a SME we run together and we use a Webapp I made to do so (now with the help of LLMs too, but I made the app before LLMs).
Don't get me wrong: I consider JavaScript to be one of the suckiest language ever invented and the amateurism of its ecosystem makes me want to vomit. It's not a love-letter to JavaScript: but browsers are very convenient.
Smalltalk also had extensibility for one. But it largely missed the explosion of collaboration when open source code became shareable and people can work on it together.
People also shared Hypercard apps.
I think it is less about client/server and more about how ideas can be shared. Sometimes, data might be shared.
Because there is no matchmaker- someone who finds people who have the same problem- and would be happy to buy it from you- on the condition it works for them so a refund is possible.
No huge company, no huge PR department, just one hobbyist/professional selling a ugly, rough around the edges tooling to other hobbyist/professionals.
I think the real thing is that software for one _business_ is very much in demand (and a bunch of SaaS exists as a release valve for those use cases). And that stuff is hard to get working
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.
There's also Spritely's[0] work on Ocapn[1], and Hoot[2], their Guile Scheme implementation in Wasm.
[0] - https://spritely.institute/
[1] - https://github.com/ocapn/ocapn
[2] - https://spritely.institute/hoot/
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?
The wizzard of OS runs a might elephant graveyard for hype products.
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
If you go up a level and read the other parts of that discussion, it's quite rewarding.
"Whoever did write this doesn't know the first thing about Kurt Vonnegut!"
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
Heh, from earlier this year: https://sandstorm.zulipchat.com/user_uploads/70121/TaTwcgiUE...
FWIW I saw the original posts, knew who wrote them, and know that Cloudflare OS is open source. It's because Sandstorm is about running anyone's apps, while where you introduce it you say this:
> the AI cannot introduce a significant security bug
https://news.ycombinator.com/item?id=49183266
That suggests running your own apps, which is a different thing.
The AI-authored apps aspect is obviously something that Sandstorm didn't have.
But Cloudflare OS also supports a concept of "blueprints", where, once you've built your app, you create a "blueprint" (a copy of the code) and share it with others, from which they can create their own instances of the app. So it is still very much about sharing apps and running other people's apps, and the sandbox makes this safe and compliant even if you're not sure the app developer knows what they're doing.
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?
Yes perhaps when I have its features all built out I'll make it packages
[flagged]
[dead]
I've been saying it to anyone who cares to listen: Salesforce is basically the biggest "Smalltalk" deployment out there. Super malleable, has a lot of ... decent rules for how to get software out into the world, every environment is basically its own universe at one point.
Someone should really attack SFDC from the "malleable Business OS" side of things. Unfrotunately everyone seems to attack it from the CRM side of things and lose the plot a bit.
Def agree that "have the thing I just came up with running in some environment that is sharable" is still a pretty gnarly problem, and LLM stuff doesn't... I don't think they've really made much progress on it.
At one point someone really needs to make an easy to manage box metaphor for all the stuff. It's not Docker. Google scripts is almost there but you really want to have the database be a thing you can drag and drop as well (SQLite people: get excited!)
Dropbox for business apps. If anyone runs with this at least send me an email thanking you for the metaphor.
Having worked with Salesforce deployments over the last two years. I'd only call it malleable as long as you fit in its definition of what's malleable. I'm half-expecting it to have its own definition of a wheel at this point.
Don't you feel like it's still fairly far ahead of other systems, if you buy into the model?
I think there are other systems that kinda get there but SFDC is the only one of these kinds of systems that give you a lot of options on the backend and frontend side of things to just ship your own things and have them be integrated.
Maybe. Honestly, it's just been the number one source of deployment issues in our stack, by a large margin, so that may be the frustration talking. It basically requires us to treat our Salesforce environments very differently from the rest of our technological stack in ways that can be pretty alien to what's pretty standard development best practices in the rest of the industry. To give one specific example, the way some things cannot be expressed through metadata or updated through API makes it very hard to have any kind of repeatability between environments, making things like e2e testing and CD a lot trickier to deal with.
As for your specific question, I'll be honest, I'm not familiar enough with what the competition has to offer, because I tend to avoid these behemoth monolithic locked-in platforms like the plague if I can help it, and my experience with Salesforce so far isn't really making it easy for me to change my mind on the subject.
That's fair, at a previous place I worked at we had SFDC integration and there was definitely a lot of restrictions and pain points there. Especially if you're integrating, it's an uphill battle.
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.
>Models can help generate the training data
They can, but I don't think they will be of sufficient quality. It is a fundamental thing. You can't generate new information from existing information. It has to come from the real world.
Generating training data using existing models will only help the model to capture the exiting patterns more thourly.
Ultimately the new data, the slight incrimental improvements to the body of code for training) will actually come from humans even though it was written by ais.
ais write 1000 bits of garbage code for 1000 different users one-offs, the users judge that most of those didn't work out but 2 did. Only those good results that humans approved becomes part of the growing body of reference code. The others either get thrown away, or even if they still exist, they are somehow known to be low quality, or at least, not known to be high value.
So an ai wrote some new code that worked and improved the total corpus that other/future ais reference, but it's not just ai output feeding ai input, it's ai output filtered through humans who nixed most of it.
(Maybe exists on github but not used by anyone. It isn't known to be bad, it's just ranked lower, but if nothing else fits as well, it's there to try. That way obscure code that's good eventually becomes known to be good.)
You can take a working codebase, tell a shitty LLM to rewrite it badly, then swap it around to look like LLM-to-working code rewrite.
>You can take a working codebas
Yes, but how many working code bases do we have. I don't think we have enough number of such high quality code bases to act as training data.
Also, the shitty re-write should also match shitty real-world patterns. Which is quite limit less....So we back to square one. Lack of input from real world.
This is already happening.
Clients come and show me their proof of concept, fully vibecoded, because they do not know / do not have the time to take it to prod. Other comments saying this will be automated in the future... may be. But even if that is the case, time and attention are still needed to make things happen.
With the extendended capabilities IA brings, having an IT person in-house makes more sense than ever, even for small shops.
> 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.
[flagged]
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
Yeah this disposable prototype model is common I suspect. I see it used regularly
So, a requirements document for updates to a legacy system?
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.
> Normal end users want reliable software that does what they want it to do.
But how does that contradicts the idea of extendable software? If anything, extendable software will better do what the user wants it to do.
It's just right now we think of extending the software as if it's a complex operation. It looks to me like the article envisions a future, where extending your software is as simple as, say, creating a new google doc or opening a link.
It is doubtable, however, that such level of ease of extendibility can be achieved at all. There might be enough essential complexity, like answering lots of questions, which, I agree, most users won't be doing.
The vast majority of users buy the software that does what they want it to do right from the start. If you reflect on it, you will likely find that this is also what you do. That behavior is not just normal for software, though, it's the standard for almost any product. You have a certain problem or need, look around until you find something that solves the problem or satisfies the need, and then you might buy it.
Think about cars for comparison. Some people like tinkering with them and tuning them. However, most people look for the features they need or desire and buy the car that satisfies their requirements and budget best.
Sometimes extensibility is part of the requirements to solve a problem or fulfill a desire but normally it isn't.
I think people who don't tune their cars also have some very specific requests on what they miss. It's just they never articulate their requests, because the only way to satisfy them would be to spend lot's of time and resources on tinkering.
However, I can see another counter-argument to my claim: not every consumer has specific requests for the product they're buying! Sometimes people are just not sure what they want. In that case, yes, I can agree that customization doesn't help. Moreover, having a limited set of pre-defined products helps to educate a consumer on what their options even are.
So, if a large part of consumers are the ones that don't know exactly what they want, then yes, you're right. I guess the distribution of “know-what-they-want” vs. “don't” depends on the product, although I think generally it tends to be that most people usually don't know.
Anyway, thanks for the good argument! Thinking about other products and industries, as cars, really helped, I missed that.
The long tail of unmet features is real. Most apps serve the common cases well, and LLM-generated extensions could fill that gap without bloating the core product.
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.
Extending software makes it more complex. As you keep adding extensions, the complexity grows until the app is unusable. Doesn't matter if it's built-in or a plugin, result is the same. But there is a proven alternative that works well.
Write completely separate small apps, and it's a different result. You get reliable functionality without an increase in complexity. Don't add a "file search extension" to your application (consider that if any other application wants this functionality, now they have to implement their own extension). Instead you make one completely separate app, called 'grep'. You then call that one 'grep' app, from any application.
It's a very old-fashioned idea to programmers who have only ever known custom-integrated REST APIs and microservices and giant monolithic frameworks. But this old-fashioned idea is the reason AI agents are even useful at all. They call those old-fashioned single-purpose external tools, and suddenly the agent has useful features, no custom extension needed.
Another thing you don't need: "a platform for platforms". There's already a platform designed to run interoperable applications. It's called an Operating System. It runs these little independent things called applications. They all have data object storage input-output access. Even internal communication between processes. And they're all compatible.
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...)
Tangent to the thread; I'm coming across your work after researching cloudflare os this evening, and I gotta say, I am super impressed.
I came across sandstorm a few years back too -- so my mind was blown to learn workers and CloudflareOS are a better implementation of that project.
Cloudflare becoming FedRAMP High recently is a big deal in my little world. I'm trying to learn everything I can about it for our little AI consultancy.
CloudflareOS looks like the sandboxing piece I was just starting to put together -- agents and MCPs behind real security boundaries. Sandboxing is so damn important in this space and most of the other providers ignore it completely or just give it lip service. I think the workers concepts are going to supercharge way more than folks are giving you credit for (in the HN thread a few weeks back there were a lot of dubious folks -- I see it more like the Dropbox announcement).
I hope our paths cross at some point soon. I would love to get more understanding of CF and the roadmap for COS.
Thanks!
In case you have not come across this it might be helpful:
MetaMask Snaps does something like Cloudflare OS's iframe sandbox, but it does aim to be suitable as a sandbox against malicious code.
Something of a security audit was published here: https://osec.io/blog/metamask-snaps/
Execution environment code here: https://github.com/MetaMask/snaps/tree/main/packages/snaps-e...
As it says in that readme, "sandboxed using Secure EcmaScript (SES)": https://github.com/endojs/endo/tree/master/packages/ses (which you might be familiar with, as it is a project of Endo, which Mark Miller helps lead)
WebRTC is coming down the pipe into CSP hopefully soon: https://www.w3.org/TR/CSP3/#directives-other
I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.
The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).
What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().
For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.
Sandboxed execution is definitely one aspect... But IMO, this is still not secure enough for vibe coders. They will want to have data-driven apps to share among small groups of people, then the security of the sandbox doesn't matter if they expose some external endpoints and if the access control logic which guards data is flawed.
Even if each user gets their own sandbox, they will still want to configure different access rules for different kinds of data which they host.
That said the idea that each user could control and host their own data is interesting and could work. I imagine you could have apps which link data from many different user sandboxes via remote foreign keys.
You could have a centralized data schema controlled by the application owner but the data itself would be held/scattered across a large number of sandboxes.
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.
Me and a Cofounder are building something along these lines on top of K8s. The wisdom that "if give the LLM clear boundaries and you get better results" definitely holds IME, even with frontier models like fable. It's impossible to specify all the guardrails you need to keep models from violating priors without writing the code yourself, so the only move is to remove their ability to do so, or to even recognize that the option exists.
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
> 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 think it all comes down to a dichotomy that wasn't extremely visible before LLMs: there are, broadly, two kinds of people – those for whom the journey and the learning are the most important, and those for whom those are mere obstacles on the way to the end product.
The two camps both speak as if the other side can't possibly exist. I think they've both always existed, it's just that LLMs have made the distinction plain as day.
I mean if you define anything using web-based technology as crap then sure, but someone could just as easily define Linux GTK apps as being old and janky and then where will we be? LLMs can write Zenity bash scripts just fine, it's up to the person driving it to ask for that instead. How's well does that Zenity bash script work on Android/iOS/windows/ChromeOS/Mac/esp32? We can shit all over people for using technologies we personally wouldn't choose, but it's not like they're aren't reasons for it. It's not 1990 anymore and my computer has gigabytes, not megabytes of ram.
> It's not 1990 anymore and my computer has gigabytes, not megabytes of ram.
And these gigabytes get used up really quickly when the LLM goes brrrr. And with this 500% surge in RAM prices, I don't think it's still enough to just buy more.
To your point, consumer computer memory has stagnated at 8/16 GiB of RAM for a while.
>> 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.
...
> LLMs can write Zenity bash scripts just fine, it's up to the person driving it to ask for that instead.
You don't think we're on the same page here?
As far as that part goes, you're right. However, someone wanting to make $APP work on raspberry pi 1 level of hardware, and complain to the LLM that electron is so laggy as to be unusable, then I also imagine the LLM is capable of suggestion rewriting $APP with $FOO technology that is the tight low-memory CPU-sipping version of $APP. If TSMC falls and we can't make new hardware, that may have to happen, but until such time that it's forced to, it's not going to.
> However, someone wanting to make $APP work on raspberry pi 1 level of hardware, and complain to the LLM that electron is so laggy as to be unusable, then I also imagine the LLM is capable of suggestion rewriting $APP with $FOO technology that is the tight low-memory CPU-sipping version of $APP
I don't think I've ever seen someone's agentic loop actually decide to do a rewrite. Once it sets off down a path, due to how token generation works, it can't actually backtrack easily.
I really enjoy working on my inhouse orchestration tool because it brings me back to the days of working in Smalltalk image where I can tweak my development IDE as I go along.
> "code can only take actions via the references it has been passed"
The cool part is a move to capabilities composed in code brings back everything great about software itself: composability, encapsulation, type systems.
I've been working on this for SQL: instead of giving clients a handle to endpoints, you give them scoped query builders they can compose with (e.g., hand out a scoped `users` object and client can do `users.where(u => u.isActive()).orderBy(u => u.createdAt)`).
The result is you define a data-model (schema, computed columns, relations) and expose that instead of an endpoint per desired client query.
(if interesting: https://typegres.com/)
Why is lovable not enough here by the way?
[flagged]
[flagged]
[flagged]
[dead]
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.