Notes from building an AI design collaborator · part 6
We rebuilt our Figma design system out of the code, not the other way round
· 3 min read
Every design system I've worked on has the same quiet problem. The Figma file and the actual coded components drift apart. Someone tweaks a button in code, nobody updates the Figma one, and six months later the "source of truth" is a museum piece that lies to every new designer who opens it.
I kept coming back to one thought. The code is what actually ships. So the code should be the source, and the Figma file should be built from it. Not the other way round, and definitely not by squinting at the running app and redrawing it by hand.
The pipeline
The build has three parts. A file of design tokens, the colours and spacing and radii, pulled straight from the code. A declarative spec that lists the components and their variants. And a generic builder that reads both and assembles the Figma file.
The rule I held to was real assets only. No faked icons, no "close enough" components drawn from memory. If it isn't in the code, it doesn't go in the file. That sounds obvious and it is the thing everyone skips, because drawing a plausible icon is faster than wiring up the real one. It's also how the drift starts.
Because the whole thing is generated from one source, rebuilding it is cheap. The code moves, you run the build again, the Figma file catches up. The museum problem just goes away, because nobody is maintaining a second copy by hand.
What it got right, and what it didn't
The first real build came out about eighty percent right. I want to be honest about the other twenty, because that's the interesting part.
The machine nailed the mechanical stuff. Tokens, variants, the tedious matrix of states that nobody enjoys doing by hand. Where it needed me was the judgment. Which components were actually the same thing wearing two names. How to group them so a human could find anything. The bits that aren't in the code because they live in a designer's head.
So the model I landed on isn't "the AI builds the design system." It's "the AI generates it from the source of truth, and a human reconciles the parts that need judgment." The deterministic pipeline does the heavy, boring, error-prone work perfectly. The human does the twenty percent that's actually design. Either one alone is worse than the two together.
That split, generate from the source then reconcile by hand, has turned out to be the shape of most of the useful AI work I do now. This was just the first place I saw it clearly.
Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own.
- design-systems
- figma
- ai
The rest of Notes from building an AI design collaborator
- 1. I stopped describing my product to AI. I just gave it the HTML.
- 2. I gave the AI my design process, not my design decisions
- 3. I turned my design process into a dozen small skills, not one giant prompt
- 4. I built a free tool that gives your AI your real product
- 5. I taught the AI to push designs into Figma. Then it quietly stopped.
- 7. We ran our design process on itself, and it broke in useful ways
- 8. How do you teach an AI your taste?
- 9. It worked great on the smart model. Then I ran it on a cheaper one.
- 10. The AI told me our brand colour with total confidence, and it was wrong
- 11. A screen list lies. I found a whole feature I didn't know we shipped.
- 12. Our documentation updates itself, because updating it is the AI's job
- 13. I sat down to turn my workflow into a swarm of agents. Most of it refused.
- 14. Every modal in our app shared one URL. Our analytics couldn't tell them apart.
- 15. My AI's rules only worked because one tool bothered to read them
- 16. Six designers, one GitHub account, and a script that saves us from ourselves
- 17. "Out of scope" usually means "we'll repaint this in six months"