AI's Design Gap Pt 2
Why the labs won't rescue us
In my last post, I argued we’re waiting for AI’s iPhone moment—the point where the interface finally matches the capability. Smartpohnes worked fine before; the iPhone made the interface disappear. AI works fine; but the interface is still there.
So who’s going to fix it?
Not the frontier labs.
The Capability Race
OpenAI, Anthropic, Google, and a handful of others are locked in one of the most expensive competitions in corporate history. They’re racing toward more capable models—better reasoning, longer context windows, fewer hallucinations.
This is important work. These improvements are real. But notice what they’re competing on: benchmarks. MMLU scores. Evals only the most hardcore enthusiasts can understand. The kind of things that show up in technical papers and investor decks.
What they’re not competing on: whether you can ask an AI to build you a spreadsheet and have it do something useful with that instruction.
I’ve tried this dozens of times. It’s maddening.
Hey chat, can you build me a financial model for this startup. Here’s their current financials, and I want to run a sensitivity analysis on their growth rate over the next 2 years.
The model understands what a spreadsheet is. It can explain Excel formulas in detail. It’s even smart enough to be able to perform most of the calculations I ask for.
But the actual task—”make me a spreadsheet that forecasts X”—falls into some void between capability and product.
This isn’t a capability problem. It’s a design problem.
Why The Labs Won’t Fix This
Three reasons:
1. Competition is on benchmarks, not experience.
When OpenAI announces a new model, they show charts. Reasoning performance up 15%. Coding accuracy improved. These metrics are legible to investors, to the press, to other researchers.
User experience improvements don’t chart well. “People find it 12% less frustrating” isn’t a headline.
2. Differentiation in the model is durable.
If one AI lab releases a new feature, it’s pretty costless and easy for every other to quickly imitate it.
The only durable differentiation (and moat) the labs can create from one another is in the model itself.
3. The Labs are Labs
Chat was always an engineering solution, not a design decision.
In the very way they describe themselves, the frontier labs fancy themselves as places of science, of engineering.
As such, they are first and foremost concerned with problems of science and engineering.
The chat interface wasn’t designed. It emerged. As far back as GPT-2, there were comments in the code at OpenAI saying “we should make this a chatbot!”
Language models predict the next token; a text box is the most direct way to surface that capability.
The engineers who built these systems weren’t thinking about user experience. They were thinking about demonstrating capability. Chat was expedient - the simplest possible way to distribute fundamentally new kind of technology.
Andrej Karpathy has said we haven’t figured out the “operating system” for AI yet. More precisely: he likens our chat-based interactions with AI assistants today to working with command-line interfaces in the mainframe era. We haven’t yet transitioned into the GUI phase.
We’re typing prompts into text boxes like it’s 1975.
The Wrapper Problem
The gap between capability and usability has spawned an entire ecosystem of “AI wrappers”—startups that take the raw API and add... something.
Most of these are doing the equivalent of building a slightly nicer terminal for the mainframe. A fancier chat window. Some preset prompts. Maybe a workflow that strings together a few API calls.
This isn’t the GUI revolution. It’s putting lipstick on the command line (I’m talking to you Claude Cowork).
The worst offenders are essentially Zapier with AI in the middle: “Connect your email to ChatGPT, which sends to Notion, which triggers Slack.” These are basic workflows masquerading as products. The moment the underlying API changes, they break. The moment a competitor adds a feature, they’re obsolete.
They’re not solving the design problem. They’re papering over it.
Will It Just Be Apple Again?
In my last post, I used the example of the Blackberry Pearl as the predecessor to the iPhone.
Apple took existing tech, packaged it better, and took over the market.
It’s not even a metaphor in this case.
Apple’s struggled in the AI race, and everyone kind of keeps expecting them to figure something out.
Plus, for a technology that hungers for context and source data, there is no one better positioned than the makers of the device that carries our entire lives on it.
Conversely, Apple may no longer enjoy design supremacy. Tim Cook’s best selling product has been a set of headphones. Jony Ive is at OpenAI now.
So will it be Apple? Time will tell.
Different Problems, Different Builders
The capability race and the design race require different kinds of companies. The organizations best positioned to build powerful models are not the organizations best positioned to build usable products.
This has happened before. The companies that invented the transistor didn’t dominate consumer electronics. The labs that developed the internet protocol didn’t build the applications that made it useful.
There’s a gap between what the technology can do and what people can do with it.
I call this the Design Gap.
The frontier labs will keep racing. The capability will keep improving. But the design will be solved by different players, operating under different incentives, asking different questions.
Whoever figures out the AI interface won’t be optimizing for benchmark performance. They’ll be optimizing for the moment when you forget you’re using AI at all.
Originally published on Griff’s Substack on 6 February 2026.