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.

You forgot to mention the IT Security team locking up all the screwdrivers to prevent potential cross-contamination with hammer usage.

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.

What if there is a new domain.

Then it is new for everyone, no?

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.

> 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.

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.

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.

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.

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.

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

> 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..

SAP is THE MOST standardised "app" in the world.

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.

Being standardised isn't always a good thing.