Imagine you've trained the smartest little model in the world. It can plan, it can reason, it can write, it can see. You sit down to give it to people. You open Figma. You drag a rectangle. You make it look like a text field. You add a send button. You ship it. Congratulations: you have just made a profound decision about what your model is, and you made it with the first shape that came to hand.
This is the move I see most often in 2026. A team will spend two years and a small country's worth of electricity training a system, and then thirty seconds choosing the shape of the box you talk to it through. They will tell you the model is the product. They will mean it. They will be wrong. The interface is the product. The interface has always been the product. The model is a brilliant ingredient that the interface either lets you taste or hides under mayonnaise.
01The chat box, considered as a building.
Let's start with the chat box, since almost everyone is in it. The chat box is a remarkable piece of design, but it is a piece of design — not a default. It encodes, quietly, a long list of opinions. It says: one user, one assistant. It says: turn-taking. It says: text is the only currency. It says: the past scrolls away. It says: this is a conversation, not a tool. It says: the model is a person; you are a person; you two are now talking.
None of those statements is wrong. All of them are choices. And they shape what your model is allowed to be. A model deployed in a chat box becomes, almost by gravity, a chatty assistant. The capability for long-horizon planning gets squeezed into a back-and-forth. The capability for visual reasoning gets squeezed into "here, I'll describe what I see." Anything the chat box can't easily express, the model effectively cannot do, because nobody ever asks it to.
02The interface is a theory of the thing.
When you draw an interface, you are writing — in shapes and gestures — a theory of what your system is for. A spreadsheet is a theory of calculation. A canvas is a theory of arrangement. A timeline is a theory of before and after. A search bar is a theory of I already know what I want. A chat box is a theory of conversation.
The most interesting AI products of the last two years have been the ones that noticed this and chose different theories. Cursor noticed that programmers don't want a chatbot, they want a co-pilot inside their actual editor — the interface is the editor, and the model is a small ghost living inside it. v0 noticed that designers don't want a description of a UI, they want the UI itself, and the interface is a canvas of components you can step into. Perplexity noticed that what people called "search" was actually "answer-with-receipts," and rebuilt the surface around citations instead of links. None of these are new models. They're new theories.
03Three examples, painfully concrete.
Let me try this on a few things I've actually built or tried to build, so this stays honest.
(a) the reading tool.
I made a small thing for reading dense papers. The first version was a chat box. You'd paste the paper. You'd ask questions. The model would answer. It was fine. It was also useless: every question I asked was, secretly, the same question — what does this section actually mean? — and the chat box was forcing me to translate that one impulse into a different polite English sentence every paragraph.
The second version had no chat box. It had the paper, rendered, with a strip down the right side that lit up paragraph by paragraph as I scrolled, showing the model's running gloss of that paragraph. No question, no answer, just here is what you are about to read, in smaller words. Same model. Different interface. Different product. I actually use the second one.
(b) the calendar agent.
I wrote about this elsewhere. The point that belongs here: the agent has no chat interface. It writes ✓ or ✕ into the titles of my events. That's the whole UI. If I'd built it as a chatbot, I would have a Slack channel with a polite robot in it nagging me about my reading time, and I would have muted it inside a week. The interface — title prefixes, no notifications, no streaks — is what makes it survivable.
(c) the failure.
I also tried to build an "AI design partner." It was a chat box that helped you think through layouts. I shipped it to friends. They used it for two days. Then they stopped. When I asked why, the most honest answer was: "I have to describe what I'm looking at, and by the time I've described it, I've designed it." The interface was making them do the work the model was supposed to help with. The chat box was the problem. Not the model.
04The lazy wrapper.
I think the reason so much of this gets called a "wrapper" is that, on a slide, the model is the impressive part. The model is the thing that took 800 GPUs and a year. The interface is the thing that took an afternoon. So we treat the model as the substance and the interface as the packaging — and then we wonder why every "wrapped" product ends up feeling the same.
They feel the same because the wrapper is the same. They all use the chat box. They all use the side panel. They all use the markdown bubble. They all assume turn-taking. They all assume one user, one assistant. The model varies; the building does not. Of course they feel the same. They are the same building with different tenants.
The teams who break out of this don't do it by training a fancier model. They do it by asking a question that sounds, embarrassingly, like a first-week design-school question: what does this thing actually want to be? A canvas? A console? A book? A mirror? A diary? A microscope? A camera? A loom? Each of those is a real shape, with its own gestures and its own grammar, and each one would absorb the underlying model differently.
05What to do instead.
- Pick the shape before the model. If you can't draw the artefact on paper without writing the word "chat," you have not designed it yet.
- Be willing to lose capability. Most great interfaces give up access to part of the model on purpose. The reading tool I described cannot answer arbitrary questions about the paper. That's the point. It does one thing, well, in one shape.
- Let the model live inside something. A document, a canvas, a map, a workshop. Don't make the model the room. Make the model the air in the room.
- Test for the second day. Anyone will play with a chatbot for an afternoon. The question is whether they open it on Tuesday, when nobody's watching. Interfaces that survive Tuesday are different from interfaces that survive a demo.
- Treat the chat box as a fallback, not a foundation. Keep it, for the cases your shape doesn't cover. But don't start from it. Starting from chat is starting from a building that's already half-built by someone else.
06The manifesto, briefly.
I am sixteen, which means I am allowed exactly one half-baked manifesto per essay, and I'm going to spend mine here: the interface is part of the idea. Not the wrapper. Not the packaging. Not the UI layer. The interface is where the model meets the world, and the shape of that meeting is what your product is. Everything else — the parameter count, the latency, the eval scores — describes the ingredient. The interface decides the dish.
When I look at the AI products I love, almost all of them have a shape that I could draw, quickly, on the back of an envelope, and that shape would be theirs — not generic, not interchangeable, not one of three industry defaults. The shape is the work. The shape is the proof that someone designed this thing instead of just configuring it.
So when you sit down to build the next AI thing, please — and I'm including myself in this — don't reach for the rectangle first. Reach for the question: what does this thing want to be? Sit with it long enough that the chat box stops feeling like an answer. Then build the answer that's left.
The model is the brain. The interface is the body. You can't ship a brain.