cd ../process
devon@portfolio ~/process/figma-mcp-design
[completed · Apr 2026]
cat README.md

# AI + Figma MCP Design

// Figma MCP write-to-canvas is in beta. I tested it to answer one question: can AI build a design system in Figma? The output looks locally correct. But locally correct and globally coherent are different things.

# conditions

$ No design specs

$ No tokens file

$ No .md context

$ Just a prompt and an empty Figma file

cat steps.json
[01]

The Promise

The expectation: start with an empty Figma file and let AI generate tokens, build components, create a design system. Figma MCP write-to-canvas makes this feel close — frames, auto-layout, variants, variable binding all work.

This is what demos show. And it works — for a single generation pass.

Empty Figma FileLLM Agentwrites via MCPTokens + Components+ patternsComplete DSproduction-ready?Ready to ship?Demos sell this. It works — once.
[02]

The Reality

AI nails the first pass. Auto-layout, tokens, repeated blocks — all correct. The output looks polished: colors match, spacing feels right, every screen renders.

Then you run the same prompt again, and the token names drift. You reuse the component in a narrower container, and auto-layout breaks. The button renders, but hover, focus, disabled states don't exist.

Each run is correct. No run remembers the last.

What you have looks like a design system. It is not one.

GenerationOutputEmpty Figma FileLLM Agentwrites via MCPUI ScreensgeneratedLoose Componentsno systemInconsistent Tokensnaming driftLocally correctGlobally incoherent
[03]

Where it breaks

1. Meaning — Generating #0F62FE and calling it blue-500 is easy. Deciding whether it means primary, accent, or brand is the real work. I tested this: AI named the same blue "primary" in one screen and "accent" in another, within the same file.

2. Continuity — Run 1: --ds-primary. Run 2: --color-primary. Run 3: --main-blue. Three passes, three naming conventions. Each valid in isolation. Together, incoherent.

3. System design — The generated button rendered fine. No hover state. No disabled state. No size variants. A button is not a rectangle with a label — it's every state, variant, and constraint behind it. AI drew the rectangle.

4. Reusability — Spacing was hardcoded (24px) instead of tokenized (--ds-space-6). Auto-layout broke when the component landed in a narrower container. Looks right once, breaks on reuse.

GapFirst passBreaks on reuseMeaningGenerate #0F62FE→ blue-500Decide meaningprimary vs accent vs brandContinuityOne-time correctsingle passConsistent naming--ds-primary → --main-blueSystem designDraw a buttonvisual outputDesign button systemvariants, states, APIReusabilityVisually correctpixels matchStructurally reusableauto-layout, tokens, nesting
[04]

The Right Model — designer defines, LLM accelerates

A design system is a system of decisions — naming, semantics, hierarchy, constraints, consistency over time.

The working model: a human defines the system — tokens, naming, component architecture, constraints. Then AI executes. Scaffolding screens, expanding variants, applying tokens at scale. Those definitions become .md specs — the persistent context AI reads before generating anything. This site was built that way. The system came first.

The tools are already getting better. Figma MCP now has a Skills system — reusable instruction sets that encode your naming conventions, so the agent searches your library before inventing new tokens. Make Kits let DS teams package their tokens, code, and guidelines into a kit that AI generates within. These address the drift problem directly. But they work by giving AI a system to follow — not by letting AI invent one.

A design system is proven through reuse — the second pass, the tenth, the one that breaks.

DesignerLLM + MCPDefine Tokensnaming + semanticsDesign Architecturevariants + statesSet Constraintsrules + boundariesGenerate UIfrom definitionsScale Componentsacross screensAutomate Productionrepetitive workConsistent UIsystem-backedSystem first. Generation second.