1. Branding. Companies want to control their interfaces for all sorts of reasons. Branding is a big one. Clarity and comms are another.
2. LLMs in the hot path. LLMs are expensive, a hell of a lot more expensive than executing some Javascript locally. Hell, you'd still probably need to do that under this model anyway. We're likely to see LLM usage filter into the right places, use-cases with higher leverage, LLMs to create a UI that is shipped to all users over LLMs creating UI on the fly every time. Costs and time will dictate this just like they have dictated how every other technology is used.
Look I'm sure it'll happen in some places, it's just not going to be a major shift in the way this post describes.
If the table stakes for using my API is a local GPU to build the interface, my competitors who used their GPUs once to create the interface for their customers will win. If the API getting started guide involves going to a user-contributed list of prompts to put together a set of things I want in the interface, the competitor who doesn't have that step and provides a default interface will win.
Default interfaces being provided is not going to change, and the universal truth of defaults is that most people stick with them.
Power users modifying their interfaces has always been a thing and is easier with LLMs, but it's going to remain niche, as in, something that power users/hobbyists do, or companies might provide their own internal UI to some external API, but again that already happens extensively.
Amazon is the wrong analogy I think, because delivery is in some ways cheaper than every individual going to the store themselves, storing in warehouses is cheaper than storing in stores. In fact in some ways the Amazon analogy better fits the other way around. Not a perfect fit.
I believe branding is still possible, though more of a capability and platform approach like Stripe or Shopify. Local LLMs will likely make it more feasible in the future as costs decrease.
The branding part might be less relevant to B2B products, but it's critical for B2C. And the clarity/communication aspect is acutely relevant to both. I don't know how you handle that with everyone generating their own interfaces.
Imagine policy compliance too? You need a cookie banner for legal reasons, how do you enforce that everyone's interfaces add the cookie banner? I hate cookie banners, but it's a clear example of where compliance dictates UI, and there are others (sales, insurance, contracts, etc).
As for costs decreasing, sure, and local LLMs improve things... but building the UI once will always win out on costs. Even with local LLMs we'll still cache UI creation, so then why not share that cache? Maybe it takes a bunch of prompting to get the exact accessibility stuff you need in the UI, so now you share prompts for generating the bit you need.... why not just share the actual output, why not just use the one the service provides?
I think there's a version of this focused on customisation that I can see happening, but otherwise all I see is a ton more code, a ton more liability, and products being on the whole worse.
1. Branding. Companies want to control their interfaces for all sorts of reasons. Branding is a big one. Clarity and comms are another.
2. LLMs in the hot path. LLMs are expensive, a hell of a lot more expensive than executing some Javascript locally. Hell, you'd still probably need to do that under this model anyway. We're likely to see LLM usage filter into the right places, use-cases with higher leverage, LLMs to create a UI that is shipped to all users over LLMs creating UI on the fly every time. Costs and time will dictate this just like they have dictated how every other technology is used.