AI coding assistants produce inconsistent UI when your design system context is missing - the model ships plausible components that ignore your design tokens, and that is the core failure mode in Figma-to-code AI workflows. The fix is one repo-native pipeline: export Figma variables as DTCG format JSON, build CSS with Style Dictionary, and point the assistant at AGENTS.md before it edits code. The W3C Design Tokens Community Group maintains the DTCG specification that makes this pipeline interoperable across tools.
Related workflows: Figma design tokens guide for primitive vs semantic architecture, Figma MCP for AI reading Figma files directly, and design system parity for syncing token exports back to the codebase.
This article stays on that single stack (tokens in the repo, not a survey of every AI design product). Tool steps cover Cursor and Claude Code as representative AI coding assistants; optional Figma file reads via MCP are noted once. Without token structure, naming rules, and component docs, output follows training-data defaults. Teams that ship the stack below commonly report tighter alignment; patterns reflect team reports, not a published benchmark. Informal “vibe coding” labels the same problem - missing context - not a separate methodology.
In short
- Problem: AI has no native view of your Figma variables unless you add files and rules to the session.
- Pipeline: Figma variables → DTCG JSON → Style Dictionary → CSS custom properties (
--ds-*) in the repo. - Context: AGENTS.md at repo root (paths, naming, no hardcoded hex) plus optional component docs.
- Assistants: Cursor and Claude Code steps below; Figma MCP is optional for layout, not a substitute for tokens.css.
- Figma hygiene: clean untokenized literals and track binding with coverage vs untokenized audits before you export tokens for agents.
Why AI tools ignore your design system
AI coding tools have no built-in link to your design system. They use training data and your prompt unless you attach token structure, component usage rules, and spacing logic. The result is UI that guesses spacing, color, and type - not your system. Model and context-window limits vary by tool; the failure modes below show up often enough that teams treat them as predictable.
Color tokens tend to survive better than spacing because hex values appear often in training corpora. Semantic aliases - background/default referencing color/neutral/gray-50 - are often collapsed to a literal hex. Responsive tokens built on Figma variable modes are frequently lost when the export pipeline flattens modes to one resolved value.
The context gap (not an AI ceiling)
Without explicit context, many teams see strong color matches on simple screens but recurring breaks on nested components, mode-based tokens, and semantic alias chains - based on team reports and community threads, not a published industry benchmark. That gap usually closes when you add a structured DTCG export and a one-page AGENTS.md the agent reads first. Hardcoded values still sitting in Figma files also leak into prompts and MCP reads; find untokenized values before you rely on AI frontend generation for production UI.
Typical token behavior in AI-generated code without explicit context (patterns from team reports)
| Token type | Typical outcome | Common failure mode |
|---|---|---|
| Brand colors | Often partially matched | Hex literals instead of var(--ds-*) references |
| Spacing scale | Often missed | Arbitrary px from training data |
| Typography tokens | Mixed | Font size/weight literals in nested text |
| Semantic aliases | Usually bypassed | Primitive hex used; semantic layer skipped |
| Mode / responsive tokens | Usually dropped | Single flattened value or ignored modes |
The token format AI coding tools actually read
DTCG JSON is the format most likely to survive from Figma export to generated code. The W3C Design Tokens Community Group maintains the DTCG specification; $type and $value fields map cleanly to Style Dictionary transforms documented in the configuration guide. Flat JSON with bare hex is ambiguous; DTCG carries type, role, and alias chains so agents can emit semantic references instead of literals.
Two-layer structure: primitives and semantics
Split DTCG into a primitive layer (raw values) and a semantic layer (roles referencing primitives). That is how agents distinguish color/brand/blue-600 from background/interactive/primary. Without semantics, generated code often inlines the hex.
{
"color": {
"brand": {
"blue-600": { "$type": "color", "$value": "#2563EB" },
"blue-700": { "$type": "color", "$value": "#1D4ED8" }
}
},
"background": {
"interactive": {
"primary": { "$type": "color", "$value": "{color.brand.blue-600}" },
"primary-hover": { "$type": "color", "$value": "{color.brand.blue-700}" }
}
},
"space": {
"4": { "$type": "dimension", "$value": "4px" },
"8": { "$type": "dimension", "$value": "8px" },
"12": { "$type": "dimension", "$value": "12px" },
"16": { "$type": "dimension", "$value": "16px" }
}
}
Exporting Figma variables for AI consumption
Figma’s native variable export is proprietary JSON, not DTCG. Use Tokens Studio or a compatible plugin to map collections to $type/$value. Export primitives, semantics, and component overrides as separate files so alias chains stay intact. Flattening to one resolved-value file removes the semantic layer agents need. After export, validate the Figma file: Coverage Audit vs untokenized scans show binding health and literal backlog before code sync. For parity from Figma to repo, keep layers intact through design system parity.
From DTCG to CSS: the Style Dictionary step
Per the Style Dictionary platforms docs, DTCG JSON becomes CSS custom properties, SCSS, or TypeScript. For AI code generation on the web, CSS variables are the most portable - models trained on front-end code recognize var(--ds-background-interactive-primary) when dist/tokens.css is in context. Run the build in CI so CSS stays aligned with Figma.
{
"source": ["tokens/**/*.json"],
"platforms": {
"css": {
"transformGroup": "css",
"prefix": "ds",
"buildPath": "dist/",
"files": [
{
"destination": "tokens.css",
"format": "css/variables"
}
]
}
}
}
AI coding assistants: Cursor and Claude Code
Cursor and Claude Code are the two assistants most teams wire to the same token repo. Both need built CSS and AGENTS.md in scope; differences are mostly how each product loads rules and context.
Cursor with a Figma design system
Cursor design system workflows work when the repo defines tokens, not the chat alone. Index the codebase per Cursor codebase indexing. Add project rules in Cursor Rules or .cursor/rules so every Agent session inherits no-hardcode constraints.
- Keep
dist/tokens.css,tokens/, anddocs/components/out of.cursorignore. - Attach
@AGENTS.md,@dist/tokens.css, and the relevant component doc. - Prompt: use only semantic
--ds-*from tokens.css; no invented hex or px. - Optional: Figma MCP for layout; CSS variables remain the source of truth for code.
Claude Code with design tokens
Follow the Claude Code overview: same AGENTS.md and dist/tokens.css, with token rules in AGENTS.md (and a one-line pointer from CLAUDE.md if you use it). Run your Style Dictionary script before long sessions.
- Open the session with: read AGENTS.md and tokens.css before any component edit.
- Visual design imports can miss alias chains - see Claude Design and design systems for limits.
- Enforce output with ESLint or Stylelint on
src/.
Writing context files AI agents actually read
AGENTS.md at the repository root is the shared context file for AI coding assistants (see the AGENTS.md convention). Keep it scannable: token paths, naming table, usage rules, links to component markdown. Agents extract facts; long prose gets skipped.
Before and after AGENTS.md (composite example)
Same prompt: “Add a primary button to the checkout card.” Without AGENTS.md or tokens.css in context, a typical agent might emit inline styles:
<button style={{ backgroundColor: "#2563EB", padding: "10px 20px", fontSize: 14 }}>
Continue
</button>
With AGENTS.md plus dist/tokens.css attached, the same tools more often emit:
<button className="btn-primary">
Continue
</button>
/* btn-primary uses semantic tokens only */
.btn-primary {
background: var(--ds-background-interactive-primary);
padding: var(--ds-space-8) var(--ds-space-16);
font-size: var(--ds-text-body-size);
}
This is a simplified before/after teams describe when onboarding designers to Cursor - not a guaranteed model behavior every run. Consistency improves further with per-component docs and lint rules.
A practical stack: AGENTS.md entry point, Style Dictionary output, and /docs/components/*.md per component. Community reports (including r/DesignSystems threads) mention non-developers opening Cursor with that setup and seeing token references in generated output without repeating token rules in every prompt.
# AGENTS.md
## Design tokens
Token CSS output: dist/tokens.css (CSS custom properties, prefix --ds-)
DTCG source: tokens/ (primitives.json, semantics.json)
Never hard-code hex values, pixel sizes, or font sizes.
Always reference the semantic layer - never primitive tokens directly.
## Token naming
background/* surface colors (backgrounds, cards, modals)
text/* foreground colors (headings, body, captions)
border/* stroke and divider colors
space/* spacing and layout (padding, gap, margin)
radius/* corner radius
duration/* animation and transition timing
## Component rules
See docs/components/ for per-component usage rules.
All components use semantic tokens only.
Responsive breakpoints: docs/breakpoints.md
What breaks token fidelity in nested components
Nested components are the most reported failure point. An agent generating a Card with a Button often rebuilds the Button instead of importing your library component - and drops established token references. Fixes that teams use reliably: component-level docs listing required tokens, and a rule forbidding reconstruction of existing library components.
Token fidelity problems, root causes, and fixes
| Problem | Root cause | Fix |
|---|---|---|
| Hard-coded hex values | No color token context provided | Add CSS custom properties to context; add no-hardcode rule to AGENTS.md |
| Arbitrary spacing px | Spacing scale missing from context | Add space token table to AGENTS.md with px equivalents listed |
| Semantic aliases bypassed | AI reads primitive layer directly | Explicitly prohibit primitive token use in AGENTS.md rules |
| Responsive tokens missing | Multi-mode variables not documented | Document each mode name, when it applies, and which tokens change |
| Token names transformed in output | Style Dictionary renames without mapping | Fix transform config; add token-name linting to CI pipeline |
| Nested component drops tokens | AI reconstructs child component from scratch | Add component-level docs listing required tokens per component |
Official documentation
- DTCG format specification (Design Tokens Community Group)
- W3C Design Tokens Community Group
- Style Dictionary - getting started, platforms
- Cursor documentation - Rules, codebase indexing
- Claude Code documentation (Anthropic)
Final verdict: design system AI workflows
Drift in AI-generated UI is usually a context problem, not a model problem. Export Figma variables as DTCG JSON, build CSS with Style Dictionary, and maintain AGENTS.md. Audit literals in Figma, then run Cursor or Claude Code with tokens in every session. That is the repeatable design system AI workflow - not a different tool for each layer.