Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by sroerick - 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’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.
- For client side there is https://hardenedjs.org/
And Cloudflare OS does some fancy things with iframes + capnweb iirc
by masterj - 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.
by 0xbadcafebee - 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.by harlan_pdx
- 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.
by a2ff6eeb0 - 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.by 13415
- > 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.
by zahrevsky - 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.
by bevr1337 - 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.
by rtpg - 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.by folkrav
- 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.
by qsera - So, a requirements document for updates to a legacy system?by brookst
- 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 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.
by lelanthran - 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.
by amadeoeoeo - 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.
by pornel - 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.
by bensyverson - > 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 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".
by yipinwong - 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.
by masterj - > 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"?
by zahlman - 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 workingby rtpg
- 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.
by 21asdffdsa12 - 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.
by hosh - 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.
- 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.
by wild_egg