Right. But what if you dropped the human-facing UI, and instead exposed the backend (i.e. a database + CRUD API + heavy domain flavoring) to LLM as a tool? Suddenly you not only get a more reliable recognition (you're more likely to eat something that you've eaten before than completely new), but also the LLM can use this data to inform answers to other topics (e.g. diet recommendations, restaurant recommendations), or do arbitrary analytics on-demand, leveraging other tools at its disposal (e.g. Python, JS, SQL, Excel are the most obvious ones), etc. Suddenly the LLM would be more useful at maintaining shopping lists and cross-referencing with deals in local grocery stores - which actually subsumes several classes of apps people use. And so on.

> Just having an LLM is not the right UX for the vast majority of apps.

I argue it is, as most things people do in software doesn't need to be hands-on. Intuition pump: if you can imagine asking someone else - a spouse, a friend, an assistant - to use some app to do something for you, instead of using the app yourself, then turning that app into a set of tools for LLM would almost certainly improve UX.

But I agree it's not fully universal. If e.g. you want to browse the history of your meals, then having to ask an LLM for it is inferior to tapping a button and seeing some charts. My perspective is that tool for LLM > app when you have some specific goal you can express in words, and thus could delegate; conversely, directly operating an app is better when your goal is unclear or hard to put in words, and you just need to "interact with the medium" to achieve it.