For twenty years the business case for a design system was efficiency. Write the button once, reuse it everywhere, and the work gets cheaper. That case is still true, and it is no longer the interesting one. Something changed underneath it: the primary consumer of your design system is increasingly not a person.

A coding agent does not open your Figma file to admire it. It reads it, resolves a token, and emits markup, without asking whether it should. Every assumption you made about review, scrutiny and human judgement assumed a human in the loop who could pause. That assumption is now the weak link in the chain.

What actually moved in 2026

Several things shifted this year, and they are related in a way that is easy to miss if you look at them one at a time.

The first is that design files became machine-readable. Figma's Dev Mode now exposes structured design data through the Model Context Protocol, which turns a design file into a queryable source that coding agents such as Cursor, Windsurf and Claude Code can consume directly. The shift is real enough that it has a name in the design systems community: the operational paradigm is moving from design-to-developer handoff to design-to-agent orchestration. The file stopped being a picture of a decision and became the decision itself.

The second is that the layer beneath the tools started to standardise. The W3C Design Tokens Community Group released its first stable specification, v2025.10, in October 2025: a vendor-neutral JSON format that lets Figma, Tokens Studio, GitHub and production codebases exchange tokens without a lossy translation in the middle. Colour, spacing and typography decisions can now move between tools without being retyped by hand, which means they can be reviewed in version control.

The third is that components are escaping the framework. Shopify's release of its Polaris web component library is the visible example, and web components are showing up in more design system stacks each year. The direction is consistent: a component that lives in a framework is a component one team can use, and one that lives in the platform can be used by everyone.

The fourth is quieter but more consequential: accessibility stopped being a checklist item. The industry is moving from a single contrast ratio to APCA, which accounts for font weight, size and surrounding brightness rather than passing or failing one number. It is a better model, and it is also a harder one, because it requires the system to encode luminance context rather than declaring a colour and moving on.

And the numbers are not encouraging. The Design Systems Report 2026 found that only 8% of enterprise teams describe their own design system as very stable, and that nearly half report significant instability. Seventy-six percent ship no onboarding material at all. Sixty-nine percent say they encourage open contribution, and yet more than two in five still gate-keep what gets in. Meanwhile the top complaint across every category dropped year on year, with accessibility complaints falling from 46% to 10%.

Read together, those numbers describe a field that has genuinely advanced its standards while failing to maintain its systems. The infrastructure got better. The stewardship did not.

Why a closed system now fails in a new way

A design system used to be a private efficiency project. The worst outcome was a team that rebuilt your button and drifted from your brand. Expensive, embarrassing, recoverable.

An agent does not recover. It does not notice it has drifted. When a model generates from a messy system, the output inherits the mess at a rate no human reviewer can absorb, and it looks confident while doing it. Give an agent access to an unmaintained system and you have not made development faster, you have made hallucination faster. The error rate improves only when the system underneath is genuinely clean, and a system that nobody outside a small group can inspect, fork or improve is not going to be clean.

This is the whole argument. Once a machine is a primary consumer, review is the only control that scales, and review requires that the thing under review be readable by the reviewer. You cannot review what you cannot inspect. A system locked inside a proprietary tool, with token names only its authors can interpret and contribution gated behind a form, produces output that nobody outside the team is in a position to check.

Openness is usually defended as generosity towards the community. It is more useful than that. It is a control mechanism. A system whose source is in version control, whose tokens are portable, and whose history is legible is one where an agent's output can be checked against something real. That is not an open-source nicety. That is how you keep an automated system honest.

Four tests for what open should mean

Teams use the word open to mean that they have a contribution form. That is not open design, it is a reception desk. Four tests separate the two.

The source of truth is in version control, and the design tool is a view of it. Not the other way around. If the design file is canonical and the code is generated downstream of it, then your history is a comment thread, your review is a screenshot, and your merge conflicts are somebody's problem in a standup. Inverting this is uncomfortable and correct.

Tokens and contracts are portable at the spec layer. The W3C format already exists and is free. Using it is not a compromise, it is the point: the value of your design decisions should not evaporate because somebody changed tools. Portability is what makes a system a public artifact rather than a private asset.

Contribution is federated with real review capacity. Two in five teams gatekeeping contributions is not a governance model, it is a bottleneck with a form in front of it. Open contribution only works if someone is funded to review it. If your reviewers are already the constraint, the honest move is to narrow the scope of what you accept and be explicit about it, not to leave a door open that nobody answers.

Provenance is inspectable. You should be able to find out why a colour changed, who approved it, and what it replaced, by reading a diff. This is unglamorous and it is the thing that makes everything else auditable.

What this asks of us

The honest position for a studio is that we are not exempt. We advise clients to build systems and we build our own, and the same test applies: could a competent stranger read our design decisions without a meeting? If the answer is no, then the recommendation we are giving clients is not one we have taken ourselves.

The 8% figure is the one worth sitting with. A field that agrees on a token standard, agrees on perceptual contrast, agrees that agents are coming, and still cannot keep eight out of ten systems stable has a maintenance problem, not a tooling problem. No specification fixes it. A spec makes the failure visible, which is where the work starts.

Design systems were always going to be part of the public commons in the way that typefaces and design principles are. What changed is that something is now reading them on our behalf, at volume, without checking. If that something is going to be pointed at your components, your system had better be something you are willing to stand behind in public.