Software That Takes Your Shape

Adapted from my talk at RenderATL, 13 August 2026. You can watch the talk here and poke at the proof-of-concept on GitHub.

---

"It would take a new kind of model."

I said that from a stage at SXSW in March 2024. The talk was about interfaces that stop being built in advance and start assembling themselves for whoever is standing in front of them, and I was sure about the shape of it. Composed at runtime. For one person. What I couldn't see was how you'd get there with the models we had, so I proposed we'd need a new class of them, trained on human-computer interaction the way language models are trained on text. I called it a Large Experience Model. I pointed at Rabbit's Large Action Model as the template to follow.

Then I spent two years waiting for a model that never arrived. Nobody trained a Large Experience Model. Nobody needed to. The capability I said was missing turned up inside the models we already had, and when it did, the problem did not move an inch. I had it filed as a capability problem. It was never a capability problem.

The one thing software has never done

Look at the boots by my back door. A few hundred miles and they've taken the shape of my feet. A baseball glove takes the shape of one hand. A cookbook falls open to the page you actually cook from. The stone step in an old building has a dip worn in the middle where everyone walks.

Everything we own gets more personal the longer we use it. Software doesn't.

The application you've opened every morning for three years is identical to the one a stranger opens for the first time this afternoon. All that use went somewhere, and it did not go into the product. It went into you. You learned where things live, you built the workarounds, you memorised which of the seven tabs has the thing you actually need, and you stopped noticing the four features you've never once opened. You did the conforming. The software has your data. It doesn't have your shape.

That's the whole reason to care about any of this. An interface composed for you, in the moment you ask for it, is not a gimmick. For the first time, the adaptation runs the other way. The software takes your shape instead of you taking its.

This is the killer use case for a real-time UI. Software that evolves toward the person using it, the longer they use it.

What a real-time UI actually is

A real-time UI is a user interface a large language model renders in real time, in the moment you ask for it. When you open the app, a model decides which components appear on the page, in what order, at what depth, and what gets computed across them. It decides right then, for you. Nobody drew that page. Nobody has ever seen it. It didn't exist until you asked for it. Every piece it was built from was designed by a person, in advance and on purpose.

Start with why the design matters at all, because it's easy to wave past.

Put a recipe on a page as a paragraph of prose. Ingredients, times, method, all of it, perfectly accurate. Now put the same recipe in a card, with the photograph and the total time and the rating sitting where your eye already expects them. Same information. One of them you read in a second. That card is doing more work for a person than the words in it ever will, and shaping how people meet information is the thing we are all actually in the business of.

So interfaces matter. The design is the product, not decoration laid over it. And brand matters just as much, because the second an interface stops looking like it came from you, people quietly stop trusting that it did.

A word for the designers, because this is where a lot of you have quietly checked out. The story you keep getting handed is that all of it ends in a chat box. Brand flattened into sameness, experience templatized, craft turned into something a machine does cheaply and badly while you watch from the side. I think that story is backwards. If the design is the product, and the model can only ever work inside what you define, then you are not being pushed to the margins. You become the thing everything else has to run through. This is the opening to matter more, not less.

For thirty years it has been fixed. Somebody designed the screen once, and everybody got that screen. Personalization was supposed to soften that. It didn't, and not because anyone did it badly. Personalization only ever decides which of these you get. A generated interface decides what this should be. One picks from a menu somebody wrote in advance. The other composes.

The difference that matters most is subtraction. Recommendation engines almost never take anything away, because removing something risks removing the thing you wanted, and there's no signal safe enough to justify the gamble. So products accrete. Every feature anyone might need stays on the screen forever, and the interface you use in year three is the one built for the person you were in week one. For somebody two years into a product, the single most valuable thing it could do is stop showing them what they've already decided about. Adding is easy, and it's what we've all been doing. Taking away requires knowing something.

Models can work in layout now, not only in words. That means the experience itself can finally be the thing that adapts, built from components you already designed, so it still comes out looking like your product.

So here's the honest question I put to a room of designers in Atlanta: would you let it do that live, unattended, in front of real users?

Why it's suddenly possible

Ask a frontier model to build you an interface today and it will. It'll be plausible, it'll run, and it will not be yours. Wrong type. Wrong spacing. Some button with a gradient on it that's never appeared anywhere in your product. For a company that's spent years and real money making sure a hundred screens all come from the same place, plausible is not a passing grade. It's a liability with a login.

While I was waiting, everybody else solved this from the other end. Shopify shipped MCP-UI. Anthropic standardised the same idea as MCP Apps. Google's A2UI sends only the name of a component and lets your client render it. Salesforce shipped a generative canvas that assembles CRM dashboards on the fly and doesn't come out a hallucinated mess, because it can only select from their own design system. Groups with nothing in common, arriving at the same answer without coordinating, which usually means the shape of the problem forced it rather than that anyone was clever.

Not one of them lets the model draw. Every single one has it picking from components a human approved in advance. The designer Josh Clark puts it better than I would: the model supplies the adaptivity, the design system supplies the consistency, and neither one works without the other.

So the work isn't in the model. It's in what you hand it. You define what's allowed: when a component may appear, what must always appear and where, what has to stay together. The model decides only which pieces, for this person, right now. An allergen warning sits immediately above the dish it's about, and no model anywhere gets a vote on that. A comparison table only shows up when there are genuinely three things worth comparing. You set the conditions. You don't build the outcome. Then code checks the model's work every single time.

That last reframe is the one I didn't see coming. For fifteen years we sold design systems on efficiency: consistency, velocity, fewer arguments about button radii. And every one I've ever seen funded that way became the thing nobody wanted to own, maintained out of duty by whoever drew the short straw. We were quietly building the substrate for this the whole time. The ceiling on what a model can safely do inside your product is set by how well you've written down what your components mean. That is a limit you control.

So I built it

Theory is cheap. I wanted to know whether any of this survives contact with something real, so I built a recipe site called Mise and gave it a deliberately loud brand, the kind that goes obviously wrong the moment something off-key lands on the page. Two rules carry the entire build. The model never draws anything, and what it picks from is one file I wrote.

Two of the households in the demo filled in byte-identical signup forms. Same size, same diet, same stated skill, the same nine things in the pantry. Their pages have almost nothing in common, because the form is not what the system is reading. It's reading what each person has actually cooked. A third household gets a page with no recipe on it at all. That one is a learner ninety days in, who abandons long ingredient lists and has never repeated a dish. A strange thing for a recipe site to decide, and exactly the right thing for someone who needs the technique rather than another dish.

On stage I struck one component out of that file, saved it, and both pages rebuilt around the absence in about ten seconds. Nobody had written a template for what to do without it.

Three things surprised me, and I predicted none of them. It looked designed, not generated. The model turned out to be the smallest part of the system: eight of the ten steps that build a page never touch a model at all. And it costs cents a page.

What I still don't know

A fixed component set is not a guarantee of correctness, and this is the objection I take most seriously. The engineers at Shopify make the case better than I can. Commerce UI is deceptively complex. Dependent variants, bundle pricing, inventory that moves while you're looking at it. A model can assemble a product card out of nothing but approved components and still be wrong, because the constraint does not live in the components. It lives in the relationships between them. Valid parts, invalid whole. My assemblies are the shape of an answer to that. They are not a proof, and a recipe site is not the hard case.

The other gap is data, and it's the one that will actually stop you. Analytics knows what a crowd did. This needs what one person did, and the difference between somebody glancing at a recipe and somebody actually cooking it on a Tuesday is not sitting in your warehouse. You have to build a product that can tell those two apart, and keep what it learns. Almost nobody has. I think that's the real work item hiding behind all of this, and it's a bigger one than the design system.

The web is ours to make

Picture it a few months in. The recipe app opens straight to tonight's dinner. The training plan routes around the knee you hurt in March. The tool you're learning on has folded away the parts you've already mastered and left the one thing you're still fumbling.

Nobody set a preference. Nothing asked. The software just took the shape of the person using it.

None of that is waiting on a breakthrough. The web became the web because a generation of makers took a pile of raw technology and refused to leave it as plumbing. A markup language. A scripting hack. A way to shuttle data around. They built the storefronts and the feeds and the maps and the tools, the whole living thing we now spend our days inside. Every good part of it started with someone deciding the primitives were an invitation, not a limit.

We've just been handed a new one. Interfaces that compose themselves, for one person, in real time. Software that finally adapts to us instead of us to it. It's sitting there right now, in the models you already have and the components you already own, waiting for someone to build with it.

That's the opportunity in front of us. Not a faster chatbot. A web that takes the shape of the people who use it. Go make that.

The proof-of-concept is linked up top. Go break it, and let's talk.