Why Interfaces Exist When We Have LLMs

From the Command Line to the Interface — and Back Again

In the early days of computing, people had to learn to speak the machine's language: switches, punch cards, terminal commands. One wrong character and nothing happened. When computers became a mass-market product, this approach collapsed. You can't expect every user to memorize dozens of commands and their parameters. Windows, menus, icons, and the mouse arrived. You could drag a file to the trash instead of typing a delete command. A layer formed between people and programs — the interface.

Now that logic is flipping. LLMs let people speak to computers in their own language again, but this time it's the machine that understands natural language, not the human who has to learn the system's syntax. Take corporate analytics: instead of hunting for a section, picking a report, and configuring filters and conditions, you simply say: "Show me customers who used to buy regularly but stopped in the last three months."

The system parses the request itself, matches it against available data, builds a structured query, and returns the result. Or take flight booking: instead of selecting cities, dates, filters, and return-flight settings, you just say, "I want flights to Beijing next week with no layovers, ideally under 200 euros, returning Sunday evening."

How

You Ask and How You Get an Answer Are Two Different Tasks

When people talk about an LLM interface, they picture a chat window: text in, text out. In reality, these are two independent parameters. A request can be spoken aloud — long phrases with multiple conditions are faster to say than to type on a phone. A sentence like "show me the projects in my division where delivery times grew over the past month but scope stayed the same" can be spoken almost in one breath.

But the fact that you asked by voice says nothing about whether the answer should come back as voice. If you ask how spending by category has changed over the past six months, you might hear a brief voice summary: "Over six months, total spending was one million rubles, with the main categories being rent, infrastructure, and contractors." Meanwhile, a chart and a detailed monthly breakdown table appear on screen.

The same logic applies to text queries — you type something and get back a map, a chart, product cards, a confirmation form, or an interactive table. Choosing how to input a request and choosing how to display the result are two separate tasks.

Today, input and output are tied to a single device: you ask your phone a question, you get the answer on your phone. That's a limitation of current products, not a technical constraint. Devices could be linked through a shared user session: a smart speaker as the voice-input device with a short audio reply, a phone showing an interactive UI, a laptop as the primary work device, a TV in a meeting room as a large shared screen. Device selection becomes part of how the answer gets routed. Financial data shouldn't automatically display on the meeting-room TV, and a chart with 20 metrics simply can't be read aloud through a speaker.

Four Ways to Build This

No. 1. Controlled generative UI

The product defines a set of components: ExpenseChart, ComparisonTable, HotelCards, Map, Confirmation. The model doesn't draw the screen — it picks the right component, pulls the data, and returns structured JSON:

``` { "component": "ExpenseBreakdown", "period": "6m", "data": [...], "groupBy": "category" } ```

Designers and developers retain full control over appearance, behavior, accessibility, and error states. The model only selects a view and feeds it data. This approach is implemented in CopilotKit.

No. 2. Declarative descriptions from building blocks

The model doesn't get finished screens — it gets basic elements: containers, text, metrics, tables, cards, charts, buttons, forms. It returns a declarative interface description, which the client assembles using its own UI kit, preserving the design system everywhere: web, mobile app, other clients. The same response can be rendered across different environments. This is the approach Google's A2UI is developing.

No. 3. MCP Apps with ready-made interfaces

A tool returns an interactive interface that the client displays inside a sandboxed iframe. It can use standard web technologies — HTML, CSS, JavaScript — to build forms, charts, maps, and multi-step flows. This is already supported by various MCP clients and apps inside ChatGPT. Here, the tool provider has more control over appearance than the client does.

No. 4. Full HTML/CSS/JavaScript generation

The model generates code entirely on the fly. This offers maximum flexibility, but raises questions about quality, security, stability, and visual consistency. It may work fine for a prototype or a one-off task, but building a critical enterprise system around this mode is risky.

How Development Will Change

With the classic approach, products quickly accumulate: a home page, a report catalog, drill-down pages, a filter builder, saved views, a period-comparison screen, export options, settings. Every new use case adds more product states that need to be designed, built, tested, and adapted for different screen sizes.

With the LLM-based model, this logic shifts. Instead of anticipating every possible combination of components across separate screens, developers build a set of basic elements and rules for how they interact. The model assembles the right combination for each specific user request on its own. There end up being fewer screens, more logic inside the system, and the whole thing becomes easier to work with.