For most of the last decade, the design systems community argued that what we build should be treated as a product. Give it a roadmap. Give it an owner. Measure adoption. That framing was useful because it pushed back against the assumption that a component library could be shipped once and left to fend for itself.

AI has quietly retired that argument, and replaced it with something more consequential. Reading through what the Design Systems Collective community wrote and published this month, the conversation felt less like practitioners advocating for product status and more like one realising, sometimes mid-sentence, that what we build has become infrastructure. Not metaphorically. Functionally. The token layer underpins generation pipelines. Component APIs are what agents call when they build interfaces. The design system is load-bearing in ways it never was when the primary consumer was a designer copying a frame in Figma.

Still Running a Product Playbook

The problem is that most organisations haven’t caught up to that shift. Infrastructure thinking changes what you prioritise, how you govern, and what you treat as debt. A lot of teams are still running a product playbook on a system that has outgrown it. I see this as much inside organisations as I do across the industry: the system is increasingly doing more, and the investment and understanding around it hasn’t moved at the same pace.

The Wrong Layer

What the writing coming through DSC this month made clear is that even the teams who have made the infrastructure shift are stopping at the wrong layer. The token architecture is largely settled.

Anna Salnikova’s write-upon reorganising her typography system reads less like a discovery and more like someone cleaning house, confident in the approach, focused on execution. The primitive-to-semantic split is just how the work gets done now. The community has settled something there.

What it hasn’t settled is the meaning layer, and that’s where the real gap lives.

Props Explain Mechanics. Not Intent.

Madhesh P made the argument directly: most design system documentation is a catalogue, not a guide. It tells engineers what a component looks like and which props it accepts. It doesn’t tell them what the component means, when it belongs, or when something else is the smarter choice. Props explain mechanics. They don’t explain intent. A polished Storybook instance can create the impression the system is working, right up until an engineer picks a toast for a critical error because nothing in the docs told them not to. The system didn’t fail. The meaning layer was just never there.

What AI Exposed

This gap has always carried a human cost. AI has made it structural.

Karthin Srinavakili put it plainly: your AI agent can’t read your design system. Not because the tooling is broken, but because a system built around visual snapshots and prop tables gives an agent almost nothing to reason with. It sees a purple button. It doesn’t see a primary commitment action that should appear once per view and never inside a dense table. Without intent, agents hallucinate props, bypass tokens, and build components from scratch when a perfectly usable one already exists.

Murphy Trueman’s piece on agent traces is the most useful provocation to come through DSC this month. Agent session transcripts, she argues, are the most honest feedback your design system has ever received. Every hallucinated prop is a hypothesis the agent formed because the documentation left room for it. Every corrective turn, where a human pushes back and the agent revises, is a labelled example of where the meaning layer is missing. The data is already being generated. Most of it expires in thirty days because nobody is treating it as signal.

Damini Patil framed the underlying shift well: design systems built for human readers worked because humans already shared the context. A designer and a developer both knew the user flow. Agents don’t share that mental model, and they never will. Intent is how an AI understands how to use a system rather than simply assemble an interface from it.

Alignment, Not Efficiency

That distinction matters more than it might seem. Infrastructure that carries no meaning is just plumbing. It connects things, but it doesn’t align them. The case for design systems was never really about efficiency, though that’s how it tends to get sold internally. It was always about keeping teams aligned around shared decisions. The token layer encodes some of those decisions. The meaning layer encodes the rest: why a component exists, when it belongs, what it should never do. That’s the part that keeps humans and agents building the same product rather than adjacent versions of one.

The component was never the hard part. It never has been. Writing down what the component means, and keeping that current, has always been the work most teams find reasons to defer.