- Design tokens are named decisions: colours, spacing, typography, which you record once and use everywhere.
- When AI gets tokens and a component library, it generates an interface consistent with your style instead of a random one.
- The Design Tokens standard (DTCG) has a stable 2025.10 version, which eases exchange between tools.
When you ask AI for an interface, without extra constraints you get something that looks good, but each following screen is slightly different: another shade of blue, other spacing, another corner radius. Everyone who tried to build a consistent site from a series of independent prompts knows this phenomenon. The remedy is the same as design teams have used for years: design tokens and a component library. They give AI a shared language in which it makes its decisions.
What design tokens are
A design token is a named decision about appearance: an accent colour, a background colour, a spacing scale, font sizes, a corner radius, a shadow. Instead of typing a hex value in fifty places, you record it once under a name and use the name everywhere. Changing a theme is then changing one value. Tailwind’s documentation puts it this way: different projects need different typography, colours, shadows or breakpoints, and these low-level decisions are called design tokens. In Tailwind you store them in theme variables, defined with the @theme directive; they influence which utility classes exist in the project, and ordinary CSS variables are also generated that you can refer to.
The formal standard for exchanging tokens is handled by the Design Tokens Community Group. On the group’s site the first stable version of the specification, 2025.10, is announced, together with a JSON format meant to provide interoperability and theming between tools. The list of participants includes Figma, Penpot, Sketch and Style Dictionary, among others. For you the conclusion is practical: tokens stored in an open format can be moved between a design tool and code.
A component library as the second constraint
Tokens define values, but not recurring elements such as a button, a form field or a card. A component library helps here. shadcn/ui describes itself as a set of beautifully designed, accessible components and a code distribution platform. Components land in your project as code you can modify, and the documentation also mentions integration with AI tools: there is an MCP server, component registries and the ability to open a component in v0. When you tell an agent to use components from the library and tokens from the theme, its freedom drops and consistency rises.
| What you record | Effect for AI | |
|---|---|---|
| Colour tokens | Named brand and state colours | No invented shades |
| Spacing and typography scale | A few sizes instead of arbitrary ones | A consistent layout rhythm |
| Components | Button, field, card in one style | Repeatable interface elements |
| Rules in the instruction file | Rules for using tokens and components | Compliance with the system on every screen |
How to pass the system to AI
The most effective way is to record the system in project files. Keep tokens in a single theme file. Components in one directory. In the agent’s instruction file, such as CLAUDE.md, add a few sentences: use only tokens from the theme, do not type colour values in code, build screens from library components, and add a new component only when none fits. I describe the details of such a file in the article on Claude Code configuration. Describe accessibility rules as well, for example minimum contrast, because otherwise the agent will optimise looks at the expense of legibility.
- 01DecisionsColours, spacing, typography, radii.
- 02TokensNamed variables in one theme file.
- 03ComponentsA library or your own set.
- 04InstructionRules of use written for the agent.
- 05GenerationScreens from tokens and components.
- 06ReviewCompliance, contrast, consistency.
When you do not have a system yet
You do not need to start with a full system. A small version is enough: five colours, three spacing sizes, two text sizes, one font family and three components. Record them as CSS variables, ask AI to build a page solely from them and judge the result. Such a small system grows with the project. The most common mistakes are three things. Too many tokens at the start, half of which nobody uses. Names that describe the value rather than the role, for example “blue-500” instead of “accent”, which makes later theme changes harder. No rules of use, so the agent hard-codes colours anyway. It is good to name tokens by role, keep few of them and now and then search the code for values that should be tokens.
An example of work from a mockup to a working component is in the article From a mockup to a component, and the whole topic is in the Design → code hub.
Last checked: 20 October 2026. Standards and libraries change quickly; check the documentation before use.