Agents that build components, not just use them
Everyone is asking whether an agent can assemble a screen from our components. The better question is whether it can contribute a component back — and what a design system has to look like before that is safe.
Still thinking about who our components are for. After March I had a list: our engineers, our designers, and the outside experts I want breaking them on real assistive technology.
The list was incomplete, and I think the missing entry is going to matter more than the other three combined.
Every conversation I am in about AI and design systems is about consumption. Can an agent read our library and assemble a screen from it? Fair question, and the answer is largely mechanical: give it a machine-readable inventory, the rules, some worked examples, and it will compose reasonably well. If it cannot find what it needs, it invents something — which is the failure mode everyone has already noticed.
Nobody is asking the second question. Can an agent contribute?
Not assemble a screen from what exists. Build the component that is genuinely missing, to our standard, and propose it back into the system.
I think that is where this goes, and I think most design systems are structurally unprepared for it.
Why systems are not ready
Design systems are built to be read. Contribution is the part we never industrialised.
Think about how a new component actually enters a mature system. Someone notices a gap. They raise it. There is a conversation about whether it belongs, usually involving taste and history that lives in three people's heads. Someone builds it, someone reviews it against criteria that are mostly unwritten, and it lands weeks later. That process works — I have run it for years — but every load-bearing part of it is social.
None of that is legible to a machine. So a system perfectly readable for consumption can be completely opaque for contribution, and the gap between those two is where the next few years of this work sit.
The naive version of agent contribution is obviously a disaster. Let a generator add components on demand and you get forty buttons in a quarter, each subtly different, which is the exact entropy a design system exists to prevent.
But the fix for that is not forbidding it. The fix is making the standard explicit enough that both a person and a machine can tell whether a proposed component meets it.
What that actually requires
If I want an agent to be able to build into this system, I have to write down things we currently carry implicitly:
What makes a component ours. API shape, naming, which tokens it may reference, what it must never hard-code. Right now that knowledge is a review comment from a senior designer. It needs to be a document, and eventually a test.
When a new component is justified. The hardest one. "Use the existing one unless you genuinely cannot" is a judgement call, and it needs to become a checkable rule — because the cheapest thing for any generator, human or machine, is always to make a new thing rather than understand the old one.
What it must pass before it is allowed in. Keyboard operation. Focus handling. An accessible name. Contrast against every surface it can sit on. Behaviour in both themes. These are not preferences. They are the minimum, and they are all automatically checkable, which means they can be a gate rather than a hope.
That last one is the part I am most confident about, and it is why I think this is an accessibility opportunity rather than an accessibility risk. We have spent twenty years asking people to remember accessibility requirements. A contribution path that refuses work failing those requirements does not ask anyone to remember anything.
The thing I keep turning over
Making a system safe for agents to contribute to is the same work as making it good for people to contribute to. Explicit criteria. Written conventions. Automated gates instead of tribal knowledge. Every one of those is something I would want anyway, and have been asking for, and have never quite been able to justify on its own.
The agent is the forcing function. Not because the agent matters more than the designers, but because a machine cannot be trained by osmosis, and the moment you try to explain your system to something that cannot absorb culture, you find out precisely how much of it was never written down.
Where this goes
Here is what I want to be true here within two years, and I am confident it is achievable.
Our design system grows from real usage rather than from a roadmap. Someone building a feature hits a genuine gap. The work of proposing a component that meets our standard — correct tokens, correct API, keyboard and screen reader behaviour verified — takes minutes instead of weeks, because the standard is explicit and most of it is checked automatically. A human reviews the proposal on the things humans are actually good at: does this belong, is it named right, is it the abstraction we want.
Both directions, machine-legible. Use and build.
The teams that only prepare for consumption will end up with a beautiful library that generators route around. The ones that prepare for contribution get a system that compounds — every gap found while building makes the shared thing better, instead of becoming another local workaround nobody else ever sees.
I would rather be early to that than tidy.