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.
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.
I've been doing this a long time too. The anti-patterns tend to come from the hype cycles of "xyz shiny tool/pattern will take away all the nasty human problems that end up creating bad software". Yes, LLMs will follow this cycle too, and, I agree we are in a kind of sweet spot moment for LLMs where they were able to ingest massive amounts of training material from the open web. That will not be the case going forward, as people seek to more tightly guard their IP. The (open) question is whether the training material that exists plus whatever the tools can self generate is good enough for them to improve themselves in a closed loop cycle. LLM generated code was the right tool for my job today; doesn't mean it's the right tool for everyone's job or that it always will be. One thing constant in this industry is change. Sold as revolutionary, which is the truth, in the sense of going in circles/cycles.
Also, they've been trained on common practices more than they've been trained on best practices. And best practice is heavily context dependent anyways.
Humans can learn from new experiences. LLMs have to be retrained (continuous learning isn't good enough yet), or you have to fit enough information into the context while still having enough for the task itself.
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.
Amazon is not one app, its hundreds of them bundled in some giant monster.
You could easily replicate the store part of it minimally, at its core its just an index of products, a basket and checkout system.
There are other parts that make up the whole thing of course.
There is a lot of room between no value and trillion dollar company
It would be great if LLM's did this (the relevant, and very pointed, follow-up questions). Instead, today they kind of just go "okay sure yeah here it is. here's as much of Amazon.com as I can code within my token budget. Good luck drawing the rest of the owl."
IMO, documentation becomes much more important if we're planning to hand off coding to the LLMs
You can ask it about the code, sure, and it'll try to tell you how it works. But, what if there's a bug in the code? Maybe the LLM will guess at how it was supposed to work, or maybe it'll start making stuff up to justify the bug's existence (it's actually a hidden feature!)
The docs say how the code should work. For an LLM that has to go relearn everything about your code base every time you invoke it, that's vitally important
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.
It's so standard that the usual paradigm is that your company will adapt itself to the way SAP works, not the other way around. Massive gigantic corporations have tried to adapt SAP and failed. IIRC Lidl had a very expensive high-profile failure in this.
> I didn't get into programming for the money, it's just been a nice bonus.
Exactly the same for me! If kind of feel like an artist whose paintings are worth more more easily than a paint or music artist… But boy would I be poor if this art were worthless!
It's also such a weird claim, how the fuck are we going to be left behind when the skill level is just entering text in a box... a skill we literally do for our jobs..
It's the problem that the whole industry is facing - the current generation of hardware is sufficient that hardware refreshes will continue to decline, and companies that want to keep milking us for money regularly need to find a new way to do it.
> the current generation of hardware is sufficient that hardware refreshes will continue to decline
If anything, Apple is refreshing their hardware much faster now compared to the Intel days. There's literally a new MacBook Pro and MacBook Air every year. And of course there are 3-4 new iPhones every year.
I hate subscriptions as much as the next person but how would you pay for continued development of software? Do you say a person can continue to run version X forever but if they want a new version they pay for it?
'analytics' and 'surveillance' are not the same thing
trying to understand player behavior in the context of a board or video game (though there is some overlap!) is not the same as trying to understand user behavior in the context of social media or purchasing behavior - the data of both of which derive their value from being sold to THIRD PARTIES as a commodity.
being able to tune a fun little video game is not the same thing at all
Collecting analytics like this is effectively the same as play-testing physical board games in-development. People play a game, information is gathered, and the game is tuned in response to that. If zero information were ever gathered, games could not be balanced or tuned for other things like unforeseen problems.
Please, show me a piece of software, or game, that is perfect the first time it is made.
So long as personal information is not collected, consent is not morally necessary.
If I collect information on how often a coin-op Street Fighter II game is played in an arcade, while collecting no personal information, consent is not needed.
You are not entitled to play the game, which is hosted on their server which requires bandwidth and other resources. In the same way that you are free to make demands about how software runs on your machine, the author is free to make demands about the use of their software.
If the data gathered is only on gameplay, and not something that can be used as PII like IP addresses or device information, then it should be fine. Gathering things like the score and time spent completing the level, isn't a problem. This could be used to rank the levels, without gathering any user information.
There are games that let you opt-out, hell even ones that ask you when you first open the game. There are bad apples, but there are plenty of good ones too.
If it asks you then it's neither opt-in nor opt-out. Then it depends on how it asks you. If it's a simple yes/no, it's fine. If it's typical tech bullshit where your options are a big "I want to make the world a better place and save the whales by sending my data" or a tiny button in the corner labeled "maybe later" that takes you to another screen saying "please confirm you want to opt out of data collection and kill a bunch of kittens" then not so good.
You could just package an arbitrary 100 levels, let the player play them in any order, then give rewards for 10, 20, 30, 40, etc. levels completed/mastered.
It's frankly embarrassing how many of the comments on this thread are some version of looking at the XKCD "dependency" meme and deciding the best course of action is to throw spitballs at the maintainers of the critical project holding everything else up.
I think both of those POVs are wrong. The whole thing about F-Droid is that they have worked hard on not being a central point of trust and failure. The apps in their store are all in a repo (https://gitlab.com/fdroid/fdroiddata) and they are reproducibly built from source. You could replicate it with not too much effort, and clients just need to add the new repository.
At the very least, it's reasonable to expect the maintainers of such a project to be open about their situation when it's that precarious. Why wouldn't you take every opportunity to let your users and downstream projects know that the dependency you're providing is operating with no redundancy and barely enough resources to carry on when things aren't breaking? Why wouldn't they want to share with a highly technical audience any details about how their infrastructure operates?
They're building all the software on a single server, and at best their fallback is a 12 year old server they might be able to put back in production. I'm not making any unreasonable assumptions, and they're not being forthcoming with any reassuring details.
F Droid is no where near being a critical project holding Android up. The Play Store, and the Play Services themselves are much more critical. Being open source doesn't make you immune from criticism for not following industry standards or being called out for poor security.
> The Play Store, and the Play Services themselves are much more critical.
Critical for serving malware and spyware to the masses, yes. GrapheneOS is based on Android and is far better than a Googled Android variant precisely because it is free of Google junk and OEM crapware.
The internet itself is also critical for serving malware and spyware, but that doesn't mean that the internet is garbage. Google invests much more into removing malicous apps from the app store than fdroid does.
If you have nothing to install on your device, what's the point of being able to? For me, f-droid is a cornerstone in the android ecosystem. I could source apks elsewhere but it would be much more of a hassle and not necessarily have automatic updates. iOS would become a lot more attractive to me if Android didn't have the ecosystem that's centered around the open apps that you can find on f-droid
I know they're marketing on price, but they really whiffed not offering AWD on that thing. Living in the Northwest, that's a total dealbreaker both from a skiing perspective and a getting-to-work-when-it-snows perspective.
Honestly, I wonder how some of these publishers stay in business at all. I haven't written a book, but I've been a technical reviewer for friends who have been published with some of the larger technical publishers. Nobody was making money from the process. I do wonder if maybe they're just taking on too many titles and reaching saturation. Do we really need "The guide to making X on Y with Z" for every potential iteration?
From the people I know who wrote or co-wrote books, the way you make money is in future interview processes.
I don't know if they still do it, but when I interviewed for Google, they had a self-ranking system of how competent you are in each technology, and the only way to get the top score was phrased something like "I wrote the book on it (yes, an actual book)".
If you "know" that a study whose title you are predisposed to disagree with has "BS" in it, something tells me no amount of scientific evidence is going to persuade you.
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.
reply