`--blue-500`. That is the whole crisis, sitting in a variable name.
A human developer sees `--blue-500` and knows, without being told, that it means the primary action color, not the link color, not the info banner. The knowledge lives in their head, backfilled from Slack threads and a Figma file and a critique meeting from eight months ago. An AI agent sees `--blue-500` and knows only what the string says: a blue, roughly mid-scale. So it guesses. And it guesses fast, confidently, across every file it touches.
That gap is the subject of this issue.
Last week I asked whether organizations would actually fund a governed, portable context spine — the boring plumbing that lets both people and machines read a design system as a single source of truth. This week I think the answer is yes, and the reason is not one anyone in DesignOps will enjoy hearing.
Start with the flattest sentence I can write. Two enterprise Japanese companies scheduled conference talks this July — one on knowledge management and Notion, one on design systems.
That is genuinely boring until you read what they called the sessions. Mercari is presenting on why it invests in knowledge management "in the AI era," framing its company-wide Notion rollout as a context foundation that, per its session description, reportedly gives AI what it describes as organization-specific context. LegalOn Technologies is presenting on turning a shared foundation — its design system — into what its session description reportedly frames as a business accelerator, explicitly noting that UI unification is, per that description, only the starting point.
Neither company is there to talk about consistency. Both describe the same reframe in slightly different vocabulary: the design system, and the knowledge base next to it, are no longer housekeeping. They are context infrastructure that humans and AI consume together.
That vocabulary shift is the entire story, because it names the moment the design system stopped being a designer's private concern and became the shared spec a machine reads as law.
Justin Delabar put the mechanism most precisely. "A token system documented in Confluence and a token system published as a well-structured JSON schema are not two ways of capturing the same information; they're two different levels of AI-readiness."
Sit with that. It sounds like a formatting note. It is not.
A design system is now the specification that generative UI tools reason from — a spec in the same sense as an API contract or a data schema: the thing that defines what valid output looks like. IBM's Carbon MCP and SAP's four MCP servers (CAP, Fiori Elements, SAPUI5, and MDK) both made this literal, exposing tokens, components, and usage guidelines as live queryable context that a model retrieves before it writes a line of code.
When IBM and SAP arrive at the same architecture independently, Delabar notes, it stops being a trend and starts being a fact.
Here is why the JSON-versus-Confluence distinction is load-bearing rather than pedantic. Every naming decision in a token system is now also a decision about the range of outputs a model can produce.
A well-scoped token system bounds the model. A poorly structured one produces "a wider, less predictable distribution of AI-generated UI, because the model ends up resolving ambiguities on its own." The ambiguity a designer used to resolve silently is now resolved by a machine — at speed, in production, wrong.
This is the difference between three kinds of debt that used to blur together. Technical debt slows engineers down. Design debt erodes consistency. Design system AI debt, as George William Amalan puts it, is different: "It scales mistakes."
Technical debt slows engineers down. Design debt erodes consistency. Design system AI debt is different: it scales mistakes—fast, confident, across dozens of files.
The reason is that humans fill gaps and machines do not. A developer hitting an ambiguous `--blue-500` pauses, opens Figma, searches Slack, asks a teammate. An agent "fills those gaps with guesses. When those guesses are wrong, they're fast, confident, and can spread across dozens of production files before anyone notices."
Improvisation at machine speed looks incredibly productive right up until the pull request arrives. Then a reviewer finds `style={{ padding: 13 }}` and `className="text-[#172B2A]"` buried in a 400-line diff that no human wrote and no human can easily unwind.
Now the organizational payload, which is the part I actually want you to leave with.
The debt did not grow. It got redistributed. And it moved in a very specific direction — out of the corner where designers used to absorb it quietly, and into the corners where budgets live.
The UX Collective piece states it plainly. Design system debt "used to be paid by one person, quietly, in files nobody else opened. Now it gets paid by the engineer whose generated component is wrong, the PM whose timeline slips because handoff broke, the marketer whose banners came out off-brand. The cost moved out of your corner and into theirs."
Read that sentence as an accounting statement, not a lament. The liability didn't shrink; it changed whose ledger it hits.
This is why the argument designers lost for years is suddenly winning. As the same UX Collective piece notes: designers have argued for years that a design system is not a deliverable but a product needing governance, funding, and an owner. "The argument was always correct and almost always lost, because the people who held the budget never felt the failure. Now they do."
That is the cynical good news. Systems will get funded — not because leadership got enlightened about craft, but because the failure finally landed on a budget-holder's desk as a broken PR, a slipped date, an off-brand banner.
The Nielsen Norman Group's maturity framework names the dimension this touches first: organizational alignment. Is the system "resourced through a dedicated, predictable budget, or does it survive on borrowed time and goodwill?" Is it understood as "core product or shared infrastructure, or as an optional service"?
For a decade that question got answered on goodwill. The MCP era answers it on self-interest.
But here is the honest risk, and it is the one worth watching.
The machine-readable spec is the easy thing to fund. It has a clean deliverable — a JSON schema, an MCP server, a set of CI checks that ban raw hex values and magic spacing numbers. You can point at it, budget it, ship it.
The harder thing is what NN/g's framework calls the other five dimensions, and what a growing body of DesignOps writing calls orchestration: the shift from governing a human-led process to actively directing "a mixed ensemble of human and machine" decision-makers.
That work — team effectiveness, governance, support, adoption, the human judgment that decides which technically-correct AI output is experientially wrong — has no clean deliverable. It looks like people, not schema.
So the plausible failure mode is not that orgs refuse to fund the design system. It's that they fund the spec and starve the orchestration — buying the JSON while leaving the DesignOps function that keeps it coherent on the same borrowed time it always ran on.
You would end up with a beautifully machine-readable token system and no one funded to arbitrate what a new semantic token should mean, or to catch the model's confident wrongness before it multiplies.
That would be the worst of both eras: a spec precise enough for a machine to obey literally, and an organization too under-resourced to notice when the machine obeyed the wrong thing.
The reframe is real, and the funding is coming. Just watch which half of the system gets the check.