Comment by WarmWash
9 hours ago
Small bespoke personalized on the spot apps are the future with LLMs.
The future will absolutely not be "How things are today + LLMs"
The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?
I think you're missing the enormous value in apps being standardized and opinionated. Standardized means that in addition to documentation, the whole internet is available to help you. Opinionated means as a user of an app in a new domain, you don't have to make a million decisions about how something should work to just get started.
Sure, there will be more personalized apps for those who have a lot of expertise in a domain and gain value from building something that supports their specific workflow. For the vast majority of the population, and the vast majority of use cases, this will not happen. I'm not about to give up the decades of experience I've gained with my tools for something I vibe coded in a weekend.
I've seen plenty of "standardized" (ie, "Enterprise" applications)... I'd just assume a bespoke hammer that's simple and easy to understand over a complex beast of HammerFactoryFactory to deliver you a builder of custom hammer builders so you get the JobHammer you need as part of the IoC loader platform that is then controlled through a 1.2gb service orchestrator that breaks at 11am every third Tuesday for an hour. When all you need to do is post up a "Help Wanted" poster on a piece of wood.
A standardized hammer can just be a carpenter's hammer, though. Putting a nail pull on the back side is making it opinionated in a way that gives users access to a tool that they may not have thought of if they built their own hammer, but very well might appreciate having.
This isn't a defense of enterprise applications, though. They're more like a shed fully of rusty tools with a thirty different coping saws blades and not a single handle because corporate policy only allows for you to have a handle if Joe from accounting says you can, but why would he when his VP confidently said you can just hold the blade between your fingers.
1 reply →
AI's / LLM's have already been trained on best practices for most domains. I've recently faced this decision and I went the LLM custom app path, because the software I needed was a simple internal business type app. There is open source and COTS software packages available for this kind of thing, but they tend to be massive suites trying to solve a bunch of things I don't need and also a minefield of licensing, freemium feature gating, and subject to future abandonment or rug pulls into much higher costs. Something that has happened many times. Long story short, I decided it was less work to build the exact tool I need to solve my "right now" problem, architected for future additions. I do think this is the future.
> AI's / LLM's have already been trained on best practices for most domains.
I've been at this long enough to see that today's best practices are tomorrow's anti-patterns. We have not, in fact, perfected the creation of software. And the your practices will evolve not just with the technology you use but the problem domains you're in.
I don't mean this as an argument against LLMs or vibe coding. Just that you're always going to need a fresh corpus to train them on to keep them current... and if the pool of expertly written code dries up, models will begin to stagnate.
2 replies →
What if there is a new domain.
2 replies →
Expertise won't be needed (it already isn't). One can create copies of apps with vague descriptions referencing those big apps:
"Create a copy of xyz. It needs to look and behave similarly. I want these features ... And on top of that ...". Millions decisions not needed. A handful of vague descriptions of what one wants is all it takes today. I think claude and co. can even take in screenshots.
Documentation won't be needed either IMO. Since humans won't write nor read the code. They will simply ask LLM's if they have a question.
I totally am giving up my experience with various paid SaaS this year, which I was paying for last years. Not only am I able to add the features that I was wishing for those tools to have (and would have never made it into the real app because they're niche requests), but am saving money at the same time.
And the above is just whats happening today. Claude Code is younger than 1 year old. Looking forward to come back to this thread in a year and swallow my words... but I'm afraid I won't have to.
But millions discussions are needed and will always be needed?
"Create a copy of Amazon.com"
ok, how did you want to handle 3pl fulfilment and international red tape?
"No not that complicated, a minimal copy"
How minimal? How many servers should I provision? How vertically integrated should we get?
Etc.
I really want to see someone build an app of any value with minimal decisions made.
3 replies →
The apps/use cases for which such standardized and opinions tools can exist for, economically, mostly already exist IMO. Vibe coded tools fill an enormous space of semi-unique problems that only affect a small amount of people. For example various scripts to automate tasks imposed by a boss. The best balance is probably to use LLMs to use the standardized tools for you when available, so that things remain mostly scrutable.
As the saying goes, 80% of users only use 20% of the features of your program, but they are different 20% parts. When the user vibecode the program instead, only their specific 20% needs to be implemented.
Then you’re going to be left behind. I’m going to be left behind.
Every problem or concern you raise will adapt to the next world because those things are valuable. These concerns are temporary, not permanent.
> Then you’re going to be left behind.
I really, really don't care
I didn't get into programming for the money, it's just been a nice bonus
2 replies →
> when LLMs can build you an custom(!) hammer or saw in a few minutes, why go to the shed?
Because software developers typically understand how to implement a solution to problem better than the client. If they don't have enough details to implement a solution, they will ask the client for details. If the developer decides to use an LLM to implement a solution, they have the ability to assess the end product.
The problem is software developers cost money. A developer using an LLM may reduce the cost of development, but it is doubtful that the reduction in cost will be sufficient to justify personalized applications in many cases. Most of the cases where it would justify the cost would likely be in domains where custom software is in common use anyhow.
Sure, you will see a few people using LLMs to develop personalized software for themselves. Yet these will be people who understand how to specify the problem they are trying to solve clearly, will have the patience to handle the quirks and bugs in the software they create, and may even enjoy the process. You may even have a few small and medium sized businesses hiring developers who use LLMs to create custom software. But I don't think you're going to see the wholesale adoption of personalized software.
And that only considers the ability of people to specify the problem they are trying to solve. There are other considerations, such as interoperability. We live in a networked world after all, and interoperability was important even before everything was networked.
> Because software developers typically understand how to implement a solution to problem better than the client. If they don't have enough details to implement a solution, they will ask the client for details. If the developer decides to use an LLM to implement a solution, they have the ability to assess the end product.
Why do you think agents can’t do that? They can’t do this really well today but if the distance we went in 2025 stays similar it’ll be like a year before this starts getting decent and then like another 1 year before it’s excellent.
> Sure, you will see a few people using LLMs to develop personalized software for themselves. Yet these will be people who understand how to specify the problem they are trying to solve clearly, will have the patience to handle the quirks and bugs in the software they create
Only humans can do this?
Hallucinations are not solved, memory is not solved, prompt injection is not solved, context limits are waaay too low at the same time tokens way too expensive to take advantage of context limits, etc. These problems have existed since the very early days of GPT-4 and there is no clear path to them being solved any time soon.
You basically need AGI and we are nowhere close to AGI.
1 reply →
> The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you an custom(!) hammer or saw in a few minutes, why go to the shed?
1) Your specific analogy is kinda missing something important: I don't want my tools working differently every time I use them, also it's work to use LLMs. A hammer is kind of a too-simple example, but going with it anyway: when I need a hammer, I don't want my "LLM" generating a plastic one, then having to iterate for 30 minutes to get it right. It takes me far less than 30 minutes to go to my shed. A better example is would be a UI, even if it was perfect, do you want all the buttons and menus to be different every time you use the tool? Because you generate a new one each time instead of "going to the shed"?
2) Then there's the question, can an LLM actually build, or does it just regurgitate? A hammer is an extremely we'll understood tool, that's been refined over centuries, so I think an LLM could do a pretty good job with one. There are lots of examples, but that also means the designs the LLM is referencing are probably better than the LLM's output. And then for things not like that, more unique, can the LLM even do it at all or with a reasonable amount of effort?
I think there's a modern phenomenon where making things "easier" actually results in worse outcomes, a degraded typical state vs. the previous status quo, because it turns what was once a necessity into a question of personal discipline. And it turns out when you remove necessity, a lot of people have a real hard time doing the best thing on discipline alone. LLMs might just enable more of those degenerate outcomes: everyone's using "custom" LLM generated tools all the time, but they all actually suck and are worse than if we just put that effort into designing the tools manually.
I started picturing AI generating tools like it does images of people... I mean, of course every other hammer will have an extra head off to the side, or split into 3 handles.
Seriously though, you can tell AI what libraries and conventions you want to follow... that's been a lot of what I've done with it recently... I've been relatively pleased with the results.
I've said several times that it's not perfect, but it is an overall force multiplier. It's much like working disconnected with an overseas dev team, but you get turn around in minutes instead of the next morning in your email. The better instructions/specs you give, the better the results. On my best day, I got about 3 weeks of what would take me alone done, after about 3 hours of planning/designing and another 2-3 hours of iteration with Claude Code. On my worst day, it was frustrating and it would have been about the same amount of time doing it myself. On average, I'd say I get close to 5 days of work done in 5-6 hours of AI assisted coding. Purely anecdotally.
That said, I usually have a technical mind for how I want the solution structured as well as features and how those features work... often it clashes with the AI approach and sometimes it swims nicely. I'll also say that not all AI coding is the same or even close in terms of usefulness.
The vast majority of users make zero changes to the default settings of an app or device, even for software they use all the time and where some simple builtin adjustments would significantly improve their experience.
I simply can't imagine a world where these same people all decide they constantly want to learn a completely unique UX for whatever piece of software they want to use.
Your missing the forest for the trees here.
Users will not fumble with the complex web of nested settings that engineers wet dream about.
But they will tell the LLM "I'd really like it if the tool bar only had the hammer and saw tools", and it will be done.
I cannot see software going in any other direction than a blank front end that users prompt LLMs to run scripts on top of.
Picture MS Word where the GUI is just a page and a sidebar for telling an LLM what you want it to do. And if it's not possible, the LLM could even write extensions and plugins that make it possible.
Software is going to completely change.
That only requires apps to be configurable. You don't need a whole new app to configure a toolbar.
> Picture MS Word where the GUI is just a page and a sidebar for telling an LLM what you want it to do.
Done. And it seems absolutely awful.
"Please bold the text I have selected" instead of a preexisting bold button.
Oh wait I can just tell it all the tools I commonly use and where to put them... Hmmm topbar or side bar. Wow so much fun getting to make all these decisions!
Ok time to change fonts. "Please add a font picker so I can pick a font"
All the people may not, but a decently skilled software engineer armed with an LLM, who doesn't have a lot of free time might be now be motivated to do it, whereas before it was like, "This thing is going to take months to replace, do I really want to write my own?"
The LLM will know how the user operates, their proclivities and brain structure, and will design UX perfectly suited to them, like a bespoke glove. They won't have to learn anything, it will be like a butler.
Why not just say that the LLM will just do all the work while you're making up future, hypothetical capabilities of LLMs?
Because whatever you use a LLM to build will inevitably need more features added or some kind of maintenance performed. And now you're spending $200+/mo on LLM subscriptions that give you a half-assed implementation that will eventually collapse under its own weight, vs just buying a solution that actually works and you don't have to worry about it.
>... and you don't have to worry about it.
Not to be argumentative, but I have a concern that whomever I buy my solution from will have vibe coded it instead. I guess that means my support contract entitles me to hassling them about it, but I'm starting to worry it's just LLMs and vibe coded apps all the way down.
"why go to the shed"
A good question but there's a good answer: Debugged and tested code.
And by that, I mean the FULL spectrum of debugging and testing. Not just unit tests, not even just integration tests, but, is there a user that found this useful? At all? How many users? How many use cases? How hard has it been subjected to the blows of the real world?
As AI makes some of the other issues less important, the ones that remain become more important. It is completely impossible to ask an LLM to produce a code base that has been used by millions of people for five years. Such things will still have value.
The idea that the near-future is an AI powered wonderland of everyone getting custom bespoke code that does exactly what they want and everything is peachy is overlooking this problem. Even a (weakly) superhuman AI can't necessarily anticipate what the real world may do to a code base. Even if I can get an AI to make a bespoke photo editor, someone else's AI photo editor that has seen millions of person-years of usage is going to have advantages over my custom one that was just born.
Of course not all code is like this. There is a lot of low-consequence, one-off code, with all the properties we're familiar with on that front, like, there are no security issues because only I will run this, bugs are of no consequence because it's only ever going to be run across this exact data set that never exposes them (e.g., the vast, vast array of bash scripts that will technically do something wrong with spaces in filenames but ran just fine because there weren't any). LLMs are great for that and unquestionably will get better.
However there will still be great value in software that has been tested from top to bottom, for suitability, for solving the problem, not just raw basic unit tests but for surviving contact with the real world for millions/billions/trillions of hours. In fact the value of this may even go up in a world suddenly oversupplied with the little stuff. You can get a custom hammer but you can't get a custom hammer that has been tested in the fire of extensive real-world use, by definition.
I do not think that this is likely to be a successful model.
When (not if) software breaks in production, you need to be able to debug it effectively. Knowing that external libraries do their base job is really helpful in reducing the search space and in reducing the blast radius of patches.
Note that this is not AI-specific. More generally, in-house implementations of software that is not your core business brings costs that are not limited to that of writing said implementation.
The more I experiment with quickly coding up little projects with LLMs the more I am convinced of this. There is that saying: 90% of your customers use 10% of your software's features, but they each use a different 10%. Well, the ability to quickly vibe up a small bespoke app that does that 10% AND NOTHING ELSE is here now, and it kind of solves that problem. We don't need to put up with DoEverythingBloatWare (even open source DoEverything) when you can just have the bits and pieces you actually want/need.
Also, you don't have to fear breaking updates--you know for sure that the software's UI will not just change out from under you because some designer had to pad their portfolio. Or that you're not going to lose a critical feature because the developer decided to refactor and leave it out.
I'm currently going through and looking at some of the bigger, bloated, crashing slow-moving software I use and working on replacements.
The 3d-printer of software: get a custom part quickly and cheaply, even if not suitable for mass production.
I think this is a great analogy
> when LLMs can build you an custom(!) hammer or saw in a few minutes, why go to the shed?
Because I thought I needed a hammer for nails (employee payroll) but then I realized I also need it to screw (sales), soldering (inventory management) and cleanup (taxes).
Oh and don't forget that next month the density of iron can lower up to 50%.
Screw sales! I've definitely felt that way more than a few times :-D
Good points. It does feel like that happens quite often
Bespoke personalized apps have been around forever in the form of shell scripts. LLMs will expand that capability to a lot more people but won’t change the basic dynamics. Just like shell scripts, LLMs will need lower level building blocks to work with. The main difference will be that the LLM ecosystem will include some libraries as well. Though, I believe, most of those libraries haven’t been written yet.
Hehe, you created quite the dog pile. Here's my woof:
IMO you only need to look at the 30+ year history of Linux to see how wrong this prediction is. There will be a small group of people who do as you say, but the other 95% will happily pay for someone else to take care of their problem. Convenience is the supreme king of the American market.
Why use a battle tested, secure, library that you know solves your problem when you can burden your project with custom code you need to maintain?
While quality libraries do exist, let's not pretend that most people are validating and testing the libraries they pull in, that abandoned / unmaintained libraries aren't widely used, and that managing the dependency hell caused by libraries is free.
I can speak to this directly: I've customized a few extensions I use with VSCode, (nearly) completely having the AI generate/iterate over my feature request until it works. I don't have the time to learn the details (or different languages) of the various projects, but I get huge benefit from the improvements.
- PRO Deployer
- MS Typescript
- Typescript-Go
- a bespoke internal extension to automate a lot of housekeeping when developing against tickets (git checks, branch creation, stash when switching, automatically connecting and updating ticket system)
StanLLM-generated hammer: "Dear valued customer, our automated systems have flagged activity on your StanLLM account that appears to be non-compliant with our Acceptable Use Policy. As a precautionary measure your account has been suspended. If you believe this suspension is in error, feel free to contact our customer support at /dev/null^H^H^H^H^H^H^H^H^Hsupport@..."
That's what you get for using proprietary software instead of the GNU version: StaLLMan
This assumes an educated, passionate and patient user that 99% of people are not. They wont ask for a hammer - they will ask for a rock tied to a stick and get pissed off when it doesn't work like a hammer. They will ask for paint that doesn't drip. They will ask for electrical sockets they can install in their bathtub.
Because I will probably ask the AI for a rock instead of a bespoke hammer. If I even know what a nail is.
I very much like to use the years of debugging and innovation others spent on that very same problem that I'm having.
My personal theory is that as the excitement for LLMs normalizes, we'll land on something evolutionary rather than revolutionary. Prompt programming will take over what used to be quick/amateur micro programs (this includes userspace "developers"). Skilled developers will operate on a spectrum: all manual code at one extreme, and at the other extreme, manually defining just the essential patterns that prompt programming can reasonably build upon.
I do not suspect that we will stay in an individualized programs Tower of Babel situation, if we ever enter it in the first place.
It's anyone's guess as to what we end up settling on, of course. This is just a guess of mine.
Maybe true for some apps, but I suspect we will still have a vibrant ecosystem of package managers and open source libraries and coding agents will know how to use them.
What would be the point of that? If LLMs ever actually become competent, surely they can just implement what they need.
The same reason why they exist now. Why spend millions of tokens on designing, implementing and debugging something, followed by years of discovering edge cases in the real world, if I can just use a library that already did all of that
Sure, leftpad and python-openai aren't hugely valuable in the age of LLMs, but redis and ffmpeg are still as useful as ever. Probably even more useful now that LLMs can actually know and use all their obscure features
1 reply →
Would you trust your hand next to a saw made by an LLM?
Maybe. Were the designs reviewed by qualified engineers and gone trough rigorous QA cycles before getting placed in front of me?
Nope. 100% vibe coded. The brand is DeValt. It may or may not come with a frayed power cord wrapped in electrical tape. As long as you stay away from any water source, it'll be fine.
"Why hire a website designer when you could just drag and drop in WordPress?"
And many businesses do, and it works, until it doesn't. I agree with you; that's the future I'm seeing for ad-hoc LLM apps.
From what - OS libraires only? Assembly?
The danger is not "Nobody uses OSS".
The danger is "building software becomes exponentially more difficult without a commons to build from".
I don't think apps where people spend a lot of time are equivalent to small tools. You can vibe code a calculator but you probably spend most of your time on much more complex software.
A calculator that uses doubles for everything I guess.
This is only a realistic expectation for the single person who needs that hammer.
Otherwise we'll all individually be burning power via GPUs to reinvent the wheel thousands of times.
Also, look at the level of effort to maintain any bespoke machine. Assembly lines with interchangeable parts were a big deal for a reason. That follows with software via standard libraries and APIs. If you reinvent your software wheel every time, we'll all have careers trying to fix the deluge of slop that has been generated.
Because it can’t really do that for any tools that matter.
Exactly, think StarTrek replicator.
Why need a tool at all when the LLM can just build the house? What is a hammer? What is a keyboard? What’s a “Drivers License”?
[dead]
Because going to the shed to get a work-tested tool is still faster than waiting on an LLM and hoping it meets every use-case you're likely to run into with that tool.
Whatever it is, the future will also certainly not be what it was a couple decades ago - that is, every one inventing their own solution to solved problems, resulting in a mess of tools with no standardization. There is a reason libraries/frameworks/etc exist.
> when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?
once such LLMs exist, this question may be worth considering
they do NOT exist at this moment
along that line of thinking, I've been wondering if there are better building blocks. right now we're asking llms to use the bricks designed for the human hand building a cathedral - what do the bricks look like when we want AI to build many sheds for specific use? functional programming? would the database ideas of data storage like the longhorn vapourware make a come back?
[dead]
[dead]
I think that's an optimistic interpretation of how good LLMs are?
But I think the reality is: LLMs democratise access to coding. In a way this decreases the market for complete solutions, but massively increases the audience for building blocks.
That you get no credit for open sourcing. Why would creators spend time anymore?
> LLMs democratise access to coding
by making the world dependent on 3, fascist adjacent, US tech companies?
I didn't know Mistral, Z.ai, Qwen, and Deepseek were all fascist adjacent US tech companies.
1 reply →
>LLMs democratise access to coding
Vibe coders don't code, they let code. So LLMs democratise access to coders.
Closed-source models aren't "democratizing" access to anything. If you wanted to hire a contractor to write some code for you, that's always been possible.
3 replies →
I like this take. "How things are today + LLM" is in some ways the best we can approximate because one is all we know and other side is the future unfolding before our eyes. One of the coolest things about vibe coding I find is starting with a base like django then using vibe coding to build models and templates exactly how one wants for a UIUX. Basically maybe we still need humans for the guts and low level stuff but that provides a base for fast, easy personalized customization.
I had a job where in short we had a lot of pain points with software that we had no resources permitted to fix them. With a mix past experience, googling I started writing some internal web based tools to fix these gaps. Everyone was happy. This is where I see vibe coding being really helpful in the higher level stuff like higher level scripting and web based tools. Just my opinion based on my experience.