Generative UI
An experiment in letting a model compose interfaces on the fly and figuring out exactly where that is appropriate and where handcrafted UI has to stay.
Generative UI is interface composed by a model at request time instead of drawn by a designer ahead of time. I've been prototyping it for months, and the useful question isn't whether it works. It's where it belongs. My current answer: ephemeral, read-only, one-shot views. Almost nowhere else.
Where it earns its place
Chat is a good input and a terrible output. When someone asks a system "how did this month compare to last month," reading the answer aloud in prose is a downgrade from a chart a first-year analyst would make in thirty seconds. So my prototype does the obvious thing: the model doesn't render pixels, it emits structured JSON against a fixed set of primitives (chart, table, card, comparison strip), and a renderer I control turns that into a view. Try it — the fourth question is the one that matters.
Pick a question
The model answers in primitives you already approved. Shrink the vocabulary and the output stays legal.
This works precisely because the views are disposable. An answer to a question you'll ask once, in a shape you'll never see again. Nobody builds muscle memory on it. Nobody's job depends on it. If the layout is slightly awkward, the cost is a shrug. Generated UI is great at views that don't need to be good, only present: the long tail of one-off questions no team would ever staff a dashboard for.
Where it must not go
I spend my days on software for people who dispatch plumbers and price HVAC jobs. That work taught me a hard rule: high-frequency workflows are sacred. A dispatcher who touches the same board two hundred times a day has compiled the interface into their hands. Spatial memory, not reading. If the layout shifts because a model felt creative today, you've broken their tool. Feel it yourself:
Operators don't want novelty. They want the thing to be where it was yesterday.
Same rule for anything with consequences. A screen where someone sends an invoice, cancels a job, or commits a technician's afternoon needs to be identical every single time, because the review it gets is a glance, and a glance only works against a known layout. Using generated UI for a consequential action is design malpractice waiting to happen.
The line I keep coming back to: generate the answer, handcraft the verb. Reading surfaces can be synthesized. Acting surfaces cannot.
What the designer actually does now
The craft doesn't disappear; it moves up a level. Instead of designing screens, I'm designing the constraint system any screen must obey: which primitives exist, how they're allowed to compose, what the model literally cannot express. The schema is the design. A model can't violate a spacing rule that isn't representable in its output format.
That's also the honest fix for the determinism problem. People frame it as "LLMs are probabilistic, design systems are strict," as if better prompting closes the gap. It doesn't. You close it by shrinking the output space until every valid output is an acceptable design. The model gets a vocabulary, not a canvas.
The taste question of whether this composition is actually good doesn't go away either. It just gets exercised on the system instead of the artifact, which is harder, less visible, and exactly the kind of work I think interface designers should be fighting to own right now.