Here's the failure mode nobody talks about until they're already in it: you start with a clean three-tier token architecture — reference, semantic, component — and six months later you have forty-seven semantic tokens, a Figma file that takes thirty seconds to load, and a designer who spent an entire afternoon cross-checking contrast ratios for a brand theme that ships to zero users.
The variant explosion problem in design systems is usually framed as a component problem. Too many button variants, too many card states, too many prop combinations. But the combinatorial blowup usually starts one layer below — in the token system — and by the time it surfaces in components, the debt is already compounding.
The Semantic Layer Is Where Complexity Hides
The three-tier model — reference tokens hold raw values, semantic tokens carry meaning, component tokens scope decisions to specific UI — is sound architecture. Masterly's 2026 token guide makes a useful point: most products before Series C only need the first two tiers. The component token layer is where teams tend to over-invest early, creating scoped tokens for decisions that aren't actually stable enough to deserve their own named slot in the system.
The problem compounds when you add theming ambitions before you have themes. DEV Community's recent piece on multi-brand systems describes exactly this trap: a designer spending a full week mapping primitive colors to semantic tokens for brands that don't exist yet, producing a token matrix so large that every new semantic color requires defining its value across all hypothetical brand contexts. The cognitive load lands on every developer who has to know which token to use for a border color because border-subtle changes meaning depending on the active brand.
That's the combinatorial explosion in practice. It's not that any individual token is wrong. It's that the relationships between tokens multiply faster than anyone can track, and the system becomes harder to reason about than the raw values it was supposed to replace.
AI Generation Makes This Worse, Faster
The same dynamic is now accelerating through a new vector. Codexical's July analysis documents a fintech team where a designer generated fourteen button variants in an afternoon using Figma's AI tooling. Each one was locally correct — right padding, right corner radius, right hover state. Three months later, an audit found eleven different values for "primary button padding" in production, none of them documented, none traceable to a deliberate decision.
The AI hadn't broken the design system. It had just answered fourteen slightly different questions, fourteen times, without checking whether the answers agreed with each other. The variant explosion was statistical and distributed — invisible at generation time, expensive at audit time.
This is the new shape of the problem. Traditional variant proliferation happened because humans made visible choices to deviate. AI-assisted generation produces deviation at volume, with no visible seam. As Codexical notes, a senior designer reviewing one AI-generated screen catches an off-brand spacing value in thirty seconds. The same designer reviewing forty screens a week doesn't have forty times the attention.
The Fix Is Governance, Not More Tokens
The instinct when a token system gets unwieldy is to add more structure — more naming conventions, more tiers, more component-scoped tokens to prevent misuse. This is usually wrong. GitLab's Pajamas design system authoring guide takes a more disciplined position: before creating a new token, verify it will be used across multiple components or contexts, and confirm the value represents an actual design system decision. The bar for adding a token is evidence of reuse, not anticipation of it.
The same principle applies to variant generation. Luis Ouriach's recent piece on design system architecture draws a useful line between value-level experiments — a badge with slightly different padding — and structural experiments that actually warrant a new component. Most variant proliferation happens because teams reach for a new component when a token override would do, or reach for a new token when a raw value would do.
The governance piece is unglamorous but load-bearing. Atomize's Figma best practices guide is direct about it: libraries without a named owner accumulate dead components in a predictable pattern — things get added, nothing gets removed, naming conventions diverge because different contributors apply different rules. A token system without someone authorized to say "we don't need this" will grow until it collapses under its own cross-references.
The Practical Heuristic
Start with fewer semantic tokens than you think you need. Masterly's guide suggests 30–50 tokens covering color, space, type, and radius as a starting vocabulary — a 400-token system nobody adopts fails the same way a 300-component library does. When a new token is proposed, the question isn't "could this be useful?" It's "do we have two or more existing callsites that need this exact decision named?"
Variant explosion is a symptom of a system that's been optimized for anticipated futures rather than actual present use. The token combinations that outpace maintainability are almost always the ones that were added speculatively — for brands that don't exist, experiments that never shipped, or AI-generated components that passed review because each one looked fine in isolation.
The system that ships fast is the one that stays small enough to reason about.
