I heard a designer say something the other day:

"Developers don't really care about hardcoded values. If the component looks like the design, nobody's going to stress about whether the tokens are wired up correctly. It's never perfect anyway."

It's easy to see why this belief is so common. It can feel comfortable, because it means we don't have to think too much about the details. And there is a grain of truth in it. But the part that doesn't hold up is the one that quietly grows over time.

Each hardcoded value is a small debt we add to the system. When we build interfaces by hand, this debt grows slowly, one component at a time. With AI, the same issues appear, but much faster—mistakes multiply before anyone can catch them. This is what I mean when I talk about visual debt at machine speed. And it quietly undermines AI-generated UI consistency before anyone notices.

Looking right is not the same as being consistent

Here's the challenge with the 'it looks like the design' approach: a hardcoded value will always pass that test.

Even if you export a well-structured, token-mapped component from Figma and let AI build it, you might still find hardcoded values hidden in the output. This is a real issue that deserves our attention. These values don't announce themselves—the component looks correct, matches the mockup, and the pull request gets approved.

This is where AI-generated UI consistency quietly breaks down. AI gives us output that looks finished, but visual fidelity and true system consistency are not the same. In fact, AI can make the gap between them wider and harder to spot. Sometimes, it feels like we're shipping an interactive screenshot, not a real component—and we're doing it faster than ever.

The honest case for skipping tokens

Before we look at why token discipline matters, let's give the 'maybe we don't need this' perspective a fair chance. It's important to consider both sides.

Major color redesigns are rare. Many teams never go beyond a dark theme, and some never even ship that. If you're working on a small project with no plans to scale, and no new team members expected to join, strict token discipline can feel like extra work for a problem that doesn't exist.

This isn't about being lazy—it's a real cost-benefit decision. For some projects, that calculation makes sense.

Tokens are how the artifact layer stays coherent. But artifacts are only half the picture — the pattern layer is what AI tools can't extract, and it's the one most teams have never written down.

Where that argument breaks

But this approach starts to break down as soon as you need to scale—and today, that happens faster than before.

A design system is not just about making today's screen look correct. It's there to help you scale: to support fast changes, client-specific customization, and to help new team members get up to speed quickly because the rules are already set. As soon as these needs appear, skipping token discipline is no longer practical—it simply passes the work (and the growing debt) to whoever comes next.

The difference now is the speed. When AI generates UI, untokenized decisions pile up much faster than before. One loose pattern can turn into forty instances before anyone has a chance to review. This is the shift to machine speed—the debt was always there, but now it grows much more quickly.

Optimizing your system for AI means making sure tokens are used correctly and that adaptations really work. This is how you maintain the system over time. If we treat this as optional, we're simply ignoring the cost that will come due later.

The fix: AI-generated UI consistency comes from less

When AI output starts to drift, our first instinct is often to add more: more tokens, more coverage, stricter prompts, longer instructions. But real consistency comes from the opposite direction. The more compact and structured your system, the more reliable the results. The goal is a system small enough that both a person and a model can understand it. The real work is in reducing, not adding. Here are three ways to make your system smaller without losing strength.

1. The third tier belongs in code, not Figma

I don't recommend keeping a three-tier token system as components inside Figma. This approach makes design work more difficult. If you keep both the semantic and component layers visible, you end up with too many tokens to manage. If you hide one layer, the system becomes hard to understand and operate. Neither option is ideal.

But the third tier can live in code, and there it earns its place:

  • It references the semantic layer without cluttering the Figma UI.
  • It's co-located with the component, so you can reason about one component at a time.
  • It can be derived or computed rather than hand-maintained.
  • Designers stay on the semantic layer; developers get the granularity they actually need.
  • It refactors without breaking Figma libraries.
  • It can be generated and validated programmatically — which is exactly what you want when AI is in the loop.

The architecture stays the same, but the home for this layer is better suited to code.

2. The fourth tier: interactive states

Most design systems end up with too many tokens, especially when you add interactive states. Each button variant gets its own token for hover, pressed, and focus, and the numbers quickly add up.

If you count honestly: filled, outline, soft, and ghost are four variants. Multiply that by different intents like destructive, success, and neutral. Then multiply again by three states each. Suddenly, you're creating dozens of state tokens by hand, and each one is a potential source of inconsistency.

This is often the layer with the most complexity, but it gets the least attention.

3. OKLCH math instead of opacity overlays

A common shortcut for states is to use an opacity overlay. Material Design uses this approach, and it can work, but it makes contrast harder to control. Some colors start to look muddy, and dark themes can become unpredictable.

A cleaner approach is to define state colors using OKLCH lightness shifts.

  • hover → L − 0.05
  • pressed → L − 0.10
### Layer 3 — State

OKLCH lightness deltas for interactive states. Applied in CSS via relative color syntax.

```json
"state.lDelta.hover":   { "$value": 0.06 }
"state.lDelta.pressed": { "$value": -0.03 }
```

CSS pattern:
```css
.dls-button[data-intent="primary"]:hover:not(:disabled) {
  background: oklch(from var(--dls-color-intent-primary-bg) calc(l + 0.06) c h);
}
```

‍

This method works without overlays or extra state tokens. Here’s why it holds up:

  • OKLCH is perceptually uniform.
  • A 0.05 lightness shift feels consistent across every color.
  • Dark themes stay stable.
  • Contrast is easier to reason about.
  • States can be generated automatically — your token JSON defines the logic, and the system outputs hover and pressed for you.

One note: Figma doesn't support OKLCH natively yet, so you may still use opacity as a visual stand-in inside Figma. That's okay—the real math lives in code, and Figma just provides a visual reference.

This approach reduces the number of tokens, increases predictability, and keeps your system clean and easy to maintain.

Bring it back to AI

A small, math-driven token system that lives in code is what makes AI-generated UI consistency possible.

Your token JSON becomes logic that the model can understand. With a smaller system, there are fewer places for hardcoded values to hide. You still need to check that token adaptation worked—this part never disappears—but reviewing 40 tokens is manageable. Reviewing 400 at AI speed only gives the illusion of control.

Systems scale best when they are simple at their core. Color math is a key part of that foundation.

The actual stake

So, is the designer right? Does the developer really not care?

Maybe the developer truly doesn't care, and maybe that won't change. But that isn't a reason to skip the work. Instead, it's a reason to build these practices into the system itself, so no one has to rely on individual choices.

Token adaptation is what separates a real system from just a screenshot. 'It looks like the design' is a tempting shortcut, but it can become costly—especially now that AI makes it easier and faster to ship. Visual debt has always been part of our work, but with machine speed, what once took months can now build up in just days.