Key takeaway: In the AI era, a design system must be machine-readable first — token names, prop tables, and semantic structure matter more than Figma polish because the thing implementing your components is an LLM, not a developer reading your file.
Three years ago, a design system was for designers. Maybe for developers if you were lucky. Now it has to be machine-readable first, because the thing implementing your components is not reading your Figma file. It is reading your token names and your prop tables.
We rebuilt our internal design system — Nova — around this idea in 2025. Everything we ship runs on it. Here is what changed and why it matters.
The old design system was a visual artifact
The average agency design system in 2022 was a Figma file, some hex codes in a PDF, a Notion page with typography examples, and a Slack channel where developers asked which grey to use. It worked because a human developer translated it, and humans are good at translation.
The costs were invisible. Every project had a 2–3 week handoff delay while developers figured out how to map "Heading / XL / Tight" to real CSS. Every studio had its own minor variations of the same system, because the source of truth was a file that got copied and drifted. And when the client's in-house team extended the system later, they extended it in their own direction, because the documentation was too loose to force alignment.
A design system whose primary consumer is a human is unavoidably fuzzy. You can get away with fuzzy when the humans are senior and work together every day. You cannot get away with fuzzy when the implementer is an AI, because it will produce plausible-looking output that is subtly wrong — and it will do it fast.
The new design system is a contract
A design system for the AI era has three properties a human-first system does not need. Explicit naming. Prop tables. Executable examples.
Explicit naming. Token names have to carry their meaning. The token for your primary brand color at 600-level weight is color-brand-primary-600. Not purple. Not purple-ish. Not brand-main. The name tells you the role (brand-primary), the scale position (600), and the category (color). Every part is a stable vocabulary word.
This discipline sounds pedantic. It is the difference between a Claude Code prompt that outputs correct CSS and one that hallucinates a close-enough color because the prompt said "use the brand purple" and there are four "purples" in your file.
Prop tables. Every component gets a prop table in its documentation. Type, default, required, allowed values, what it does. Not a screenshot of the Figma component. A table. If the variant size accepts sm | md | lg, write that exact union. If a button supports icon-left | icon-right | icon-only, list them. The component doc is a contract the AI implementer will uphold if you give it one.
Executable examples. A short snippet of working code for every component, not just a visual. Humans can eyeball a Figma frame and guess the implementation. AI cannot, or will not reliably. Give it a working example and it will pattern-match correctly.
The worked example: Nova inside AI Business Analyst
Our AI Business Analyst product is a demonstration of the design system as machine-readable contract. The report component is not one giant React file. It is a set of bound components — report-summary.jsx, report-competitors.jsx, report-digital.jsx, report-checklist.jsx — each reading from the typed Report JSON and rendering with Nova DS tokens.
The stylesheet structure is the same discipline. colors_and_type.css holds the tokens for light and dark mode. app.css holds layout and component rules built on those tokens. extras.css holds the new component styles introduced for this product. Every rule uses tokens. Nothing uses raw hex values. Nothing uses made-up variable names.
The sun/moon theme toggle is the cleanest proof the system works. Flip the theme and every component — from the intake form to the 50-item ICE-scored checklist — adjusts. No per-component overrides. No "oh wait, the threat bar looks wrong in dark mode." The design system survives the theme swap because the tokens are doing the work, not the components.
This is only possible because the tokens are named by role, not by value. color-surface-default means "the default surface in the current theme." In light mode, that resolves to a near-white. In dark mode, a near-black. The component never asks which mode it is in. It asks for the role it needs, and the system provides it.
Rebuilding your design system this year?
We'll make it machine-readable the first time, so your AI implementer gets it right without a human translator.
Concrete dos and don'ts
Prose is better for narrative, but this part genuinely is list-shaped.
Do:
- Name tokens by semantic role, then scale.
color-brand-primary-600, notpurple-dark. - Document components with prop tables, not screenshots.
- Include executable snippets in every component doc.
- Namespace everything.
space-4,radius-md,shadow-raised. A single flat vocabulary becomes a contract. - Define empty states, loading states, and error states explicitly. AI will not invent them correctly.
- Version the system. If you change a token's meaning, bump the version.
Do not:
- Use color names for tokens. The moment you rename "purple" to "blue" in a rebrand, every reference is lying.
- Hand off a Figma file as the source of truth. Figma is a rendering of the system, not the system itself.
- Let developers ask in Slack "which grey." If they had to ask, the system failed.
- Rely on designer commentary in the Figma file. AI cannot read the gray sticky notes next to the component.
- Mix semantic and literal tokens. Either you have
color-brand-primary-600, or you havecolor-purple-600. Not both for the same thing.
Component documentation that works
Here is the structure we use for every Nova component.
- One-line description. What it is, in ten words or fewer.
- Prop table. Name, type, default, required, allowed values, description.
- Variants and states. Listed explicitly. Not "and other variants." Every one.
- Code example. Minimum working markup and bindings.
- Accessibility notes. Required aria attributes, keyboard behavior, focus rules.
- Do and do not. Two or three of each, specific.
- Related components. Links, not prose.
This looks like overhead until the first time you hand it to Claude Code with a "render me a new dashboard page using the standard components" prompt and it outputs something you can ship with a single round of review. That moment pays for the documentation forever.
Handoff files that survive the AI round-trip
When we hand a design system or a project handoff to a client's internal team, we hand over three things. The Figma file, yes. The token JSON, for programmatic consumption. And a plain-text documentation export — Markdown, structured, no images — that an AI can read verbatim.
The third one is the new requirement. Any client team using Claude, Cursor, or any AI coding assistant is going to feed the docs into context. If your documentation is locked inside Figma comments and Slack threads, their AI will not see it and will invent its own interpretation.
What this means for you
If your design system is a Figma file, it is a 2022 design system. If your tokens are named after colors, it is a 2023 design system. A 2026 design system is a machine-readable contract with semantic token names, prop tables, and executable examples — and it pays for itself the first time an AI implementer uses it correctly.
If you are extending or rebuilding an internal design system and want it done right, drop us a line: hello@cinnaboner.com.
Your design system should survive an AI round-trip.
If it doesn't, we'll rebuild it so it does. Clean tokens, prop tables, executable examples.
