A few days ago I read a post by Mircha Emanuel D’Angelo about the death of the user interface. The kind that sticks with you. I read it, I reread it, and then I started noticing it in real life too: how much mental energy we spend just to remember where you do something—on which tab, in which menu, in which product.
And while I was trying to fall asleep, the question became more annoying and more interesting: if the UI really stops being the center of software, what happens to the rest? Because maybe it’s not just the screen that dies. Maybe the application as we’ve known it dies.
If the UI dies, it doesn’t fall alone #
When we say “app”, we usually mean a fairly clear object. It has a name, an icon, a place in the dock, a monthly subscription, a personality. And above all it has a boundary. Inside is Notion’s world. Inside is Jira. Inside is Salesforce. Outside is everything else.
I realized that boundary, often, isn’t there because the problem requires it. It’s there because the business model requires it.
A lot of modern software is built like a fence. Not out of malice, maybe. It’s just that for years the simplest way to monetize has been this: take a set of features, package them up, build an interface around them that becomes familiar, put the user’s data inside, and then make leaving painful.
Mircha draws a parallel that I find illuminating: MCP servers as “new Unix programs”. And if that’s true, then the natural consequence is another one, a bit more uncomfortable. SaaS applications, seen from there, resemble mainframes. Big monoliths born in an era when distributing software was expensive and the only way to get paid for it was to build walls.
In a world where an agent can compose small, precise capabilities on the fly, that wall becomes more of a burden than a protection.
The generative interface: not designed, summoned #
There’s a passage in Mircha’s post that made me stop and think. The idea that the GUI shifts from control panel to display. And it made me ask: what if it were neither?
Maybe the interface, in the next round, becomes ephemeral.
Today a designer, when designing a screen, is making a compromise. They look for a layout that works “well enough” for many people, in many contexts. The result is often an interface that’s solid, consistent, tested, but inevitably generic. It has to serve everyone, so it serves no one perfectly.
With an agent in the middle, that compromise could break.
I don’t mean “do everything via chat”, which is a convenient caricature. I mean a system that, given your intent, generates the right interface for that moment. A form that isn’t generic, but with those fields, in that order, with sensible defaults for your case. A dashboard that isn’t standard, but the visualization that answers a specific question, with the necessary data and no noise.
These UIs aren’t maintained. They aren’t versioned. They don’t need a roadmap.
They’re summoned and then they disappear.
And the unsettling thing is that it’s not even sci-fi anymore. Today we already see models that generate components, pages, small artifacts in React in real time. It’s still rough, yes. But the direction is hard to ignore.
At that point the designer’s role doesn’t disappear, but it changes skin. From screen designer to designer of generative systems. Design system, constraints, patterns, rules. Work more like building a grammar than drawing sentences.
The agent as an operating system #
Another consequence that keeps coming back to me is this: maybe the right metaphor for the agent isn’t “assistant”. It’s “operating system”.
An OS does things we take for granted: it abstracts hardware, manages resources, offers a unified interface, lets different programs coexist and talk to each other.
The agent does something similar, one level up. It abstracts services, manages contexts, offers a unified interface (natural language), orchestrates different capabilities.
If this metaphor holds, then something almost inevitable happens: the agent becomes the platform. Not because everything “lives inside” the agent, but because everything passes through the agent. Just as today no software runs without an OS, tomorrow no service will be used without an agent.
And here comes the political, or economic, part, which is probably the most delicate. Whoever controls the agent controls the access point to software. It’s a position we’ve already seen in history, just with different names.
And I wonder whether we’ll manage to avoid the usual trajectory. The one Cory Doctorow calls enshittification. First everything is useful and open, then it becomes rent, then it becomes a toll.
From app to capability #
If the application loses meaning, what’s left?
What’s left is the capability.
A capability is an atomic function exposed via protocol, described in human terms, invocable by an agent. “Create an invoice.” “Search for this contact.” “Summarize these tickets and tell me the risks.” It’s not a product with a brand and a layout. It’s a building block.
And as soon as you think in terms of building blocks, the economics change too.
Today you pay a subscription for a bundle: a hundred functions, you use twenty, but the price is for all of them. Tomorrow you might pay per use, capability by capability, at the moment you need it. Fractions of a cent for a single action done well.
This throws three historical advantages of SaaS into crisis:
First, the interface as lock-in. If the interface belongs to the agent, it’s no longer yours.
Second, data as a prison. If data lives in personal vaults and access is via granular permissions, the fence loses power.
Third, the bundle. If the agent can compose the best for each piece, the monolithic package becomes less attractive.
At that point only one thing remains: the quality of the capability. Do one thing, do it better than everyone else. It’s Unix as a technical philosophy, but also as a business model. Elegant, and a bit ruthless.
The new literacy #
There’s another idea in Mircha’s post that I think is underestimated: “not knowing how to talk to AI” as a new form of illiteracy.
For decades we’ve called “digital literacy” something very specific: knowing how to use interfaces. Clicking, dragging, navigating menus, filling out forms. We built courses, certifications, professional roles.
If the agent becomes the main interface, all of that deflates.
The central skill becomes something else, and maybe it’s more human than technical. Knowing how to express an intention clearly. Knowing how to provide context. Knowing how to break down a problem. Knowing how to judge a result and iterate.
And here there’s a paradox that fascinates me. There are people who never really learned Excel, but can explain what they want with surgical precision. And there are power users who, put in front of an agent, don’t know what to ask.
The skills map gets redrawn.
And yes, the risk of a new digital divide is real. But there’s also a rare opportunity: for the first time, the advantage isn’t “knowing how to speak the machine’s language”. It’s knowing how to think and communicate well.
The European surprise: compliance as a capability #
There’s a piece of this story that, in my opinion, we can’t ignore in Europe.
While the American narrative tends to see regulation as a brake, here we’re building a regulatory framework that touches exactly the exposed nerves of a world of composable capabilities: AI Act, Cyber Resilience Act, Product Liability Directive, EAA.
In a system where an agent combines three capabilities from three different providers, the question “who’s responsible if something goes wrong?” becomes explosive.
If the law asks you for traceability, security, audit trail, explainability, then compliance stops being just a cost. It becomes a differentiating capability.
SBOM as the component’s passport. The agent’s action log as a requirement. Transparency as a competitive advantage.
And here there’s an almost ironic reversal: many historical demands of hacker culture—openness, accountability, verifiability—are becoming law. Maybe Europe, more than slowing things down, is building the trust infrastructure without which the agents world doesn’t hold up in serious companies.
2030, an ordinary day (maybe) #
I try to imagine a normal day, without wanting to do sci-fi.
You no longer have “apps” on your phone. You have an agent. You talk to it, write, maybe make a gesture. It orchestrates different services and you almost never see what’s behind the scenes. A bit like today you don’t think about microservices when a page loads.
The interface you see was generated for you, in that moment. In five minutes it no longer exists.
Commerce becomes conversation. “I need trail shoes, budget 150 euros, mixed terrain, I prefer a Vibram sole.” The agent knows your size, history, preferences, trusted sources. It proposes three options with a custom-made comparison. You choose, done.
At the office something similar happens. The PM doesn’t open Jira, they ask “where are we on Alpha?” and get status, risks, next steps. The sales rep doesn’t navigate the CRM, they ask “which deals are at risk this week?” and receive a briefing. The developer describes a behavior and the system generates, tests, deploys.
Data lives in a personal vault, encrypted and portable. Capabilities ask for granular, revocable permissions, and everything is logged. Every action produces an audit trail.
In that world, value sits in two things: good capabilities and trust.
A necessary realism #
Is it inevitable? I don’t know.
Transitions are never linear. There will be enormous economic resistance. Enterprise moves with an almost geological slowness. Habits change more slowly than press releases. And there are real technical problems: reliability on complex tasks, error handling in composition chains, security, costs.
But the direction Mircha brings into focus seems hard to ignore to me, because it’s supported by two concrete forces.
On one side the cognitive cost of traditional interfaces, which grows with every new SaaS.
On the other the ability of agents to reduce that cost, which grows with every iteration of the models.
When the distance between the two crosses a threshold, the transition becomes practical, not ideological. And for some use cases, maybe that threshold has already been crossed.
Mircha closes by asking who will build this future and with what values. I’m left with another question, a bit more personal and a bit more cynical: who will have the courage to build for this future, knowing it means dismantling the model that pays salaries today?
Because the dilemma, in the end, isn’t technical. It’s the willingness to cannibalize the present.
And the time to decide which side to be on, probably, isn’t infinite.
This post is born from reading "La morte dell’interfaccia utente come la conosciamo" by Mircha Emanuel D’Angelo. If you haven’t read it, I think it’s worth starting there.