A spec describes intent. A pipeline guarantees it. Here's how moving tokens into the build ended visual drift on a mature enterprise SaaS.
Most teams I've worked with have a design-token "system" that is really a token document — a Figma page, a spreadsheet, a wiki table — that describes the colors, spacing, and radii the product should use. It's accurate the day it's written. Then the product ships a few times, and the document and the code quietly diverge.
On Infor RMS, that divergence had a name in our bug tracker. Every release surfaced a handful of small visual inconsistencies: a spacing value a few pixels off, a blue that wasn't quite the brand blue, a border radius that didn't match the rest of the screen. Designers filed them. Engineers re-implemented the values by hand. The same class of bug came back the next sprint. The handoff itself was the defect.
The insight that changed our approach was simple: as long as a human re-types a value somewhere between Figma and production, drift is not a question of discipline — it's a question of time. Someone will eventually type #0073ee instead of #0072ed, and no amount of care prevents it at scale.
So we stopped treating tokens as a thing to read and started treating them as a thing to compile. Figma variables became the single source of truth. A build step exported them, transformed them, and published them as versioned CSS custom properties the application consumed directly. No one re-typed a value, because there was no longer a place to re-type it.
Visual consistency stopped being a discipline problem and became a property of the build.
The flow has four stages, and the important thing about it is that none of them involve a person copying a number:
Because tokens are versioned, a theme change is now a reviewable, revertible artifact — not a sweep of find-and-replace across the codebase. And because they're consumed as custom properties, runtime theming (light, dark, density) is a matter of swapping a token layer, not re-styling components.
The pipeline proved its worth under a real deadline. We needed a complete dark theme for RMS — a data-dense enterprise product with a deep component inventory. Historically that's a multi-quarter effort, because every hard-coded color is a landmine.
With tokens flowing from Figma, the work changed shape. I drove the dark theme end-to-end in three months, using Kiro and MCP-connected Figma variables so that every dark-mode value originated in Figma and compiled into production. There was no manual color audit at the end, because there were no hand-typed colors to audit. The theme was, in effect, a new token layer — not a re-skin.
If your tokens live only in a spec, you have documentation, not a system. The leap is to make tokens the input to a build, so that "matching the design" is something the pipeline does, not something a person remembers to do.