Design is a model capability now - and why that changes agent UX

For most of the last decade, "the model" and "the design" were two different teams. The model returned text or JSON; a human decided what it should look like. That line has moved. Frontier models — Claude in particular — now have genuine design taste: give one a rough brief and it will return an interface with real hierarchy, restraint and internal consistency, not a wall of divs.

That sounds like a nice-to-have. It isn't. Design quality is the difference between an agent your team actually adopts and one that gets quietly abandoned — and it's now something you can ask a model for, if you constrain it correctly. This is the follow-on to generative UI: not just can the model return a component tree, but can it return a good one, on your brand.

What "design taste" means in a model

Taste isn't magic; it's a set of decisions made consistently. When we say a model has design sense, we mean it reliably does the things a good designer does without being told each time:

• Hierarchy. One clear primary action per view; secondary things recede. It doesn't give every button equal weight.
• Restraint. It leaves whitespace alone, resists decoration, and doesn't invent five accent colours when one will do.
• Systematisation. It reuses the same spacing, radius and type scale across a layout instead of hand-picking values per element.

Those are exactly the properties that make an interface feel "designed" rather than "generated." The catch: left unconstrained, a model expresses that taste in its defaults — generic, competent, and nothing like your product.

Generic taste isn't your brand

The mistake is asking a model to "make it look good." Good by whose system? The fix is to stop treating the model as a designer and start treating it as a very fast implementer of your design system. You supply the tokens and the component vocabulary; the model composes within them. It can't reach for an arbitrary hex value because you never give it the option.

 // The model doesn't get "design freedom" — it gets a palette of approved // primitives + tokens and must compose only from those. Anything it emits // is validated against this contract before it's allowed to render. export const uiContract = { // The ONLY colours, spacing and type the model may reference. No raw // hex, no arbitrary px — it names tokens, the runtime resolves them. tokens: { color: ['bg', 'surface', 'primary', 'para', 'stroke', 'ok', 'danger'], space: ['xs', 'sm', 'md', 'lg', 'xl'], text: ['label', 'body', 'title', 'display'], radius: ['sm', 'md', 'lg', 'pill'], }, // The component vocabulary. The model returns a tree of THESE, not raw // HTML — so every screen is built from your real, accessible components. components: ['Stack', 'Card', 'Button', 'Field', 'Table', 'Stat', 'Badge'], rules: [ 'Exactly one Button with variant="primary" per view.', 'Never set a raw colour or pixel value; reference a token by name.', 'Every Field has a visible label; every icon-only control has aria-label.', ], } as const 

Now the model's taste works for you: it still makes the good structural decisions — hierarchy, restraint, reuse — but it makes them in your tokens, so the output is on-brand by construction. The same idea underpins how we generate reports and documents: the runtime owns the styling, the model owns the content and layout choices within a fixed vocabulary.

Why this decides adoption

Here's the part that's easy to underrate. You can build the most capable, most secure agent in the world, and if the surface it presents looks like a 2005 admin form, people won't trust it with real work. Interfaces are how users judge software they can't see inside. A governed agent that feels native — familiar components, your type, your spacing — clears the adoption bar that a functionally-identical but ugly one never will.

That's why we treat generated UI as a first-class output with the same rigour as generated code: it's the thing standing between a powerful backend and a human deciding whether to rely on it.

The guardrails

Constrained generation is what makes this safe to ship, not just pretty in a demo:

• Design-system-bound output. The model returns a tree of approved components referencing named tokens — never raw HTML with inline styles. Off-brand output is unrepresentable, not just discouraged.
• Accessibility as a contract rule. Labels, contrast and focus order are validated, not left to the model's mood. A generated screen that fails the a11y check is redrafted, not rendered.
• A review loop. The same validate-and-repair pattern we use elsewhere: the model proposes, the contract checks, and a human can edit — and the edited version becomes the authoritative baseline.

Design used to be the step you did after the model handed back its answer. Now it can be part of the answer — provided you hand the model your system instead of asking for its taste. Do that, and "the model designed this" stops being a warning and starts being a feature.