Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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
- 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 - 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 - 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 - > 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