You write the rules once — a token spec, a component API reference, a page of accessibility requirements — and assume that if an AI coding agent can read them, it will follow them. That assumption underpins a year of design-system tooling: AGENTS.md files spelling out a system’s conventions, MCP servers (connectors letting an agent query live design data), and Figma’s Code Connect, linking components to their canonical implementation. Practitioner Murphy Trueman’s July 17, 2026 essay “Design Systems Need Evals” names the problem almost nobody checks: teams pipe their rules into an agent and trust the documentation did its job, without verifying the agent obeyed it. The best available evidence on how models handle long instructions says that trust is misplaced more often than teams assume.
The instruction-following evidence undercuts the assumption
The number Trueman leans on comes from AGENTIF , a May 2025 benchmark built by researchers at Tsinghua that scored current large language models against 707 human-annotated agentic instructions, averaging 1,723 words and roughly 11.9 constraints apiece — closer in shape to a design system’s page of conventions than to a one-line prompt. Its headline finding, in Trueman’s words: “The best model followed fewer than a third of them in full, and adherence fell further as the instructions grew longer and packed in more constraints.” That’s not a story about one sloppy prompt; it’s what happens once a rule set grows past a handful of items — exactly the shape of any design system worth documenting, with token scales, prop APIs, naming conventions and accessibility rules stacked together. If adherence degrades as constraint count rises in general agentic work, there’s no obvious reason an AGENTS.md file running to thousands of words would be exempt. It’s the same trust question raised when community projects packaged brands’ scraped visual identity into forkable DESIGN.md files any coding agent could install : a rule file only works if something downstream reads it. Left unverified, the design system stops being a document an agent might read and becomes a test suite it has to pass — whether anyone wrote that suite yet or not.
What a design-system eval suite actually checks
Trueman’s answer is to stop treating the design system as documentation and start testing it the way any LLM application gets tested before shipping: prompt-and-expected-output pairs, run several times each, since the same prompt can yield different code from the same model. He splits checks in two. Mechanical assertions catch what’s countable — did the component pull a proper token reference instead of a hard-coded hex value, does its API match the documented props, is there an accessible label on the interactive element. LLM-as-judge rubrics catch what’s subjective — does the result read as the system’s style, not just technically compliant with it. Wire both into CI, and a pull request that drifts from the rules fails the way a broken unit test would. Trueman cites Kaelig Deloumeau-Prigent’s account of an eight-agent pipeline at Intuit generating components as evidence this isn’t hypothetical: teams already run agents against production systems, with or without anything checking the output.
The design system stops being a document an agent might read and becomes a test suite it has to pass.
It runs parallel to what happened when shadcn/ui’s underlying primitives switch propagated one maintainer’s defaults into countless codebases without any design org choosing them: once an agent, not a human reviewer, applies a design system on every pull request, its authority stops living in the document and starts living in whatever gets enforced at merge time. A design system that exists only as prose a person might reread is, in that world, functionally optional.
The “under a third” number is a strong analogy, not proof
The honest complication is that AGENTIF never measured design-system compliance specifically — it’s a general instruction-following benchmark built from 707 tasks across 50 real-world applications, not Figma files or component libraries. Reading its numbers onto AGENTS.md and Code Connect is analogy, a strong one given how closely the rule shapes resemble each other, but nobody has run the equivalent study and counted how many token violations an agent actually ships. Evals carry their own cost, too: maintaining prompt-output pairs is ongoing work, and most design-system teams — often one or two people, unlike Intuit’s eight-agent setup — lack the headcount to sustain it. The LLM-as-judge half compounds the uncertainty rather than resolving it, since the judge is itself nondeterministic; a green run proves the rubric passed today, not that the system’s visual intent survived contact with the code. No source yet quantifies how much compliance improves once a team adopts evals — closer to a reasonable bet than a proven fix — not unlike the argument that real coding governance gets discovered from failures mid-project rather than specified upfront , since an eval suite, too, mostly earns its keep by catching what a spec didn’t anticipate.
None of that argues teams should wait for a definitive study before writing their first eval. It argues for modesty about what a green CI run actually proves — and for treating the design system less like a manuscript to be admired than a claim re-earning belief, one pull request at a time.
