Why token pipelines are breaking at the last mile

Why is it that we can land a rover on Mars, but we still can’t get a semantic “surface-primary” token to look the same in Figma as it does in a React production build? We’ve spent the last three years obsessing over naming conventions and JSON structures, yet the “last mile” of design tokens remains a chaotic mess of manual overrides and CSS regressions.

The theory is brilliant. We use a single source of truth, automate the handoff, and magically, the entire interface updates across every brand and platform. But in reality, most enterprise pipelines are held together by digital duct tape and hope.

As we look toward 2026, the baseline for enterprise systems has shifted. It’s no longer enough to just have a list of hex codes in a spreadsheet. We’re moving toward standardized architectures aligned with the Design Tokens Community Group (DTCG) specs, but the translation layer — the bit where design intent meets browser reality — is where everything falls apart.

The semantic naming trap

Honestly, we’ve become a bit obsessed with naming. We spend weeks debating whether a token should be called color-bg-subtle or surface-secondary, only to find that the developer has hardcoded gray-100 because the token wasn't available in the legacy Sass mixin.

The problem isn’t the name itself; it’s the lack of context. A token is more than a value; it’s a decision. When we strip away the “why” during the pipeline transformation, we leave the implementation open to interpretation.

If your pipeline doesn’t carry the intent — like whether a color is meant for text contrast or just a decorative border — the system will eventually break. This is especially true as we move toward more complex color spaces like OKLCH, where the math behind the colour is just as important as the visual result.

The multi-brand collision

Multi-brand systems are the ultimate stress test for any token pipeline. It’s easy to manage one brand, but what happens when Brand A requires a 4px border radius and Brand B demands 12px, all while sharing the same React component library?

Most pipelines handle this by creating massive, nested JSON files that are a nightmare to maintain. We end up with “token bloat,” where the sheer volume of variables slows down build times and confuses everyone involved.

According to recent insights on the future of enterprise design systems, the trend is moving toward more automated, AI-assisted pipelines that can handle these variations without human intervention. But even with AI, if your foundational logic is flawed, you’re just automating the delivery of bad decisions.

// The "Last Mile" breakdown: What Figma sees vs what Code gets
{
  "semantic": {
    "action": {
      "primary": {
        "$value": "{brand.primary.600}",
        "$type": "color",
        "extensions": {
          "com.figma.variableId": "f123..." 
        }
      }
    }
  }
}

Contrast and the APCA hurdle

We are finally moving away from the outdated WCAG 2.1 contrast ratios and toward the more perceptually accurate APCA (Advanced Perceptual Contrast Algorithm). This is a huge win for accessibility, but it’s a massive headache for token pipelines.

Most automated tools are still built on the old luminosity math. If your pipeline isn’t designed to calculate contrast on the fly using modern algorithms, your “accessible” system might actually be failing users in the real world.

I’ve seen teams try to bake these calculations into Figma variables, only for the CSS output to lose all that nuance. This is exactly why I focused heavily on OKLCH and APCA when writing Ship Your Design System; if you don’t solve the math at the pipeline level, you’re just guessing.

The “Figma-to-Code” illusion

We’ve been promised a “no-code” handoff for years, but the last mile is stubbornly resistant to full automation. The issue is that Figma variables and CSS variables don’t share the same mental model.

Figma treats variables as a flat list or a simple hierarchy, while CSS relies on inheritance and the cascade. When you try to force one into the other without a sophisticated transformation layer (like Style Dictionary or a custom script), you end up with “ghost tokens” that exist in design but throw errors in the console.

To bridge this gap, we need to stop thinking of the pipeline as a one-way street. It’s a loop. Developers need to be able to feed constraints back into the design tool, and designers need to understand how their “simple” change might trigger a massive re-render in a production environment.

The 2026 baseline

The next two years will be about maturing these connections. We’re seeing a shift toward design-to-code pipelines as the new standard, where the pipeline itself is treated as a first-class product. It requires its own testing suite, its own documentation, and its own governance.

If you’re still copy-pasting hex codes into a :root block, you aren’t building a system; you’re building a debt mountain. The teams that succeed will be the ones that master the translation—ensuring that a brand's visual identity survives the journey through the JSON wilderness and arrives on the screen exactly as intended.

Wrapping up

The last mile of a design system is where the value is actually delivered. If your tokens don’t behave consistently across platforms, you haven’t solved the problem; you’ve just moved it.

• Focus on intent over names: Ensure your tokens carry semantic meaning that survives the transformation process.
• Embrace modern color math: Start preparing your pipeline for OKLCH and APCA now, rather than retrofitting it later.
• Treat the pipeline as code: Use version control, automated testing, and clear governance to manage how tokens flow from Figma to React.

If you want the long-form version of this with 23 chapters and runnable code, Ship Your Design System on Amazon is the handbook.

Twitter https://x.com/alexandersstudi · LinkedIn https://www.linkedin.com/in/alexandersstudio/