Design Tokens Are Prompts Now

Originally published at mauriciojuba.com

ESSAY · DESIGN SYSTEMS × AI

The primary consumer of a design system changed species — and most design teams haven’t noticed.

For ten years I wrote design tokens for human engineers. In 2026, the primary consumer of a design system changed species.

The old contract

A design token was always a contract: this is the blue we mean, this is the spacing rhythm — and here it is as data, so your code can consume it without a designer in the room.

At Dell, I rebuilt the Design System’s token architecture around exactly that idea. The system was stalled — strong foundations, run as a black box. The real blocker wasn’t governance, as leadership suspected; it was that the tokens were named by designers, for designers, with no export pipeline. The people actually consuming them — front-end engineers — had been ignored by the naming.

We flipped it: a simplified core + semantic hierarchy, light and dark, shipped as JSON and CSS to every dell.com surface. The lesson I’ve repeated ever since: naming is a product decision — optimize for the real consumer, not the author.

I just didn’t expect the real consumer to change again this fast.

What changed

By 2026, a large share of new UI code is machine-generated — half of designers surveyed say they’ve shipped AI-generated code to production. Claude Design reads a team’s design system straight from the codebase and applies it. Figma ships a native AI design agent. Every product team has a coding agent somewhere in the loop, emitting components at a pace no design review can inspect.

And generated UI has a specific failure mode: speed without memory. Each session, each model, each prompt invents its own paddings, its own grays, its own border radii. Individually plausible, collectively incoherent. Drift used to take an org quarters; an agent fleet manages it in an afternoon.

Here’s the part that should reframe your roadmap: when an agent generates UI, it doesn’t read your Figma library. It reads your repo. Your tokens file. Your component signatures. Your docs — if they’re in a format it can parse. Figma’s own framing of its Dev Mode MCP server is that output quality tracks how connected your system is; the documented failure mode is hard-coded values sneaking in when the system isn’t machine-legible.

Your design system’s machine-facing surface is now its primary interface. The token file stopped being an export artifact. It became the prompt.

Conventions erode. Compilers don’t.

If tokens are prompts, a new problem appears: prompts are suggestions. Models — like busy humans — follow them until they don’t.

Every design system I’ve worked on had governance by convention: guidelines, review rituals, a Slack channel where someone occasionally posts “please don’t hardcode colors.” It erodes. Always. New hires don’t read the wiki; deadlines beat guidelines; and now, agents hallucinate a plausible hex because it was statistically likely.

The only enforcement point that doesn’t erode is the build.

I tested this thesis the hard way. For my own tooling project — an authoring IDE in Rust — I rebuilt the shadcn/ui design language natively for egui: 60+ components, token-first. And I encoded the law as tests: a literal color, font size or spacing anywhere above the token layer fails the build; only the lowest layer may touch the painter. Escape hatches exist, but they’re explicit and greppable. An exception you can grep is documentation; an exception you can’t is rot.

Then I did most of the component work pairing with a coding agent, daily, for weeks. The result surprised even me: the system didn’t drift. Not because the model was disciplined — because the build was.

That’s the whole thesis in one loop: I didn’t review the machine’s taste. I made taste non-negotiable at compile time.

Tokens were the easy part

“Design tokens as LLM context” is the entry point, but the appreciating asset is bigger. If I were running a design-systems team today, this would be the roadmap:

The uncomfortable part for my own field

I’ve watched designers treat the AI wave as a tooling story — which prompts to learn, which plugin to install. The structural story is bigger: the deliverable is moving. The mockup was never the product; now even the component library isn’t the product. The product is the constraint system that keeps a thousand generated screens recognizably yours.

That work is design work — it’s taste, hierarchy, intent. But it ships as tokens, tests, types and docs. The designers who can write that layer are becoming the most leveraged people in the building: one good constraint system disciplines every agent that touches the codebase, forever.

The brand-guideline PDF died twice. The first time, tokens replaced it — because humans needed data, not prose. Now the prose is dying again, as the machine-facing surface becomes primary.

Design tokens are prompts now. The build is the reviewer. Write accordingly.

PROOF BY CONSTRUCTION

The design system described here is open source: ouroboros-ui — 60+ components whose governance tests fail the build, with a live storybook running in your browser.

References — Anthropic, Claude Design · Figma, Config 2026 & design systems + MCP · W3C Design Tokens Community Group (format module reached first stable version, Oct 2025) · AI in Design Report 2026.