What does it mean, exactly, for a design system to be “AI ready”? As a design systems engineering leader, I’ve been thinking about this question a lot. When I look around the industry, it seems most design systems teams have attempted to answer this question by converging on tactics: Making documentation machine-legible. Encoding design data (aka tokens) in a format with sensible semantics and interpretable structure. Creating AI skills, llms.txt files, and MCP servers that furnish LLMs with the right information on how to find and use foundational elements and components.

But it’s not just tactics. Leave it to design systems folks—who have always been generous in sharing notes—to take it one step further: as these solutions have emerged, so has the public documentation about the solutions. We now have assessments and leaderboards (multiple, in fact!) enumerating the major design systems, detailing their level of capability across multiple attributes. At the same time, overlapping and competing “standards” for design system encoding have also popped up: the Design System Doc Spec, Google’s DESIGN.md, and Adobe’s Design Data Specification. And all of this is happening at rapid speed, with teams trying to figure it all out while the entire software development lifecycle changes underneath them. A recent zeroheight report captured the frenetic energy in this space pretty well: “AI is strengthening the design system team’s position even as fears grow of being bypassed or devalued. Stakeholder expectations are racing ahead of what AI can actually deliver, and the system is being positioned as infrastructure for AI at the same time it’s being routed around.” Or, as PJ Onori succinctly put it: “I’m not sure if we’re in the hardest time for design systems, but we’re definitely in the weirdest.”

During these weird times, while most teams are building roughly the same machinery and documenting the heck out of it, I feel readiness itself remains ill-defined. That’s because none of these approaches say anything about what we actually mean when we say a design system is “AI ready.” Readiness implies a promise of something delivered. Tactics are a means to an end, but they don’t say much about what that end should feel like.

Framing the question

Here’s a thought experiment: If you give a reasonably capable model your design system’s documentation and skills, then ask it to build a settings screen, will you be happy with the results? In my own experimentation, more often than not I find I’ll get something that follows every rule in the book and yet is, somehow … well … a little bit off. The components are real, the spacing is correct, and the colors match the system. And yet, I could show the output to any designer on my team and they will probably tell me that the AI still did a bad job.

We tend to frame design system AI readiness as an indicator of how well a design system can be used by AI. This framing treats the design system as infrastructure for AI, with the AI sitting outside the system. But when we do this, I think we will always be disappointed. Not because the work of making AI skills or machine legible documentation is wrong, but because it frames readiness as a property of these artifacts. And so any fix always involves the production of more artifacts, or improvements to existing artifacts when perhaps what’s missing is something that can’t be codified at all.

This is why I feel a better framing flips this relationship inside out. What we really want to know, when we think about readiness, is how well AI can act as a part of the design system itself. To explain why, I’m going to have to detour into cybernetics. If that sounds a bit high-minded, I’d like to point out that designers Hugh Dubberly and Paul Pangaro were arguing that cybernetics is the “lost language” of design back in 2010. Think of this as a small act towards reclaiming that lost language. I hope you’ll indulge me.

A brief digression into cybernetics

One of the most well-known concepts to come out of cybernetics is encapsulated by the popular saying, “the purpose of a system is what it does,” often abbreviated POSIWID. First coined by the British cybernetician and management theorist Stafford Beer, it basically says we should ignore what a system claims to be for, and instead watch what a system actually produces. The ostensible purpose of a design system is to enable consistency, quality, and “on-brand-ness” of user interfaces, at scale. This is, at least, what’s printed on the tin. But design systems only accomplish this in the hands of people with design training, good design sense and regular exposure to design patterns in the wild—people who have internalized a whole bunch of norms and conventions nobody wrote down. Which is why I’m of the (perhaps controversial) opinion that a design system is not a system at all unless you include the humans who wield it. The people are what make it “go.” Otherwise all you have is a collection of digital artifacts: documentation, tokens, Figma libraries, and components—lifeless and inert.

We can hand those same digital artifacts to an LLM and observe what the system does. By the principle of POSIWID we then discover the new purpose. And in most cases what it becomes is plausible design drift, at scale, forever. This is because by swapping the human with the LLM, we haven’t replaced an external user of the system. What we’ve done instead is replace a load-bearing part of it, thereby changing the system’s behavior.

Now, in cybernetics there is another concept perhaps less well-known than POSIWID: Ashby’s Law of Requisite Variety. Variety, in cybernetics and systems theory, is a measure of complexity, which is basically the number of states or behaviors that a system can exhibit. A single stoplight has a variety of three: red, yellow, or green. A design system of, say, 50 atomic components, multiple color ramps and other foundational elements, all applied to a specific design problem, has nearly incalculable variety. Ashby’s Law says that for any complex system to be regulated effectively, the regulator must have at least as much variety as the disturbances it needs to absorb. Or, as Beer later summarized it: only variety absorbs variety.

Historically, the regulator of a design system has always been a human designer. And a human designer is what we might call a high-variety regulator, because they can meet the effectively infinite mess of real-world design problems and constraints—weird nuances of brand context, accessibility vs. density collisions, necessary exceptions to standardized layouts—with judgment built on years of experience and gobs of tacit knowledge. Now replace the human with an LLM and a pile of Markdown files and what you’ve done is replace the high-variety regulator with a very good but lower-variety simulacrum. This really leaves us with two options: either lower the variety the regulator has to handle, or raise the regulator’s own variety.

PJ Onori found this out empirically. (He says he’s not a smart guy but I don’t believe him.) While systematically testing agents against his design system, he started with one fixed prompt, liked the output, but then noticed that maybe it was going too well. So he added randomized prompts, on the premise that randomization emulates how a design system actually gets used, which is unpredictably. This, it turns out, is variety. A fixed prompt is a low-variety environment; a randomized prompt increases the variety.

High floors and higher ceilings

Let’s return to that pile of AI-legible artifacts I enumerated at the start of this essay. Despite their apparent differences, we can group them into roughly two complementary approaches: The first is to constrain generation of UI code by feeding the LLM a pile of context and rules on how to use (or not use) the design system’s elements. This means specifically telling the agent to actually use the intended design system, use these components in such and such a way, use these colors for these purposes and not other purposes, always lay out elements in this fashion using these pre-defined spacing tokens, avoid inventing new components, and so forth and so on. Constraining generation shrinks the disturbance variety of the whole system by reducing what’s possible. The second tactic involves governing output of the LLM through evaluations and critique loops. Here you give the agent tools to check and grade its own work, then feed those evaluations back into the system for another cycle. Governing output increases the regulation variety of the system, or the amount of differing output it’s able to effectively handle.

Returning to POSIWID, in practice design systems have never really guaranteed either quality or consistency. All they guarantee is a reasonable floor for both. It is the humans in the system who hold up the ceiling and determine how high it goes. So, when we talk about AI readiness what we’re really asking are two things: First, by replacing the humans with AI, does the floor remain stable, or does it sink? And, second, which bits of the ceiling can we afford to lose? Most design systems readiness work tends to focus on the former question. Yet the latter question is arguably more interesting, because answering it requires determining where and when you keep humans in the loop.

The trouble with tacit knowledge

By definition, there’s no way to write down the tacit knowledge of an entire design team. As Michael Polanyi said, “we can know more than we can tell,” and most of what a team knows isn’t unwritten-but-writable stuff. Much of what you can do with a design system might be technically allowed by all the rules you can think of, but still strike designers and users alike as a mistake. That settings screen example from earlier may not have broken a single rule that anyone had written down, and yet every designer who saw it knew immediately that it was wrong. Maybe the layout was technically allowed but slightly off-brand, or a particular component variant was overused, or the typography was totally on brand but still didn’t quite work. Documentation can cover a lot, but it’s a tall order to try and cover everything because so much of design judgment is not a proposition sitting in anyone’s head.

So … what to do?

I don’t have a great answer here; I can only propose an idea I haven’t actually tried. But maybe, if you can’t write down all the rules, you can still capture the stream of design decisions a team makes every day.

Recently, David Hoang proposed the idea of a unified design ledger that captures the context, decisions, approvals, and artifacts of a team’s design work as it happens. As more teams hand more work to AI, Hoang argues, something like a ledger becomes necessary to keep human thinking visible and creditable to the organization. You need a way of seeing who did what and how, because AI churns out high fidelity artifacts that can easily fool a recipient into thinking more thought went into that artifact than actually did.

The ledger is a tool for upholding human credibility, but there might be a second-order benefit. While it may not capture all the unwritable rules of good design, such a ledger would certainly capture how those rules are applied in real-world contexts, the verdicts of the design process. An invisible ledger could hypothetically be integrated into design tooling such that it captures the most salient residue of design work—decisions, annotations, final specifications—as it happens, in situ, without anyone telling it to do so. This could allow teams to move from trying to document design judgment to simply instrumenting it. Every decision around layout for common patterns, every time a designer intentionally detaches from the system (and for good reason), every time accessibility and density collided and someone had to make a choice. All of this serves as possible training data to help further govern LLM output or constrain LLM generation.

There are, of course, downsides. First, designers may bristle at the very idea of a ledger that can be used to train a system to design better, not just because of the apparent encroachment on the territory of human judgment, but also because the ledger could be abused as a surveillance tool. I take that seriously and don’t have a good response. What I can offer is engineering as a point of comparison, where work has always been easy to surveil through source control and code analysis. Has that been abused? Sometimes. Unfortunately you don’t get the value without the visibility. Exactly how much visibility is the right amount will always depend on company, culture and comfort level.

The other downside is that POSIWID will bite back, because a system trained on yesterday’s decisions is most likely to repeat them. That, in itself, may be useful as a mechanism for keeping a standard. But it won’t be sufficient, since the work of design has always included navigating the tension between keeping the standard and breaking it. The machine can do the former, but is hard-pressed to do the latter.

An answer, maybe?

All this brings us back to the original question. If readiness is a promise, then here’s the one promise I think is worth making: a design system is AI ready when it can accommodate AI in the designer’s role without the quality floor sinking, and when the team has decided—on purpose, not by accident!—which parts of the ceiling still need a human holding them up. I don’t see a version of this where humans are left out of the system. The question of AI readiness was never whether humans could be completely pulled out of the loop, but rather where in the loop we should remain.