What happens when the design system makes the decisions?

I spent the last few weeks reading design engineering and design systems job posts, and something has changed in how companies describe the work.

A year ago, most posts asked for someone to build and maintain a component library. Now the language is different. Mixpanel wants someone to turn its design system into the infrastructure that powers how the company designs and builds. Miro calls its system AI-native. Another post asks for AI-assisted workflows that connect Figma to production code.

These aren't small wording changes. They describe a different job, and a different kind of risk.

The library became infrastructure

A component library is a product people use. Designers pick from it, and engineers import from it. If a component is missing or wrong, a person notices, works around it, and maybe files a ticket.

Infrastructure is different, because other things are built on top of it, often without a person looking at each step. That's where design systems are heading, and I see three reasons.

The first is that AI tools now generate UI from the system. Code assistants and design tools assemble screens from our tokens and components, so the system is their vocabulary.

The second is that design and code are connected by pipelines. Tokens flow from Figma to code, and components are mapped across both, which means a change in one place lands in many.

The third is that more people ship UI. Product managers and engineers outside the front-end team now ship interfaces with AI help, and they trust the system to make the right choices for them.

In all three cases, the system is no longer something people consult. It's something work runs on.

Every gap repeats

When a person uses a flawed component, the flaw shows up once. When an AI tool uses it, the flaw shows up on every screen the tool generates. Quietly, and fast.

Think about what that means in practice:

• A button with no visible focus style becomes 400 buttons with no focus style.
• An icon button with no accessible name becomes a product full of buttons a screen reader announces only as "button."
• A color token that fails contrast becomes the default text color for every new page.

Nobody decided to ship those bugs. The system decided for them. That's the real shift: the design system is now making decisions at scale, and its mistakes scale with it.

Accessibility has to live in the system

Most job posts I read list accessibility as one bullet among ten. "Cares about accessibility." That made sense when accessibility was something we checked at the end, page by page.

It doesn't work when the system generates the pages. If accessibility isn't built into the tokens and components, no one downstream will add it back. The AI tool won't. The product manager shipping a quick internal tool won't. And the audit at the end will find the same issue in 400 places.

So accessibility has to move into the foundation:

• Tokens carry contrast rules, not just colors. A text token is only valid on the backgrounds it was tested against.
• Components carry semantics, names, keyboard behavior and focus by default. The easy path is the accessible path.
• Checks run in the pipeline. Contrast, names and roles are tested on every change, the same way types and tests are.
• Documentation is written for machines too. AI tools read our docs, and clear rules about when and how to use a component help them make the right call.

There's a second reason this matters. AI agents are starting to use interfaces, not just build them. They read the same structure screen readers do: semantic HTML, roles, names and states. So a system that serves screen reader users well is already most of the way to serving agents.

We're already doing this at ClearCo

This isn't theory for me. It's the work my team is doing right now at ClearCo, on the new version of our talent management platform.

Template repositoryReviewProduct

1. 1Template repositoryRead the rulesPeople and coding agents read the design rules, accessibility standard and writing guidelines first.
2. 2Template repositoryBuild on the real systemThe real components and tokens, with mock data.
3. 3ReviewOpen a pull requestDesigners and product managers, the same as engineers.The same review gate as engineers
4. 4ProductShipKeyboard behavior, focus, structure and contrast came with the components.
5. 5Template repositoryFix drift at the sourceDrift found downstream comes back as a pull request against the template.

Handoff is working code now, not static files. Designers and product managers ship pull requests through the same review gate as engineers. And when drift shows up downstream, it flows back upstream as a pull request against the template.

The system is a running app, not a library. We built a template repository on the real component library and tokens, with mock data. It installs on any machine, and it's where designers and product managers now build.

The rules are written for people and agents. Our design rules, accessibility standard and writing guidelines live as markdown files in the repository, and both people and coding agents read them before anything is generated.

Accessibility ships in the starting material. We set WCAG 2.2 AA as the target and moved accessibility out of the end-of-line audit and into the components. Keyboard behavior, focus, structure and contrast come with every component by default.

And agents use the product, too. We built a proof of concept that lets an AI agent operate the platform through the same connections the app already uses to talk to its server. The agent acts with the permissions of the person signed in, and no more.

None of this is finished. But the direction is clear: the system is the product's foundation, and accessibility is part of that foundation, not a check at the end.

Treat it like infrastructure

If your design system is becoming infrastructure, here's what I'd do:

1. Measure quality at the source. Track accessibility defects in components, not just on pages. One fix in the system is worth hundreds downstream.
2. Add gates, not reminders. A contrast check that fails the build does more than a guideline nobody reads.
3. Staff it like a platform. A design system that powers AI generation needs engineers who own it full time.
4. Test what the AI actually produces. Generate screens from your system on purpose and audit them. That's where you find the gaps your users would find later.
5. Put accessibility expertise at the foundation. Not as a reviewer at the end, but as an owner of the tokens, components and checks everything else is built on.

The job has changed

The companies writing these job posts are right. The design system is becoming the layer that both people and AI build on. But a foundation is only as good as what it gets right by default.

That makes this a good moment for accessibility. For years, we asked teams to remember it on every page. Now we can build it in once, at the source, and let the system carry it everywhere. If we don't, the system will carry the gaps everywhere instead.