In brief: Our design system holds far more than reusable components. We documented it in structured MD and MDX files so an AI could reason about it as well as use it. Four properties made it unambiguous to a machine: tokenized styles, semantic component names, built-in accessibility, and branded, reusable components. With that foundation in place, our designers could design almost entirely through AI.
This is the third article in our series on AI-accelerated design inside a large life sciences program. Part two showed how we cut a design cycle from four weeks to just over one. Part three goes under the hood, into the design system that let us design almost entirely through AI.
Every bit of that speed depended on a design system engineered for machines as well as humans, and engineered for a machine to reason about, not only to use. Our design system is more than a library of reusable components. It is a machine-readable knowledge hub that holds components, foundations, patterns, templates, tokens, and usage guidance. Other practitioners ask me about this piece more than any other, so this article gets specific about what we did.
Components and patterns do different jobs
Those categories are not all the same kind of thing, and one difference shapes everything that follows. Components are the individual building blocks in the library, such as a button, a table, or a search box. Patterns are proven arrangements of those blocks into a complete solution, such as a full data-table screen with search, sorting, and empty states already worked out together. Because we document patterns as their own category, separate from components, an AI can reach for a validated whole before it assembles the parts one by one.
Why AI needs a design system it can reason about
Most design systems are built for people. A human designer can look at a slightly inconsistent component, work out what was meant, and move on. Told to use the “blue button,” a human knows which blue. People fill gaps with judgment.
An AI can’t fill those gaps the same way. Where a human designer would stop and ask for more detail, an AI keeps going and quietly substitutes its best guess. The result still looks finished, and that is the problem: mistakes travel through design looking correct. For AI to help generate real interfaces, it has to understand the design rather than copy it. So the system must state its meaning explicitly, in a form a machine can read without ambiguity, because a machine will do exactly what the system tells it and nothing more.
Think of the difference between building with LEGO and carving from clay. Molding clay lets a single artist shape anything they can imagine, but every piece is one-off and fragile, and only the sculptor knows how it fits together. LEGO bricks are consistent and snap together predictably. You can hand the set to anyone, including a machine, and they will build the same model every time. We set out to make our design system a LEGO set.
How MD and MDX files make a design system machine-readable
We captured the whole system as design system documentation in structured MD and MDX files. Both are plain-text formats that people and machines can read.
MD (Markdown) files hold the written rules: a component’s purpose, when to use it, its accessibility requirements, and its do’s and don’ts, all in text an AI can parse directly.
MDX files take this further by pairing those written rules with live, working examples of the actual components. The same file is readable by our designers and usable by AI. It also gives the AI agents that build alongside us the explicit context they need to reason about the design system, instead of interpreting pixels or filling gaps with assumptions.
Together, these files make the system’s purpose, usage rules, variants, tokens, accessibility requirements, and do’s and don’ts explicit, so humans and machines work from the same source of truth.
Four properties that remove the guesswork for AI
Within that documentation, four properties carried most of the load. We chose each one to make the system unambiguous to a machine.
Tokenized styles. Every color, spacing value, and type choice is defined as a named token with a single source of truth. “Primary blue” is one defined thing, referenced everywhere, instead of a hex code retyped from memory. People benefit from this. Machines depend on it, because tokens remove the guesswork that would otherwise produce a dozen almost-right blues.
Semantic component names. We name and structure components by their purpose rather than their appearance, so a component is called “Primary action” instead of “blue button.” For an AI, this makes intent readable. Asked to build a confirmation step, a machine can choose the primary action correctly, even if the brand color changes tomorrow.
Built-in accessibility. Accessibility is engineered into the components themselves, so it is a starting condition instead of a cleanup task at the end. When the building blocks are accessible by default, everything assembled from them inherits that, including everything an AI generates.
Branded, reusable components. One set of on-brand building blocks is defined once and reused everywhere. Consistency comes automatically, and the whole system can shift by changing the source instead of editing a thousand screens.
What a machine-readable design system made possible
Combined, these four properties give you a design system an AI can use correctly, so AI-generated designs arrive without invented colors, misused components or quietly dropped accessibility. We kept the machine from guessing by removing the need to guess.
This is what made the leap in our acceleration story possible. Once the design system reached this level of maturity, our designers could design almost entirely through AI, because the AI was working from building blocks it could understand and, more importantly, couldn’t misuse. The system carried the correctness, which left our designers free to think.
In an AI-accelerated practice, a machine-readable design system is the foundation everything else stands on. Without it, designing with AI means constantly correcting a machine that is guessing. With it, the machine becomes a real collaborator.
Next in the series: the team of specialist AI agents we built on this foundation.
Frequently asked questions
It is a design system whose meaning is explicit enough for AI to reason about, not only for people to use. Ours holds components, foundations, patterns, templates, tokens and usage guidance, all documented in structured MD and MDX files so designers and AI work from the same source of truth.
A human designer fills gaps with judgment, but an AI fills them with its best guess and keeps going. Because the output still looks finished, those mistakes move through design looking correct. A machine-readable system removes the need to guess rather than correcting the guess afterwards
Components are individual building blocks, such as a button, a table or a search box. Patterns are proven arrangements of those blocks into a complete solution, such as a data-table screen with search, sorting and empty states worked out together. Documenting patterns separately lets an AI start from a validated whole.
MD files hold the written rules for each component, including purpose, usage, accessibility requirements and do’s and don’ts. MDX files pair those rules with live, working component examples. Both are plain text, so AI agents read the design system directly instead of interpreting pixels.
Design tokens are named definitions for every color, spacing value and type choice, each with a single source of truth. Together with semantic component names, which describe purpose rather than appearance, and accessibility built into the components themselves, they stop a machine from guessing.
