Your Design System Should Not Live in Figma. Or in Code.

You know the argument. A button changed in Figma but not in code. Two people build the same screen two ways, and the review turns into a fight about which file is right. You have been in that meeting. So have I.

Here is where we are. Teams are trying a different answer: put the truth in neither place. A small file sits in the middle, and both Figma and code get built from it. AI is what made this urgent. Let me catch you up.

The winner you crown becomes the copy nobody updates

Most teams fix drift by picking a winner. Either code is the real system and Figma chases it, or Figma is the real system and code chases it. Christine Vallaure lays this out plainly: it does not matter which one you crown. The other becomes a copy someone has to keep updating by hand.

That is not a discipline problem you can train away. It is what happens when the same thing lives in two places, maintained by two different people. You can hire a patient person to keep the library tidy. The drift still wins over time.

The file in the middle both sides copy from

The fix is a third thing. For each component, a small JSON or YAML file describes what it is. What options it has, like primary or secondary. Which tokens and colors it uses. What is allowed inside it. No pictures, no code. Just the agreement.

Then it flips. Figma and code both get built from that one file. In Figma the file becomes instructions a plugin runs to make the variants. In code it becomes typed options. Neither is the original. They are both printouts of the same recipe. Southleft, the consultancy behind the design system contract playground, built a checker that compares all three and tells you the exact spot they stopped agreeing.

Why a labeled file and not a markdown doc? A paragraph has to be understood, and understanding varies. A contract only has to match, and matching is the same answer every time. That is the whole trick.

AI turned a slow leak into a flood

For years drift was annoying but survivable. Now AI builds screens, and an unsupervised copy drifts faster than any human could. In Southleft's own A/B test, an AI left alone scored 69 out of 100. It invented options that did not exist. It hard-coded colors instead of using tokens. It made work that looked fine and broke the system in ninety places.

The same AI, handed the contract as a strict rulebook, scored 100 out of 100. And when it hit something the system could not do yet, it said so instead of faking it. That gap became a proposed change, the change got reviewed, and the system grew by one honest step.

The process is bending the same way

This is not just a components story. The whole handoff is getting spec-driven. Darren Yeo's SAID framework makes the same bet at the process level: a spec becomes the source of truth, and agents build from it. He points to Anthropic's design lead Jenny Wen and her claim that "the design process is dead," then sharpens it into something you can use.

The skill shift for your designers is real. Yeo puts it bluntly: "If a design idea cannot be translated into behavior, constraints, and testable rules, it is still too vague to scale." Not markdown engineers. People who can write down intent so it survives contact with code. Same idea as the contract, just one layer up.

The deep cut

Before you buy this for your team, size it right. Vallaure is honest about the edge: a contract fixes what a component is made of and which token sits where. It does not decide how the code is written, and a lot of craft lives in that layer. Drag, focus-trapping, motion, good CSS, all still hand-written.

And it is not for everyone. A team of three does not need it. You are Figma and code at once, so there is nothing to drift apart. Enterprise fits, and they will get it first because they can afford the third artifact. This is a migration, not a switch. Governance does not vanish, it moves into a review. If you are the person who keeps the library tidy today, you are the person in that review tomorrow. That is where your Monday work actually goes.

Three questions for your team

1. When AI generates a screen from our system today, who checks that it used real tokens and did not invent options? If the answer is "nobody, or we eyeball it," that is your 69 out of 100 waiting to happen.
2. Which of our components are stable enough to write down as a contract, and which are still moving too fast to freeze? Start with the ten you argue about most.
3. Can our designers write intent as testable rules, or do they still hand off pixels and hope? If it is the second one, that is a training decision to make this quarter, not next year.