Install HeroUI’s React library into a fresh project and its CLI writes something into your repo’s AGENTS.md: “STOP. What you remember about HeroUI React v3 is WRONG for this project. Always search docs and read before any task.” That’s not a stray debug line — the State of AI in Design Systems survey , published 1 September 2026 by Kaelig Deloumeau-Prigent, calls it “the strongest coercion artifact” in a catalogue of 157 techniques 20 open-source design systems have built to argue with the AI writing their code, because roughly 30,000 stars of the library’s old v2/NextUI code sit in every model’s training data against a v3 API that broke almost all of it. The AI writing your company’s screens has memorized last year’s version of your component library, and the people who maintain it now write it notes in capital letters.
Validation and prohibition dominate the corpus
The survey sorts its 157 techniques into 11 categories. Validation loops top the list — 30 techniques, present in all 20 systems — with outright prohibitions close behind at 26 across 19. Ant Design’s copilot-instructions.md reads like a rap sheet of what the model keeps inventing: it names the exact components an agent hallucinates — Container, Stack, Heading, Box, Sidebar, Navbar, IconButton — and states flatly that antd exports none of them. It’s a correction, not onboarding: the design system’s job used to be teaching a developer who knew nothing, and now it’s arguing with a model that’s already certain, and wrong.
The stakes split by which side of the library you’re on. A developer new to it reads the docs; a model already has a confident, wrong answer baked in by however many repos ran the previous version. If you maintain a component library, shipping a breaking change now means authoring and maintaining a second artifact whose only reader is a model. If you consume one, the agent in your editor keeps importing a Stack or a Container your library never exported until someone on the maintaining side writes the sentence telling it not to.
The design system's job used to be teaching a developer who knew nothing. Now it's arguing with a model that's already certain, and wrong.
The one category almost nobody has built
Buried at the bottom of the same table sits design-to-code mapping — three techniques, the smallest category by far, and none of them is Figma’s own Code Connect : that’s a system-level integration only 2 of the 20 design systems, Carbon and Primer, wire in, cataloged apart from the 157. Adobe’s React Spectrum S2 does its own by hand instead: its agent guide demotes Figma’s Dev Mode MCP server to “a reference, not a code generator,” since it “does not produce S2 output,” substituting a hand-written table mapping Figma layer names to S2 props — filling in, the survey notes, “for the Code Connect mappings Adobe has not published.” That’s the reliability gap an earlier Pipeline analysis argued design systems need evals, not just rules, to close — a mapping nobody built can’t be followed either way.
| Category | Techniques |
|---|---|
| Validation loops | 30 |
| Prohibitions | 26 |
| Design-to-code mapping | 3 |
What the survey can show, and what it can only suggest
The survey claims no more than what it counted: a census of what 20 maintainers wrote, not a trial of whether the writing works. Two Python-library studies come closer: a benchmark of 270 real-world API updates found generated code executable only 42.55% of the time without structured documentation, rising to 66.36% with it, according to a benchmark on knowledge conflicts from evolving APIs . A companion study, LibEvoBench , found models “version-oblivious” by default — naming a target version does nothing, only real documentation does. Neither paper touches a React library, let alone HeroUI’s line. Read the design-systems census against that research, though, and a claim becomes reachable: correcting a model’s confident memory of last year’s API, not onboarding a developer with none, is now the design system’s central agent-facing job.
That job isn’t wasted effort, either. Instruction files and an agent’s own working notes account for 60.5% of the documentation coding agents consult, against 1.3% for formal API references, most of it read unprompted, according to a study of how coding agents discover and read documentation . Pipeline traced the same split : instructions change agent behavior even when a generated architecture tour doesn’t — echoing a July debate over what AI-ready design documents leave out . Writing at the model, rather than for it, may simply be the best lever a maintainer currently has.
The survey knows its own limits, too. Deloumeau-Prigent calls it “a dated snapshot, not a live index,” captured over three days in late July, of 20 open-source systems — unusually exposed to the problem they’re fighting, since their old versions fill public training data. A private, internal design system has the opposite problem: the model has never seen it, and needs a different fix than a note correcting a memory it doesn’t have.
The three design-to-code mapping techniques that do exist — Ant Design’s rename table, Adobe’s hand-written Figma-to-props table, and shadcn/ui’s registry-as-oracle codemod — are humbler than Code Connect, and the rest of the 157 are, overwhelmingly, the design system telling the model, in various tones of patience, that it’s wrong. Until the binding between a design file and the code it should become is more than three entries at the bottom of a table, that correcting job stays what it is now: unglamorous, permanent, and paid for entirely by whoever ships the next breaking change.
