Carl Pei said it at SXSW last week. His company, Nothing, makes smartphones. He stood on stage and told the room: "The future is not the agent using a human interface. You need to create an interface for the agent to use."
A consumer hardware CEO publicly declaring that the product category he sells is the wrong shape for what's coming. That's not a hot take. That's a company repositioning before the floor disappears.
The room moved on. Most of the coverage focused on the "apps are dying" framing. That's the wrong thing to argue about. Apps are not dying next Tuesday. The question worth sitting with is quieter and more immediately useful: what does it mean that the thing we've been building — apps designed for human eyes, human fingers, human intuition — is increasingly being navigated by something that has none of those?
For thirty years, software design started with a user. A person with a screen, a mouse or finger, a working memory of roughly four things, limited patience, inconsistent behavior. Every design decision flowed from that starting point. Navigation was visual because users have eyes. Flows were linear because users lose context. Confirmation dialogs exist because users make mistakes and need to undo them.
Those constraints weren't arbitrary. They were load-bearing. The entire architecture of how software works was built around the specific limitations and capabilities of a human being sitting in front of it.
Agents don't have eyes. They don't navigate menus — they call functions. They don't get confused by non-linear flows — they parse structured outputs. They don't need confirmation dialogs — they need permission boundaries defined at initialization, not presented as popups mid-task.
When an agent tries to use an app designed for a human, it's doing something like what Pei described: hiring a genius employee and making them work using elevator buttons. The capability is real. The interface is friction. The agent scrapes what it can, simulates the clicks, and works around the design rather than with it.
This works. Barely. Temporarily.
The split is already visible in how developers describe their workflows.
Karpathy, in a March podcast, described moving from writing code to delegating to agents running 16 hours a day. His framing: macro actions over repositories, not line-by-line editing. The unit of work is no longer a file. It's a task.
Addy Osmani wrote about the same shift at the interface level: the control plane becoming the primary surface, the editor becoming one instrument underneath it. What used to be the center of developer work is becoming a specialized tool for specific moments — the deep inspection, the edge case, the thing the agent got almost right and subtly wrong.
These descriptions share a structure: something that was primary becomes secondary. Something that was implicit becomes explicit. The developer who used to navigate the editor now supervises agents. The app that used to be the product now needs to also be a legible interface for non-human callers.
Here's what that means practically, for anyone building software right now.
The apps built for human navigation will still work for humans. That's not going away. But increasingly, those apps will also be called by agents acting on behalf of humans — booking the flight, filing the form, triggering the workflow. And when the agent calls your app, it doesn't navigate. It looks for a contract: what can I call, what will you return, what happens when I'm wrong.
Most apps don't have that contract. They have a UI. They have an API if you're lucky. But the API was designed as a developer convenience, not as a primary interface for autonomous callers. The rate limits assume human usage patterns. The error responses assume a developer reading them. The authentication assumes a human with a session.
None of those assumptions hold for agents.
The developers who see this clearly are already building differently. Not abandoning the human interface — users still need screens, still need control surfaces, still need to understand what's happening on their behalf. But building the agent interface in parallel. Structured outputs. Explicit capability declarations. Error responses designed to be parsed, not read. Permission boundaries that don't require a human to click through them.
The spec is where this shows up first.
A product spec written for human implementation describes features. What the user sees. What they can do. How the flow works. A spec written for agent implementation describes contracts. What the system accepts. What it returns. What it guarantees. Where the boundaries are.
The [ASSUMPTION: ...] tags in spec-writer exist because that boundary — between what was specified and what the agent decided — is where agent implementations go wrong. Not in the happy path. In the assumptions that weren't stated because a human developer would have asked a clarifying question.
An agent doesn't ask. It fills the gap with whatever its training suggests is most plausible. If the assumption was wrong, you find out in production.
The spec that makes agent implementation reliable is the one that surfaces the assumptions before the agent starts. Not because agents are unreliable — they're remarkably capable within a well-defined contract. But because the contract has to be explicit in a way it never had to be when the implementer was human and could pick up the phone.
Carl Pei's argument is about device form factors. The smartphone built around apps and home screens doesn't fit a world where agents intermediate between intention and execution.
The same argument applies to every level of the stack.
The database schema built for human-readable queries. The API designed for developer convenience. The workflow tool that requires clicking through five screens. The SaaS product whose entire value lives in a visual interface with no programmatic equivalent.
None of these are broken today. They will accumulate friction as agent usage grows — the same way command-line tools accumulated friction when GUIs arrived, the same way desktop software accumulated friction when everything moved to the web.
The difference is pace. The GUI transition took a decade. The web transition took another. The agent transition is compressing.
The developers who will build the next layer are already asking a different question. Not "how does the user navigate this?" but "how does the agent call this?" Not "what does the confirmation dialog say?" but "what are the permission boundaries at initialization?" Not "how do we make the flow intuitive?" but "what does the contract guarantee?"
These are not new questions. They're the questions API designers have always asked. What's new is that they now apply to everything — not just the backend service, but the whole product. The human interface remains. It becomes one layer, not the only layer.
The future is not the agent using a human interface. The future is building interfaces designed for both — and knowing which decisions belong to which layer.
The developers who get that distinction early will have built the right foundation before it becomes mandatory. The ones who don't will spend the next three years retrofitting contracts onto systems that were never designed to have them.
That's the same pattern as every previous transition. The only thing that changes is how much runway you have before the friction becomes a crisis.
Right now, you still have some.
Top comments (2)
Your article is the first of its kind that I have seen. Well done and very proud to have been able to read it.
Keep going ! More people should read this and think long and hard about the implications that this brings.
But does having a well designed (REST) API not solve/address this?
Reminds me of a dev.to article that I came across some time ago, where someone said:
"What if I do not design a GUI or a frontend for my system but just let an AI agent, talking to the API, be my 'user interface' ?"
That sounded like a fascinating idea - maybe not an "AI agent" but more a kind of "chat bot" ...