Design system is born in code, not in Figma: Christine Vallaure's MCP workflow

For years, the path was always the same: the designer would draw in Figma, a developer would translate that into code, and the details that didn't survive the trip were resolved in a hallway conversation. It was when designer Christine Vallaure handed that same task to an AI that she noticed the problem: the result looked correct, because the AI read the Figma file faithfully and filled in everything the file didn't say with whatever seemed most plausible.

In an article published on UX Collective, Vallaure describes the decision she made after that: reversing the direction of the workflow. Her design system is now born in code, and the Figma library is generated from it, not the other way around. Code always wins; Figma is a mirror, not a second source of truth.

Why Figma-to-code breaks with AI

The problem, according to her, isn't a lack of polish in the tool: it's that the Figma file was never meant to be a complete instruction set. Vallaure compared what a React component can express with what a Figma component can express and arrived at a coverage of around 17%; for CSS, the number rises to close to 45%, still far from the total. These are her own numbers, from an informal comparison and not an official statistic, as the author herself is careful to point out.

Keyboard focus order, error states, what a screen reader announces, what happens when a list comes back empty: none of that shows up in a screenshot, and that's why no one catches it in review when it's the AI, not a developer, filling in those gaps alone.

Everything Figma cannot say used to be filled in by a developer who could walk over and ask a question.

Christine Vallaure, designer and author at UX Collective

The same literalness that's a problem in one direction becomes an advantage in the other: generating from code, the AI reads exactly what exists, and what exists are real props, real values, real states.

What MCP is and how the library is built

MCP stands for Model Context Protocol, the standard that lets an AI read and write directly to variables and components in a Figma file, instead of just suggesting text in a conversation. Vallaure specifically uses Figma Console MCP, from Southleft, because it handles variables well, something the basic Figma connection doesn't do properly.

The workflow she demonstrates starts far from Figma: access to a code repository with Storybook running (the local showcase, at something like localhost:6001, that shows each component live and clickable from the real code). Then comes an empty Figma file, connected to Console MCP, with Claude Code bridging the two sides.

The order matters: tokens and text styles first, because components depend on them. Tokens are the atomic values of color, spacing, radius, and typography that feed the whole system; in her case, they become collections of variables and text styles in Figma, using exactly the same names as the code. Only after that does she test with two components, one simple and one more complicated (Button and Alert, in her example), before running the entire library.

The success criterion isn't visual. It's whether both sides use the same property names, letter for letter: no danger on one side and error on the other, no component that's secretly another one under a different name. It's this naming alignment that supports everything that comes after, including AI prototyping on top of the real system.

GAPS.md: the file that's worth more than the components

At every round, Vallaure asks the agent for a specific file: GAPS.md, listing everything that couldn't be expressed in Figma, everything that remained uncertain, and everything that needs manual review. According to her, this document ended up being more useful than the generated components themselves.

Her file accumulates things like line heights that are unitless in code and need to become pixels in Figma, states that only exist in behavior (not in appearance), and layout rules for which Figma simply has no equivalent. Each item comes with a note on how she decided to resolve it.

After repeating this process a few times, she noticed she was typing the same corrections every time, and turned that into a skill: a packaged set of instructions that the agent automatically loads for this type of task, including comparing screenshots of generated components against the Storybook stories. She makes an explicit security warning: a skill runs code on the machine of whoever installs it, so it's only worth installing one from someone you trust, or having a developer review it first.

Maintaining parity is the real work

Generating the library once is the easy part. Keeping it faithful while the code changes every week is the open problem, both in her setup and in the industry in general, in the author's own words.

The solution she built is simple and deterministic:

• Storybook, starting with version 10, can automatically generate a manifest.json with every component, its properties, allowed values, and defaults, straight from the code.
• With MCP open, she asks Claude to write an equivalent list of what actually exists in the Figma library.
• The two JSON lists are compared name by name, property by property, default by default: what matches turns green, what changed turns red.

She publishes this result as a status page inside Storybook itself. The comparison itself doesn't use any AI: same input, same output, always. AI only comes in to trigger the process, and that's still manual in her setup, something she acknowledges as a limitation. Important: for now, the check only covers architecture (names, properties, values, defaults), not the visual side in CSS.

Updating a library that already exists

Many teams won't start from scratch: they already have a Figma library with years of work in it. Vallaure shows that the same connection can be used to compare instead of create, by asking the agent to check a specific component against its code version and propose a report, a side-by-side reference version, or a direct fix.

Three precautions she highlights for anyone trying this on a real system:

1. Work on a copy. Never let an agent loose on a live library that other files depend on.
2. Deleted variants don't come back. Each variant has an internal key; deleting and recreating it with the same name doesn't reconnect the instances that already use that component in other files. The way to go is to rename and fix, never delete and recreate.
3. It still needs babysitting. In a real system, with real history, this is assisted work, not magic: the AI is fast and doesn't get tired, but it doesn't know which differences really matter.

What's left for those who lead a design system

The real gain of the method, by Vallaure's account, isn't visual: it's that both sides start speaking the same language of names and properties, which becomes a prerequisite for prototyping with AI on top of real components, without inventing a parallel interface. But the upfront cost is high (generating the entire library costs time and tokens), and the work of maintaining parity afterward, according to the author herself, still isn't automatic in almost any team, including her own.

The question that remains for anyone who maintains a design system: if an AI had to fill in, on its own, everything your Figma doesn't say about focus, error states, and accessibility behavior, what would it invent in its place? That's the kind of gap that only shows up when someone, as Vallaure did, explicitly asks for the list of what got left out.