A design system is a set of rules for building screens. For ten years those rules had one reader, a person.
That reader is no longer alone. 84% of developers say they use or plan to use AI tools, and 51% of professional developers use them every day. Something else is building your screens now, and it is not opening your docs site.
If a machine cannot read your design system, it will invent one. Whatever it invents is what ships.
Five gaps, and what to publish instead
1. Tokens that live only in Figma
What teams ship: colour, type and spacing variables inside a Figma library, exported by hand when someone remembers.
Why it fails: the agent writing the component never opens Figma. It finds a hex value in an old file and copies that.
Ship instead: tokens in the W3C Design Tokens format. It reached its first stable version in October 2025, and Figma, Sketch, Penpot, Style Dictionary and Tokens Studio already read it. There is no excuse left about the format not existing.
2. A docs site written only for humans
What teams ship: a handsome site with usage guidance, dos and donts, and careful prose.
Why it fails: prose is not a contract. A model reads "use sparingly" and picks its own definition of sparingly.
Ship instead: something queryable next to the prose. Figma's MCP server has a search tool that looks through connected libraries for components, variables and styles. If your library is not connected, that search comes back empty and the agent builds a button from scratch.
3. No map from the design file to the code
What teams ship: a Figma component called Button, and a React Button that nobody has linked to it.
Why it fails: without the link, the model writes the markup again every time. You get forty buttons that look right and share nothing.
Ship instead: Code Connect, which points a design node at the real component file. One audit of 37 public design systems, re-read on 4 September 2026, found 6 publishing tokens in the standard format and 3 shipping Code Connect. Three.
4. Rules that live in code review
What teams ship: "never use the danger variant for a save action", held in a senior engineer's head.
Why it fails: review happens after the code is written. By then the screen exists and the rule loses the argument.
Ship instead: put the rule in the type. A list of allowed variants is a constraint the generator cannot talk its way past.
5. Waiting until agents are mainstream
What teams ship: a plan to do this later, when agents actually matter.
Why it fails: they are not mainstream yet. 52% of developers either do not use agents or stick to simpler AI tools, and 14% use agents at work daily. But 46% already distrust the accuracy of what these tools produce, against 33% who trust it. Unpublished rules are one reason.
Ship instead: pick one surface this quarter. Tokens first, then Code Connect on the ten components that appear on every screen.
What the machine asks for
| What the agent needs | Where it looks | What most teams have there |
|---|---|---|
| Token values | A tokens file in the standard format | A Figma library |
| Component names and props | A design system search endpoint | A docs site |
| Which code file to use | A Code Connect map | Nothing |
| Allowed variants | The component's types | A reviewer |
| When not to use something | Types and lint rules | A paragraph |
The four question audit
Run it from a terminal, not from Figma.
- Can I fetch your tokens as a file, without a Figma account?
- Can an agent list your components and their props without reading prose?
- Does a design node point at a code file?
- Is a broken rule a type error, or a comment in a pull request?
Four nos means every screen an agent writes for you is a guess. The drift that comes back is not the model being careless. You never published the contract.
Get the PDF