Generative UI moves layout into the model's output space
For most of my career, interface was compiled and content was dynamic: designers drew the screens, engineers built them, and the model — when models arrived — filled them with text. Generative UI ends that division. The model now emits the interface itself: typed components streamed from tool calls, interactive widgets, in the maximal case a whole working application generated per prompt. Layout has moved into the model's output space, and that relocates the designer's job.
This is already running at two scales. At component scale, the Vercel AI SDK's streamUI pattern turns a tool call into a streaming React component — a flight card instead of a paragraph about flights. At page scale, Google Research demonstrated full interactive web apps generated per query, and the evaluation numbers are worth sitting with: raters preferred generated interfaces over markdown answers 82.8% of the time, and on ELO scoring the generated UIs (1710.7) landed within about 45 points of pages built by paid human experts (1756.0). Notably, that capability appears to be emergent — recent model generations produce structurally valid apps where models a generation older failed constantly. The direction of travel is not ambiguous.
Design systems become grammars
If the model composes the interface, then the design system stops being a Figma library and becomes a grammar: a vocabulary of components and a set of composition rules the generation must obey. That's not a metaphor — it's literally the architecture of the emerging protocols. Google's A2UI has the agent emit a declarative JSON component tree, which the host renders natively from a component catalog: a client-side registry of trusted, pre-approved components that constitutes the rendering contract. The agent can say anything expressible in the catalog and nothing outside it. The competing approach, MCP Apps, lets the agent ship self-contained HTML into a sandboxed iframe — more expressive, less governed. That fork — sandboxed code versus described data — is the central design decision of the space, and it's a designer's decision: how much expressiveness do you grant the model, versus how much control do you keep over styling, accessibility, and security?
Either way, the work changes shape. Instead of drawing screens, the designer defines the constraint system: which components exist, what states they carry, what compositions are legal, what the validation loop rejects. The Google system's quality comes less from the model than from its scaffolding — a system prompt built on a small set of hard rules (interactive-first, no walls of text, no placeholder data, verify facts before rendering them) plus post-processors that repair the output. Someone has to author those rules, and that someone is doing design, even though the deliverable is a grammar and a protocol rather than a mockup. Even the economics are a design input: every tool-wrapped component costs a few hundred tokens of context per turn, so a catalog's information architecture now has a token budget.
Where paragraphs still win
The concession: generation is slow and variable. Full-page generation runs one to two minutes — an eternity against a rendered template — and quality drifts run to run in ways a compiled interface never does. The experts still held the top ELO. And plenty of queries deserve a sentence, not an app; interactive-first is a bet the research made, not a law of interaction design. For stable, high-frequency workflows, hand-built UI remains correct.
But the boundary is moving in one direction. The long tail of interfaces nobody could afford to design — the one-off comparison table, the ephemeral calculator for exactly your question — is becoming addressable. Designers who treat the design system as a grammar, with rules a model can follow and a catalog a host can trust, are the ones who'll decide what that long tail looks like.