Case Studies
Practical patterns from shadcn, Radix, Stitch, Material, Fluent, and AI-first systems.
Key takeaways
- Across shadcn, Radix, Figma MCP, Stitch, Material, and Fluent, AI performs best when the system is explicit, composable, and inspectable.
- shadcn shows local copyable code is agent-friendly but needs ownership; Radix shows accessibility belongs inside tested primitives.
- Figma Dev Mode MCP is a freshness layer, not the source of truth; durable rules stay in DESIGN.md, specs, and verification commands.
- Stitch and DESIGN.md prove agents need a design intent layer above tokens and APIs, with both desired and forbidden examples.
- The strongest AI-first systems share four traits: inspectable code, accessible primitives, explicit intent, and governance against parallel UI.
Real systems show the same lesson: AI works better when the design system is explicit, composable, and easy to inspect.
Comparison Matrix
| System | What AI teams can reuse | Main caution |
|---|---|---|
| shadcn/ui | Local, inspectable component source and registry workflows. | Copyable code can diverge without ownership. |
| Radix UI | Accessible behavior primitives separated from styling. | Composition still needs product-specific rules. |
| Figma Dev Mode MCP | Live design context, frames, variables, and component names for coding agents. | Beta and plan-dependent details must be checked against Figma docs. |
| Stitch and DESIGN.md | A top-level design intent document for AI generation. | Intent docs must stay connected to tokens and components. |
| Material | Tokenized scale across components, motion, layout, and adaptive patterns. | Large systems can be too broad unless teams expose the relevant subset. |
| Fluent and Copilot | Assistant surfaces as part of the product design system. | Agent actions need confirmation, recoverability, and audit trails. |
| CopilotKit and assistant-ui | Runtime assistant UI patterns for product integration. | Generated UI still needs schemas, permissions, and design-system guardrails. |
shadcn/ui
shadcn/ui makes component code copyable and local. This works well for agents because the source is visible in the repository. The risk is uncontrolled divergence, so teams need ownership and update discipline.
Lessons:
- local code is agent-friendly;
- registry metadata improves automation;
- copyable components still need governance.
Operational pattern:
- Keep copied components owned by the product team.
- Track upstream changes intentionally rather than blindly re-running generators.
- Add local examples and anti-patterns so agents do not treat the registry as the whole system.
Radix UI
Radix shows the value of accessible, unstyled primitives. Agents can compose UI more safely when focus, roles, and keyboard behavior live inside tested primitives.
Lessons:
- accessibility belongs in primitives;
- styling and behavior should be separable;
- composition rules must be documented.
Operational pattern:
Use primitives for focus, roles, keyboard behavior, and dismiss logic. Put product density, visual hierarchy, and token choices in the local design system.
Figma Dev Mode MCP
Figma MCP gives agents a more direct path to design context than screenshots alone. It is useful for frame hierarchy, component names, variables, and current visual source-of-truth data.
Lessons:
- live design context reduces guesswork;
- remote and desktop server capabilities should be checked before documenting workflows;
- Figma names must map cleanly to code names for agents to make reliable choices.
Operational pattern:
Treat MCP as a freshness layer, not the only source of truth. Durable rules still belong in
DESIGN.md, component specs, token docs, and verification commands.
Stitch and DESIGN.md
Stitch popularized the idea that agents need a design intent layer above tokens and components.
DESIGN.md gives models brand mood, composition rules, and visual direction.
Lessons:
- agents need intent, not only API docs;
- markdown plus structured tokens is a useful hybrid;
- examples should show desired and forbidden patterns.
Operational pattern:
Use DESIGN.md to describe product feel, density, layout philosophy, and visual constraints. Keep
implementation details in component specs so the intent layer does not become a second API reference.
Material 3 and Expressive Systems
Material demonstrates how tokens, components, motion, and adaptive layout can form a large coherent system. AI workflows need the same coherence, but with machine-readable contracts.
Lessons:
- expressive design still needs constraints;
- component states and motion should be standardized;
- adaptive behavior must be documented.
Operational pattern:
Expose only the subset the team actually supports. Agents perform better with a narrow approved palette of components, tokens, and examples than with the full surface of a large external system.
Fluent and Copilot Patterns
Microsoft's Fluent and Copilot patterns show how AI assistants become part of the product UI itself. The design system must cover not only screens, but also prompts, suggestions, tool calls, and assistant surfaces.
Lessons:
- conversational UI needs design-system ownership;
- agent actions need confirmation and auditability;
- assistant surfaces should reuse product primitives.
Operational pattern:
Document assistant surfaces as normal product surfaces: prompt input, suggestions, tool calls, citations, confirmations, handoff, interruption, error recovery, and audit history.
CopilotKit and assistant-ui
Runtime assistant UI libraries show that AI interfaces are becoming part of product architecture, not just chat widgets. They help teams render messages, tool calls, actions, and generated UI in application context.
Lessons:
- assistant UI needs component contracts just like product UI;
- generated actions need permission boundaries;
- runtime UI should degrade gracefully when a tool, model, or data source fails.
Operational pattern:
Define schemas for tool results and UI blocks. Map those schemas to approved components before letting runtime generation reach users.
Practical Takeaway
The strongest AI-first systems share four properties:
- code and docs are easy for agents to inspect;
- accessibility is built into primitives;
- design intent is explicit;
- governance prevents generated UI from becoming a parallel system.