Generative UI
AI-driven or procedurally-generated UI where layout, content, and component arrangements are composed dynamically in response to content, user context, or model output — rather than being hand-authored for each state.
Plain English
Traditional UI design is a finite set of hand-crafted screens: the designer builds a dashboard layout, a product detail page, a settings panel. Generative UI breaks that model. Instead of screens, you define a palette of components — a stat card, a chart, a recommendation list, a text summary — and let an AI or algorithm compose them into a layout that fits the current data, user role, or conversational context. This is how Vercel's AI SDK generates chat interfaces, how copilot sidebars render contextual tools on demand, and how future dashboards will adapt to each user's workflow. The designer's job shifts from "design every screen" to "design the atoms and the rules — let the system compose the molecules." It is simultaneously the most powerful and most unpredictable design paradigm in practice today.
Technical
Implementation patterns: (1) Server-driven UI — the backend sends a JSON layout descriptor (`{ type: "grid", children: [{ type: "stat-card", props: {...} }, ...] }`) and the frontend renders it with a recursive component renderer. (2) AI SDK streaming — using Vercel AI SDK's `streamUI()` or Anthropic tool use, the model returns structured tool calls that the frontend maps to React components. The model selects which components to render and with what props. (3) Procedural layout — an algorithm scores and arranges components based on content priority, user behavior data, or A/B test assignments. Key architectural concerns: all components in the generative palette must be fully self-contained and prop-driven with defined interfaces (TypeScript or PropTypes), since the system — not a human — is composing them. Use a component registry: `const registry = { "stat-card": StatCard, "chart": Chart }` and `const Component = registry[type]; return <Component {...props} />`. Guard against XSS and malformed props from AI output — validate all AI-returned props through a schema (Zod) before passing to components. For layout, CSS Grid named areas or a flexible Bento Grid pattern handles unknown component counts gracefully.
Live Demo
Generative UI
AI-driven UI could regenerate layout compositions from the same content. Each click produces a new bento-grid arrangement — same cards, different structure.
Design Tokens
Colors, spacing, and typography in one place.
Components
Reusable UI building blocks.
Motion
Animation principles.
Layout A — Left hero
Generative UI lets AI recompose layouts from fixed content — giving users a personalized structure.
Usage
✓ Good usage
A copilot sidebar that, when a user asks "show me this week's revenue breakdown," uses Anthropic tool calling to select a LineChart component, two StatCard components, and a TextSummary component — rendering them in a vertical layout with real data props, all composed by the model without a developer hard-coding that specific dashboard view.
✗ Bad usage
Allowing the AI model to return arbitrary JSX strings that are eval()'d or dangerouslySetInnerHTML'd into the page — generative UI must compose from a controlled component registry, never execute raw markup or code from AI output.
Recommended values
- Component registry: all generative components keyed by string type
- Validate AI-returned props with Zod before rendering
- Layout: auto-filling CSS Grid (auto-fill, minmax) adapts to unknown component count
- Streaming: render placeholder/skeleton until component type is resolved
- Fallback: always define a default component for unknown types
- Log rendered component trees for debugging AI composition errors
Common mistakes
- No component registry validation — rendering `registry[type]` without checking if `type` exists leads to silent null renders or crashes when the AI returns an unexpected component name.
- Skipping schema validation on AI-returned props — AI models can return malformed, missing, or adversarially crafted prop values; Zod parse before render.
- Designing components with layout assumptions baked in — generative components must be layout-agnostic (no hardcoded widths/heights), letting the container and grid determine their size.
- No fallback loading state — streaming AI responses render components progressively; each component needs a skeleton placeholder while its data resolves.
- Treating generative UI as a replacement for all UI design — it excels for data-driven, context-dependent surfaces; hand-crafted design still wins for fixed-purpose, high-polish screens.
AI Prompt Example
Copy this into Claude, Cursor, Bolt, or v0.
Build a generative dashboard surface. Define a component registry with at minimum: StatCard, LineChart, BarChart, DataTable, TextInsight, and AlertBanner. When the user asks a natural language question, send it to Claude with tool definitions for each component (name, description, required props schema). Stream the model's tool calls, validate each returned prop object with Zod, and render matched components into an auto-filling CSS Grid (`grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))`). Show a skeleton card for any component whose data is still loading. Log unknown component types to the console and render a fallback placeholder.