---
title: "Software That Takes Your Shape"
publishedAt: "2026-08-17"
dateModified: "2026-08-17"
author: "Brian Fletcher"
role: "Principal, Co-founder @ FM"
headshot: "/images/brian_fletcher.jpg"
category: "Thoughts"
slug: "software-that-takes-your-shape"
excerpt: "For thirty years we made people conform to software. Real-time UIs finally let it run the other way: software that composes itself for one person and takes their shape the longer they use it."
image: "/images/posts/software-that-takes-your-shape.jpeg"
---

*Adapted from my talk at [RenderATL](https://renderatl.com), 13 August 2026. You can
[watch the talk here](https://www.youtube.com/live/KFt5dAY9ZRw?si=Qespvmw3W611HPgS&t=22296)
and poke at the [proof-of-concept on GitHub](https://github.com/BuildFM/render-conf-demo).*

---

"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](https://shopify.engineering/mcp-ui-breaking-the-text-wall). Anthropic standardised
the same idea as [MCP Apps](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/).
Google's [A2UI](https://a2ui.org/) sends only the name of a component and lets your client
render it. Salesforce shipped a
[generative canvas](https://bigmedium.com/ideas/links/salesforce-generative-canvas.html)
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](https://bigmedium.com/ideas/when-interfaces-draw-themselves.html) 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.