Token Drift
Token drift is what happens when the design tokens declared in your Figma library separate from the values actually running in production code. You set up a clean scale for radius, neutral colors, and elevation in January. By April a designer tweaks three semantic tokens during a sprint because the new mockups feel tighter. The engineers never see the ticket. The Tailwind config and CSS variables stay on the old values. Six months later buttons rendered from the same component definition look different depending on who built the surrounding surface. Cards sit next to each other with mismatched shadows. The whole product loses its snap even though every individual piece still passes visual review. This is not a bug in Figma or Tailwind. It is a discipline failure where two sources of truth were allowed to exist without a single owner forcing them to match.
Token drift is not healthy iteration or the natural tension between design and engineering. It is not the same as intentionally evolving your brand palette after research or updating primitives when Radix ships a new version. It is not what happens when you skip tokens entirely and hardcode values in a one-off landing page. Those are separate choices. Token drift specifically describes the unmanaged gap that opens when you have token layers, primitive, semantic, and component, but no ruthless process to keep every layer synchronized across tools. It is not a framework problem. It is a maintenance problem that the article warned about when it said the tokens drift from the codebase.
Look at the 2024 analytics startup that raised a Series A and doubled their team in nine months. They began with a tight token foundation: 28 primitive values, 19 semantic aliases, and four component tokens for their data tables. Everything lived in a tokens.json file that fed both Figma variables and their Tailwind config. For the first two quarters it held. Then the new brand refresh hit. Design updated 11 tokens including a new radius scale that moved from 6px to 10px and a completely revised dark mode neutral set. The PR to sync the code side got deprioritized behind a compliance deadline. Three engineers kept shipping new flows using the old autocomplete values. The resulting dashboard had surfaces that looked almost right but not quite. Their NPS visual-polish score dropped 14 points in one cycle. Fixing it required a dedicated two-week audit that pulled three seniors off the roadmap. They later admitted the entire mess traced back to the exact failure mode the You Do not Need a Design System piece described: maintenance hours compounding while payoff stayed linear.
Linear offers the control case. Their token file contains fewer than 40 values total. That file is the single source of truth and compiles directly into both their design library and the frontend. When they adjusted their elevation scale in 2025 the change propagated everywhere in one commit. No drift, no audit, no Slack arguments. Vercel runs the same system with an even heavier Tailwind config treated as gospel. Resend and Loops layer house tokens on top of vendored Shadcn primitives and keep the list so small that any mismatch becomes obvious on first review. Notion maintains an extremely tight vocabulary where token changes are events, not background noise. These teams win because they engineered token discipline into their minimum viable visual system instead of bolting on process theater after the fact.
Fight token drift once your team exceeds six people touching UI or your product spans more than two surfaces. Appoint one owner, keep the token layers small, reconcile values in the same room every month, and make the tokens.json file generate both Figma and code. Use AI tools against your own tokens by feeding the current values in the system prompt so generated output does not fight your system. Stop fighting token drift when you are a three-person team validating an idea. Hardcode the values, ship the mockups, let taste rule. Building elaborate sync platforms or governance docs before you hit that size is exactly the LARP-ing maturity the parent article called out. The maintenance tax arrives before the payoff ever shows up.
AI generation made token drift more expensive. Tools like v0, Cursor, and Claude default to Shadcn-shaped output trained on public Tailwind patterns. When your tokens have drifted from those conventions every generated component needs manual fixes for radius, shadow, and color. The 20-minute component becomes a 90-minute refactor. Teams with tight token discipline get the speed. Teams without it watch AI become another source of inconsistency.
The article nailed it. Most teams do not need a design system. They need token discipline, a short primitive layer, vendored primitives, and a designer with taste who says no. Without the discipline the rest collapses.
Token drift turns sharp products dull the moment teams treat tokens as decoration instead of infrastructure that demands weekly care.
Read the full guide
Related terms
Keep exploring
Design Tokens
The atomic design values (colors, spacing, typography, shadows, motion) stored as platform-agnostic variables that every component in a design system references.
Semantic Tokens
Design tokens that assign meaning to raw values. Instead of referencing color-blue-500 directly, components reference color-primary, which resolves to the appropriate raw value.
Token Discipline
Token discipline is the rule that every visible value in a design file, color, spacing, type, radius, shadow, motion, must resolve to a semantic token from a single source of truth.
Token Layers
Token layers are the three-level hierarchy that separates raw global values from semantic meanings and component-specific bindings so you can change one thing and update thousands without hunting down stray hex codes.