Habr column argues LLMs make graphical interfaces unnecessary

The first interfaces required people to know the machine's language: switches, punch cards, terminal commands. Windows, menus and the mouse removed that requirement for the mass user. A Habr column titled "Do I Even Need Interfaces?" goes further and claims that with the arrival of LLMs, the interface layer itself becomes redundant. The author promises to show this in practice, but the RSS announcement contains only the introduction, and the demonstration is hidden behind the cut. So we examine the thesis itself and its limits.

Where the layer between human and program came from

The author frames his argument as a history of translations. At first, a person wrote to the machine in its own language, and a single wrong character meant nothing would happen. Once computers became a mass-market product, remembering dozens of commands and parameters stopped being realistic. Windows, icons and the trash can appeared: instead of typing a delete command, users simply dragged a file, and instead of a list of operations they saw objects and the actions available on them.

The key point is that the machine kept executing the same exact commands all along. Only the translator between human intent and the function call changed. That translator is what we call the interface.

The simplified timeline the reasoning rests on:

• 1950s: punch cards and switches, the human speaks the machine's language;
• 1960–1970s: the command line, where you have to remember syntax and parameter order;
• 1973–1984: from Xerox Alto to Macintosh, graphical windows and the mouse pointer;
• 2007: iPhone, direct touch of objects on the screen;
• November 2022: ChatGPT launches, and a request is phrased in plain language.

What exactly LLMs change

If an interface is needed as a translator, a language model looks like a very strong candidate for the job. A person writes "remove the duplicates from the report and send it to Marina," and the model finds the right operations and calls them itself. Technically, the groundwork is already in place: tool-connection protocols such as MCP, introduced by Anthropic in November 2024, and agent frameworks let a model call application functions directly, bypassing the buttons.

In this logic, a button is just an intermediate link that the user presses by hand. An agent presses the same thing through an API, and faster.

The thesis has weak points, however, and the author will have to address them in the main part.

• A chat essentially remains a command line, only with a parser far more tolerant of phrasing.
• A graphical interface shows what is possible at all. An empty input field does not.
• A window with data lets you verify the result at a glance. A text message saying "done" offers no such check.
• Undo, confirmation and action history are built into a GUI. In agent scenarios they have to be designed separately.
• Tasks that require precise spatial selection, such as selecting an area on a photo or fixing a cell in a spreadsheet, are faster with a mouse than with words.

Practical takeaways for product teams

Even if you agree with the author only halfway, priorities shift. First, expose the application's functionality through an API and well-described tools so that an agent can use it. The interface then changes from the main entry point into a control panel: it shows what the agent did and lets you quickly roll back the result.

For developers, a simple test is useful: which of your scenarios can be completed with a single phrase, and which cannot be done without a screen. Hand the former to the agent and keep the latter visual. Separately, you need an action log, confirmation for irreversible operations and clear error messages.

The author is publishing the full version with the demonstration on Habr. For now, the main point is already visible: the question is no longer "how do we make the button more convenient," but "does a person need this button if an agent will press it."