Design Systems Are Dead. Long Live the Design Contract.

The short answer

Design systems as we know them — static libraries of components, tokens, and documentation — are becoming a bottleneck. When Claude Design, Cursor, and open-source tools like Open Design can generate entire interfaces from a prompt, the limiting factor is no longer component inventory. It's the contract between what the AI promises and what the product can actually deliver.

A design contract is a runtime agreement: which components are available, what props they accept, what states they handle, and what constraints the AI must respect. Atlassian Design System has been moving in this direction with its focus on composable, state-aware components. Open Design takes it further by letting you link a codebase so the AI understands existing patterns. The next step is making that contract enforceable at generation time, not reviewed after the fact.

Key takeaways

• Static design systems don't constrain AI generation; they just give it more material to misuse.
• A design contract encodes constraints in the prompt and validates output against a schema.
• Tools like Open Design and Claude Design already support linking codebases — the missing piece is runtime enforcement.
• Invest in a small set of well-typed, state-aware primitives rather than exhaustive variant libraries.
• Automated validation in CI catches violations before they reach users; manual review doesn't scale.
• The teams that ship fastest with AI-generated UI will be those that treat the design contract as a product, not a library.

The real problem: AI doesn't read your documentation

Your beautifully maintained Storybook, your meticulously documented component API, your Figma with 47 variants of a button — the AI doesn't care. When you prompt Claude Design or Cursor to "build a dashboard for mortgage pipeline management," it will generate UI based on its training data, not your design system. Even if you link a codebase, the AI treats your components as suggestions, not constraints.

The result is interfaces that look vaguely on-brand but break on real data: empty states that don't exist, loading spinners that never resolve, error messages that don't match your tone. Every AI-generated screen becomes a manual review task. That doesn't scale.

Tradeoffs and when the conventional wisdom breaks

The conventional wisdom says: build a comprehensive design system, document everything, and the AI will use it correctly. That's wrong. Comprehensive libraries give the AI more rope to hang itself. More variants mean more combinations that haven't been tested. More documentation means more surface area for the AI to misinterpret.

The better approach is radical constraint. Define a small set of primitives — maybe 10-15 components — with strict prop types that encode every product state. A Button component doesn't have 12 variants; it has a variant prop that accepts three values, an isLoading boolean, and a disabled condition. The AI can only use what you expose, and you validate that usage against a schema.

This means accepting that some designs won't be possible. That's the point. The constraint is the product.

How this looks in a shipped product

I've been experimenting with this pattern in an AI-powered mortgage dashboard. The design contract is a TypeScript schema that defines every component, its props, and its valid states. The generation prompt includes the schema as context. The output is validated against the schema before it reaches the render tree.

Here's what changed:

• Generation time dropped because the AI stopped inventing components.
• Review time dropped because violations were caught automatically.
• Accessibility improved because the primitives enforce focus order and ARIA attributes.
• The team stopped maintaining a 200-component library and focused on 12 primitives.

Open Design's approach of linking a codebase and exposing 19 skills is a step in the right direction. The next step is making those skills enforceable — not just suggestions.

What to evaluate when adopting a design contract

If you're evaluating this approach, look for three things:

1. Schema enforcement at generation time. Does the tool validate output against your component API before rendering? If not, you're back to manual review.

2. State-aware primitives. Can your components handle empty, loading, error, and success states without the AI having to invent them? If not, every AI-generated screen will break on real data.

3. Prompt-bound constraints. Can you encode brand rules, accessibility requirements, and interaction patterns in the prompt itself? Tools like Claude Design support this with system prompts; the question is whether those constraints are actually respected.

A concrete next step

Stop adding components to your design system. Start defining the contract. Pick your three most frequently used components — Button, Input, Card — and write a TypeScript schema that captures every valid state and prop combination. Then write a prompt template that references that schema. Generate one screen. Validate the output against the schema. Fix what breaks. Repeat.

The teams that ship fastest with AI-generated UI won't be the ones with the biggest component libraries. They'll be the ones with the tightest contracts.