Further reading

Scores a field of 37 against five first-party signals: an MCP server, llms.txt, DTCG tokens, an installable component registry, and published Code Connect mappings. Wrappers and third-party shims do not count. Re-audited quarterly, and downloadable as JSON and CSV under CC BY 4.0.

A build report: eight agents across an Understand, Build and Verify pipeline turning a Figma file into a production Menu component, each with a named artifact, exit criteria and a retry budget. Full autonomy hit a ceiling, and the fix was a human gate rather than a better prompt.

The pipeline could follow rules but it couldn't question.

A practitioner survey, n=147. One in ten teams has AI in the process, just under half are experimenting, and the rest are not. Code generation leads the use cases, then documentation generation, then prototyping. Where this list mostly reads artifacts, this one asks people.

A free assessment that places a system on six independent axes rather than one score, each running through four stages. One of the axes is AI readiness, which makes this the closest thing to a self-serve version of the question this report asks. Built on the four-stage model from Sparkbox.

Whether your design system is the default context that AI tools build from, or whether AI is silently working around it.

Argues that a design system with agents pointed at it should ship a regression suite the way it ships a changelog. Your instructions tell an agent what the rules are; only running it under real conditions tells you whether it followed them.

You've taught agents your design system. You still don't know whether they're following it.

Separates the architecture question from the accountability one. Agents working in a loop is a claim about capability; a design system is a way of encoding collective judgment and holding people to it. Offers one test for anyone selling the former as the latter.

what rejects the agent's output, and who decided the rule it's being rejected against?

The design side of the same shift. Naming conventions, semantic tokens and complete component states stop being documentation hygiene and become the instructions a machine follows, which puts more of the outcome in the designer’s hands and less of it up for interpretation.

Three moves for the year: MCP servers, skills and design guidelines; designing in code rather than on a canvas; and shipping patterns as structured relationships instead of components. Argues a system has to document when and why, not only how, because the why is what a model otherwise guesses at.

AI is finally starting to change what a design system ships.

Reads the modal side by side in Carbon, Material UI, Polaris and Radix, then shows how each one’s naming and composition choices commit it to a different contract with whoever consumes it, human or agent.

Where a component expresses its structure is where it communicates its contract.

Makes the case for treating a component library as an interface other software consumes: explicit semantic contracts, purpose-driven naming, machine-readable documentation. The earliest work on this list, and the one the others keep arguing with.

Your design system is already an API; the question is whether it's a good one.

An eighty-minute conversation rather than a conference talk, recorded before most of the writing on this list. The oldest work here, and the one most likely to have been overtaken.

AI is rapidly reshaping who (or what) uses your design system.

Six chapters covering AI fundamentals, tooling setup, improving an existing system, and rolling the result out across an organisation. Released iteratively, with live jam sessions and a Slack community alongside.

Six modules taught by practitioners from WhatsApp, GitHub, Figma, Adobe, Miro, Atlassian and Indeed: agentic design systems, making a system machine-readable, AI infrastructure, and shipping production code as a designer.