Every design system I've worked on has had the same problem: the Figma library says one thing and the codebase says another. Components drift. Tokens get updated in one place and not the other. Someone builds a variant in code that never makes it back to the design file. After a few months, the "source of truth" is whichever one someone checked last.
I've been thinking about what would change if we just accepted that the code is the real design system. Not the Figma file, not the documentation site. The code.
Where the drift starts
The traditional model is: design in Figma, document the spec, hand it to engineering, they build it, and the Figma file becomes the reference. This works until the first time an engineer has to make a judgment call the spec didn't cover. They adjust the padding, tweak a color, add a loading state the designer didn't think about. The code diverges from the design.
And it keeps diverging.
The response is usually "we need better handoff" or "we need to keep Figma updated." But what if the problem isn't discipline? What if it's that we're maintaining two sources of truth and expecting them to stay in sync?
Code as the living system
What if designers worked directly in the component library? Not writing CSS from scratch, but using AI-assisted tools to modify, extend, and compose components in the same environment engineers use. The component you see is the component that ships. There's no translation step. There's no drift.
This isn't hypothetical anymore. Tools are emerging that let designers work with code in ways that weren't possible a year ago. The gap between "designing a button" and "building a button" is collapsing. The question is what that means for how teams organize around a shared system.
The enterprise question
At a small company, one team owns the system and everyone's close enough to stay coordinated. At enterprise scale, you might have ten teams consuming the same component library across different products. How does a code-first design system work when the people using it are spread across organizations, time zones, and priorities?
I don't have the full answer yet. But I think it involves treating the design system repository the way open-source projects treat their codebases: contribution guidelines, pull request reviews, release notes, and a small core team that maintains quality while staying open to input from the edges.
Maybe the design system of the future looks less like a Figma library and more like a well-maintained open-source project. We're not there yet. But I think we're closer than most people realize.