4 min read:
A design system exists twice at once. It is in Figma as components, and it is in code as the real thing engineers ship. Those two are supposed to be the same. They never quite stay that way.
You change a button in one place, someone forgets the other, and a few weeks later a designer builds a screen with the old one while an engineer builds it with the new one. Then the review turns into an argument about which file is right. You have been in that meeting, so have I.
Coming up
Design Figma Files That Scale with AI FREE
Online, 10 September 2026, 30 min 路 Sign up now
Figma MCP Masterclass, with SmashingConf
Online, 14 September 2026, 4 hours live plus Q&A 路 Sign up now
From Team to System: Figma and AI Workflows FREE
Online, 17 September 2026, 30 min 路 Sign up now
Design with Figma, Claude and MCP: An Honest Introduction FREE
Online, 29 September 2026, 30 min 路 Sign up now
Build Scalable UI in Figma, Designers Ready for Agentic AI
Online, 4-week hybrid course, starts 2 October 2026 路 Sign up now
See all: Video courses 路 Live workshops 路 Team training
Why picking a winner does not work
Most teams try to fix drift by crowning one side. Either code is the real system and Figma has to chase it, or Figma is the real system and code has to chase it.
It does not matter which you pick. Whichever you crown, the other becomes a copy that somebody has to keep updating. That is not a discipline problem you can train away. It is what happens when the same thing has to be maintained in two places by two different people.
The idea: a third file in the middle
Instead of treating Figma or code as the real one, you put a small file between them. One per component, called a contract.
It is a plain description. What options it has, like a button being primary or secondary. What tokens it uses. What is allowed inside it. What it does when you click it. No pictures, no code, only the agreement about what the component is.
Then the clever part. Both the Figma version and the code version get built from that one file. On the code side the files are written straight out. On the Figma side the contract becomes instructions that a plugin runs inside your file. Neither is the original. They are both printouts of the same recipe. And there is a checker you can run that compares all three and tells you exactly where they stopped matching. Even if you are a designer, have a look, this is not crazy and you can see where it mentions Figma and maps it:
The one rule that makes it work
Figma and code are never allowed to update each other directly.
If a designer changes a colour or an engineer adds an option, that change goes into the contract first, gets reviewed like any other edit, and then both sides rebuild from it. One source in the middle, everybody else follows. It is the same discipline Git already uses for code and design tokens already use for values. What is new is applying it to whole components, which is a place we have never had it before.
Why this matters now
For years drift was annoying but survivable. You fixed it with process and a patient person keeping the library tidy. Now AI builds screens, and an unsupervised copy drifts faster than a human ever could.
In Southleft's (a design system agency) own test, an AI left to itself scored 69 out of 100. It invented options that did not exist, hard-coded colours instead of using tokens, and restyled components to taste. Work that looked fine and quietly broke the system in ninety places. The same AI, handed the contract as a rulebook, scored 100. And when it hit something the system could not do yet, it said so instead of faking it.
I did not run those tests and I do not work on the dev side of this. I am reading their receipts like you are. It is also early, one repository, one schema, and adopting it on a hand-built library is a real migration rather than a switch. The idea is the thing to take away today, not the tooling.
Where this comes from
None of this is mine. The model, the proof of concept and the 69 versus 100 numbers come from Southleft, founded by TJ Pitre (who now works at Figma, good sign!). The idea of a component spec in the middle is older, and Nathan Curtis, a big name in the design system circles, has been making that case for the past months.
There is a browser playground where you can edit a contract and watch both sides rebuild from it, break a rule on purpose and watch it get refused.
I wrote an in-depth article about this where you can find all files and references.
Join the Free September Sessions
Actionable Figma and AI training for designers - individuals and teams.
Most designs break between idea and build. I teach the thinking, the tools, and the technicalities beneath the surface, plus which AI workflows earn their place. Check out my video courses, tailored team trainings and workshops on moonlearning.io
Video courses 路 Live workshops 路 Team training
The Solo, my book 路 LinkedIn 路 Past issues
You are getting this because you signed up at moonlearning.io.
Responses