Your Design System Has a New User, and It’s an Agent

Design systems in the AI era, as of October 2026. Written by a frontend dev who spends too much time inside table components.

You’ve probably seen this. You ask an AI tool for “a settings page,” and what comes back has an oversized sans headline, a purple gradient, rounded cards in a bento grid and soft shadows everywhere. It looks fine. It also looks like every other app shipped this year.

I’ve spent the last few months fixing table components in Nuxt UI, and I’ve sent PRs to Ant Design and Chakra’s Ark UI. So I’ve been thinking about one question a lot: if agents write more and more of our UI, do design systems still matter?

My answer, after going through a pile of 2026 docs, surveys and blog posts, is that they matter more than before. The difference is who reads them. A design system used to be a UI kit for humans. Now it’s also context and infrastructure for agents, and that shift changes what we as frontend engineers should be building.

Why everything looks like shadcn (it’s not shadcn’s fault)

The “AI slop” look has a fairly boring cause. Take v0, one of the best-known generators: it uses shadcn/ui as its default component system (GeekyAnts), and it was trained on those defaults directly. v0’s own (now legacy) design-system docs say v0 is “specifically trained on the default implementations” of shadcn/ui, so heavy customization can lead to unexpected output. When every team starts from the same defaults, everyone ends up with the same app.

GeekyAnts summed it up well: “The shared library is not the problem. Starting from a blank page is.” I agree. shadcn is a good library. The problem is an agent with no context falling back on the most statistically average UI it has seen. Creative Bloq adds a fair point: convergence was already happening because of platform design systems, and AI just speeds it up, since models prefer common patterns and their output gets fed back into the web.

Teams using a custom library had a different problem: the AI ignored it. On the Figma forum through 2025, users reported Figma Make skipping their attached library components and building look-alike buttons and switches instead. It couldn’t see variants or tokens, and one person said they got better results without the library.

The data backs this up. In zeroheight’s State of AI in Design Systems 2026, design generation got a net satisfaction score of −53, which the report calls the biggest miss. 59% of teams report UI being built outside the design system. Caveat: the sample is 123 practitioners, mostly in-house design leaders at mid-to-large tech companies. That’s small, but I think the direction is clear.

Design systems are becoming APIs for agents

Over the past year, nearly every serious player shipped some kind of “API for agents” for their design system.

Figma: from context-only to writing on the canvas

Figma’s MCP server launched in June 2025 as a desktop-only “Dev Mode MCP server” beta (AlternativeTo) that provided design context only: variables, components and layout data (gihyo.jp). Now it’s a remote-first server at mcp.figma.com/mcp (Figma docs) with 40+ tools, including get_variable_defs, search_design_system, Code Connect tools, and a create_design_system_rules prompt that generates a rules file for your codebase (Figma docs). In March 2026 Figma opened the canvas itself to agents with use_figma. It’s free during beta and will later become usage-based, and Figma says plainly that output is non-deterministic.

The key part for frontend people is Code Connect. If your Figma components are mapped to real code components, the MCP server names the component to import rather than describing its shape (Savvy). One catch: Professional plans allow only one active framework (Figma docs).

Storybook: your real component API as context

Storybook MCP arrived with Storybook 10.3 in March 2026. It generates a components manifest (props, stories and docs) and lets agents write stories and run component and accessibility tests, so they can fix their own mistakes. Storybook’s benchmark on the Reshaped library reported about 12.8% better code usage, 2.76x faster runs and 27% fewer tokens. That’s one library, measured by the vendor, so treat it as a promising data point and not proof. It launched for React first, and the current docs now list Vue, Angular and Web Components too. The docs also say the MCP server itself works in every Storybook project, and only the docs toolset depends on your framework (Storybook docs). It’s still in preview, the components manifest is off by default, and the docs warn that the API may change.

What I like is that Storybook reflects the code that actually exists, prop types included, rather than what the design file says.

shadcn: registries as distribution for agents

shadcn reframed its registry format as a distribution layer. The shadcn MCP server lets agents browse, search and install from any namespaced registry, private authenticated ones included. In March 2026, shadcn CLI v4 added skills for coding agents, presets that pack your design system config into a short code, and --dry-run/--diff flags (shadcn changelog). There’s also @shadcn/lint, whose rules include no-raw-colors, no-arbitrary-values and no-restyle (alexop.dev). So the library everyone accuses of causing sameness is now shipping tools to stop agents from drifting.

The big systems ship their own MCP servers

This is the part I find most interesting as a library contributor:

Nuxt UI hosts an MCP server at ui.nuxt.com/mcp with tools like search-components, get-component, get-component-metadata and get-migration-guide (Nuxt UI docs). After all that time in its Table component, I like knowing an agent can look up the real props instead of guessing them.
Ant Design includes an MCP server in @ant-design/cli (antd mcp) with tools such as antd_token and antd_semantic. It supports version pinning and also publishes llms.txt and llms-full.txt (ant.design).
GitHub Primer ships @primer/mcp with 19 tools, including find_tokens, lint_css and review_alt_text (Primer).
IBM Carbon runs a hosted MCP with a code_audit tool and a “carbon-builder” skill (Carbon).
Shopify Polaris comes through the general Shopify dev MCP (shopify.dev).

Notice the trend: the leading systems go beyond retrieval and add validation tools like lint, audit and alt-text review. The design system works as a guardrail as well as a reference.

Plain text still matters: llms.txt and DESIGN.md

The MCP server doesn’t have to be the only option. Atlassian’s llms.txt points to separate files for tokens, primitives, components and styling. Google open-sourced the DESIGN.md format from Stitch around April 2026: YAML tokens plus prose rationale in one file, with a CLI that exports to Tailwind or DTCG. The format is still alpha (The Decoder). Vercel publishes a design.md that gives agents a bounded vocabulary of classes and tokens so they stop inventing spacing and type.

Not everyone is convinced. One critic argues DESIGN.md “adds another layer rather than consolidating” and points out gaps such as no way to build dark or light modes and no motion in the alpha. Fair point.

Tokens finally have a standard, and semantic names matter

On 28 October 2025, the W3C Design Tokens Community Group shipped the first stable spec, 2025.10 (W3C DTCG), with Format, Color and Resolver modules. It covers theming and multi-brand, modern color spaces like OKLCH and Display P3, and aliases. One nitpick: it’s a Community Group report, not a W3C Recommendation, so “W3C standard” isn’t quite the right label.

Adoption a year later is real but uneven. Style Dictionary 5.x has been adding 2025.10 features step by step; for example, 5.4 added support for the new object-style dimension tokens (npm release history). Penpot stores tokens in DTCG natively (Tokens Studio). Figma’s native export is DTCG-aligned, but users report that composite tokens like typography and shadows don’t export, and that export naming doesn’t follow DTCG (Figma forum). “DTCG-compliant” means slightly different things in different tools.

Why should a frontend engineer care in the agent era? Because of semantic tokens. Here’s a tiny DTCG-style example:

{
  "color": {
    "blue": {
      "600": {
        "$type": "color",
        "$value": { "colorSpace": "srgb", "components": [0.1, 0.4, 0.9], "hex": "#1a66e6" }
      }
    },
    "gray": {
      "50": {
        "$type": "color",
        "$value": { "colorSpace": "srgb", "components": [0.98, 0.98, 0.98], "hex": "#fafafa" }
      }
    },
    "action": {
      "primary": { "$type": "color", "$value": "{color.blue.600}" }
    },
    "surface": {
      "elevated": { "$type": "color", "$value": "{color.gray.50}" }
    }
  }
}

The way I think about it: a human can work out that blue.600 is “the button color,” but an agent just sees a blue, while color.action.primary tells it where the value belongs. MindStudio argues the alias layer is the one agents interact with most, and Christine Vallaure says that if you do only one thing, do the semantic layer. She also covers “hypertokens”, an idea Figma’s Jake Albaugh floated in a Config 2026 talk: named bundles of style properties. It’s a concept, not a shipped feature or an official Figma announcement.

What the numbers say (read the fine print)

I’ll use a few numbers, carefully:

Stack Overflow 2026 (30,000+ respondents): 73% of people using AI coding assistants or agents use them daily, 66% of AI users work with coding agents, and the best sources of trusted context are project goals and requirements (85%) and code and docs (73%) (Stack Overflow). To me, that last point is the case for design systems as context in one line: agents are trusted when they’re grounded in your stuff.
Figma’s 2026 AI report (8,403 responses): developers doing design work went from 44% to 60%, and 65% of developers say design is at least as important as it was before AI (Figma). Figma sells design tools, so keep that in mind.
zeroheight 2026: 48% already run an MCP server, but only 17% call their docs “very AI-ready.” Their recommended order is docs first, MCP second, quality over adoption. And the main barrier? “Budget isn’t the blocker. Time is.”
UX Tools State of Prototyping 2026 (n=1,478 designers and builders): only 8.1% ship AI output with minor tweaks, and 40.2% picked design systems and tokens as one of their top three areas to invest time in over the next year (UX Tools).

Accessibility is where I’d be most careful. An AudioEye study of 15 AI-built sites found 55 issues per page on average. That’s bad, but slightly below their 62-per-page baseline for the typical site. So “no better than the inaccessible web” is more accurate than “worse than humans.” AudioEye is also a vendor. A CHI 2026 extended abstract analyzing 300 UIs from three commercial models found 541 semantic violations across six fault types, roughly 1.8 per UI. The CHI paper looks at whether content is actually meaningful, like alt="image" passing automated checks, so I don’t expect accessible primitives alone to write good labels for you.

One of my own Nuxt UI PRs (#7048) lets the as prop take an object, so you can pick the heading element in 11 components, from PageHero to BlogPost. It’s a small thing, but it’s the kind of semantic control I think a design system should hand to whoever is writing the page, human or agent.

The honest counterpoints

I don’t want this to read like a vendor pitch, so here’s the other side:

Much of the “AI-ready design system” story comes from vendors such as zeroheight and Figma, who have products to sell. Keep that in mind when you read their numbers.
Some of it is still React-first. Lovable’s design systems are React only for now, and Storybook MCP launched for React before other frameworks. Its docs now say the server works in every Storybook project, but the docs toolset depends on the framework, and Vue 3 support sits behind an experimental flag (Storybook docs). As a Nuxt UI contributor, this bugs me. @shadcn/lint does support React, Vue and Svelte, but it needs ESLint for Vue templates because Oxlint only exposes the script blocks (alexop.dev).
A lot of it is still early. Storybook MCP is in preview, Figma’s write-to-canvas is in beta (free for now, usage-based later), and DESIGN.md is alpha. Expect APIs to change.
MCP isn’t magic in production. One write-up lists RTL breaking, stale node IDs, near-identical hex values from different ramps, and agents inventing focus and disabled states inconsistently (Savvy). Even in one of Figma’s own internal examples, updating a slide deck, the agent had done the first 80% of the content work and a human finished the rest (Figma).
Lint passing doesn’t mean the UI looks right. You still need visual checks.

So what should a frontend engineer actually do?

Here’s what I’d do, and what you could start this week:

1. Write a rules file. An AGENTS.md or CLAUDE.md that lists your tokens, your components and your do’s and don’ts. The first, second and fourth rules below are adapted from Daniel Vaughan’s Storybook MCP template. The semantic-token rule is my own addition:

## UI rules
- Check for an existing component before creating a new one.
- Check a component's props before using it. Never invent props.
- Use semantic tokens only (color.action.*, space.*). No raw hex, no arbitrary values.
- Run story tests after every component change.

If you use Figma, try the create_design_system_rules prompt to get a first draft.

2. Add a semantic token layer if you only have primitives. Name things by intent, not by appearance. In my view, that’s the cheapest improvement for agents.

3. Connect the MCP servers you already have. On Nuxt UI, Ant Design, Primer or Carbon there’s an official server waiting. On React with Storybook, try the addon. Keep it small, though: listing every doc can blow the context budget on large systems.

4. Make off-token values impossible, or at least loud. Use @shadcn/lint-style rules, or go further like Polar.sh, who moved to typed <Box/>/<Text/> primitives (<Box/> takes token names, never raw values). Their ADR says that as AI-authored UI grew, “that freedom became a consistency and correctness problem.” I think types steer agents better than review comments do.

5. Close the loop with verification. Story tests, a11y tests and screenshot comparisons at a couple of viewport widths. Don’t trust “it compiled.”

6. If you maintain or contribute to a library, treat machine-readable docs as a feature: clean prop types, examples, llms.txt, MCP. Your next user might be an agent.

Wrapping up

The fear was that AI would make design systems obsolete. What I actually see is the opposite: as I see it, the design system decides whether AI output looks like your product or like everyone else’s. Brad Frost calls the good version AI that’s “deliberately constrained to using the high-quality design system materials.” I’d say constrained in a good way.

So update your tokens, write that AGENTS.md, and if you see me in the Nuxt UI issue tracker, say hi. Probably in a table thread.

— Kazbek