I see a lot like this on the internet. Someone feeds a handful of screens into an AI design system tool. A few seconds later, out comes a color palette, a type scale, a row of buttons, some badges, a checkbox, a couple of tabs. The caption is always some version of the same sentence: "We just built our entire AI-generated design system in five minutes."
In a world where AI is reshaping the industry, posts like these are meant to show how powerful these tools have become. And they are powerful. But what these posts actually reveal isn't the strength of AI. It's how little our industry has ever agreed on what a design system is.
Because if a palette and a few generic components count as a design system, then we've been fooling ourselves for the last decade. And honestly, a lot of us have been.
A decade in, we still don't have a shared definition
Design systems have been an industry standard for years. Conferences, books, dedicated job titles, dedicated teams, dedicated tooling. Whole startups built around documenting them. And yet a tool that produces five colors and seven components can be called "a design system" or "a design system for AI" on LinkedIn.
The reaction tells you what most people think a design system is: a kit of parts. Tokens plus components. A library you pull from. A swatch sheet with a button next to it.
But anyone who has actually built one knows that's not the system. The kit of parts is the output. The system is everything that decides what goes into the kit and how it gets used — the patterns, the rules, the rationale, the governance, the decisions about how this product, specifically, behaves for the people who actually use it.
A design system isn't a design artifact, but an organizational one. The components are what you can see, whereas the system is what produced them.
What AI tools actually do well
The current generation of AI design tools is genuinely impressive. They can draft first-pass copy (specifically useful for not native speakers), create images, turn a component into functional code, generate design variations for exploration work, automate the repetitive and mechanical work.
These are real capabilities, and they're going to keep getting better. The teams using them well are shipping faster than they ever have. None of what follows is an argument that AI tools don't belong in design work. They do.
What I want to push back on is a much narrower claim — the claim that these tools have built something, when what they've actually done is extracted something. They've solved the easy half of the problem.
The artifact layer and the pattern layer
The easy half is artifact extraction. Pull tokens out of a Figma file, generate a button component, recognize a card pattern, output it as code.
And even at this surface layer, most teams aren't getting it right — hardcoded values pile up as visual debt at machine speed, and AI compounds the problem faster than humans can review it.
This is real work, and it's the work AI does well, because the artifacts are right there on the surface, structured, named, exportable. Claude Design, Cursor, v0, Lovable, Figma Make — they're all reaching into the same layer and pulling out the same things. Tokens, components, a type scale.
What they can't reach is the layer underneath. The layer that decides:
- When does this product use a modal versus a side panel or drawer, versus a new page?
- What does an empty state look like in this product, given how this product is used and who uses it?
- How do we communicate that something is loading versus stuck versus failed?
- What's the difference between a confirmation, a warning, and a destructive action in our voice?
- When does an action belong in a primary button, an overflow menu, a contextual menu, a keyboard shortcut?
- What happens to a list when it has zero items, three items, three hundred items, three thousand?
- How the nav bar should be structured and transform on mobile or tablet?
- Where to put labels and not badges?
- What information should a table emphasize to avoid overwhelming users?
They're product questions, not the component ones. And the answers to them — the ones that make a product feel coherent rather than assembled — almost never live in a Figma library. They live in patterns, documentation, Slack threads, Confluence. In the heads of the three senior designers who've been there long enough to remember why we decided to do it that way.
The artifact layer is what you can extract. The pattern layer is what makes your product yours.
What AI design system tools actually produce
Once you see this distinction, every "AI built our system" post starts looking the same. The output is always recognizable. It's a button that's the right color, sitting in an interface that could belong to anyone.
The components are technically correct. The badges are present. The tabs work. The spacing is consistent. And yet the product feels like it was assembled from a pattern library someone bought online — because in a sense, it was. It was assembled from the pattern library that lives inside the model, defaulted to wherever the training data has the most density. Generic SaaS dashboard. Generic settings page. Generic empty state with a generic illustration of a generic person looking thoughtfully at a generic chart.
We've all seen this. We've all shipped this, on bad days. The reason it happens isn't that the AI is failing. It's that we gave it the artifact layer and asked it to invent the pattern layer, and the patterns it invented are the patterns it sees most often, which are the patterns of every other product.
Why this matters more now than it did a year ago
Here's the part that I think doesn't get said enough.
For the last decade, having an undocumented pattern layer was a problem, but it was survivable. New designers learned the patterns by sitting next to senior designers, by getting feedback in critique, by having someone catch the inconsistency in PR review. The pattern layer existed; it just lived in human heads. Onboarding was slow. Inconsistencies crept in. But the product mostly held together, because human designers absorbed the rules even when they were never written down.
That grace period is over.
AI doesn't sit next to anyone. It doesn't go to critique. It doesn't have the lunchtime conversation where someone says "yeah, we tried that two years ago and it didn't work because of X." It can only reason about what you give it. And most teams, even teams with mature design systems, have given it the surface — because the surface is what they had documented.
So when you point an AI tool at your design system and ask it to build a new feature, the tool doesn't fail by producing nothing. It fails by producing something. It invents whatever it doesn't have, and it invents it generically. And it does this fast. It does it at the speed of every other team's "AI built our design system" post.
Pre-AI, the cost of an undocumented pattern layer was slow onboarding. Post-AI, the cost is shipping a generic product at scale, every day, in every feature your team builds with these tools. The work that used to live in heads has to live somewhere a model can read it, or it might as well not exist.
That's why the title of this piece is what it is. AI doesn't replace your design system. It makes you need one — a real one, not a kit of parts — urgently.
The accidental gift
I want to put this generously, because I think it matters: this isn't really a story about AI exposing something we didn't know. We always knew. Every design system team I've ever worked with has known that the pattern layer mattered more than the components. We just didn't write it down.
Why didn't we? Because writing patterns is invisible work. Components ship. Components get demoed. Components get stars on a Figma library page. A page of well-considered guidance on when to use a side panel doesn't show up in any of those metrics. It shows up six months later, when a new designer joins and ships something coherent on their first sprint, and you can't quite explain why it went so well.
So we shipped components. We shipped tokens. We told ourselves we'd write the pattern layer "next quarter," every quarter, for years. Some of us managed parts of it. Most of us didn't.
AI is, accidentally, the forcing function. Not because the technology is magic, but because the alternative — a model inventing your patterns for you, generically, fast — is now an actual product risk that leadership can see. The pattern layer has finally become legible as an investment, because not having one has finally become legible as a cost.
That's a gift, even if it doesn't feel like one. The work we always wanted to do is now the work the business can finally see needs doing.
What a design system has to be now
A design system in this era has to do more than it used to. It has to:
Carry the pattern layer, not just the artifact layer. When to use a modal versus a side panel. When to use a destructive confirmation versus an undo. How errors behave. How empty states behave. How loading behaves. How responsive breakpoints behave for your users on your devices. The decisions, written down, with rationale, in a form a model can read.
Be governed. Patterns drift. Decisions get re-litigated by every new hire. Without governance, the pattern layer becomes the same kind of folklore the components used to be — true if you talked to the right person, false if you didn't.
Be authored collaboratively. The pattern layer doesn't come from one designer. It comes from designers, engineers, PMs, support, sometimes legal. A system that can only be written by one team will only contain what that team knows.
Behave like a living system, not a snapshot. A PDF with last year's guidelines is worse than nothing, because it gives a model confident-sounding answers that are no longer true. The pattern layer has to evolve with the product, and it has to do so in a place models and humans both read.
This is tool-agnostic. Whoever provides the substrate that lets you do this — zeroheight, a competitor, a homegrown internal tool, a structured set of Markdown files in your repo — is doing the work that matters. The shape of the answer is what counts, not the brand on it.
How the work shifts for design system teams
Which means the job changes, too.
For most of the last decade, design system work has been heavily artifact work. Build the component. Document the props. Maintain the Figma library. Sync the tokens. Triage the bug. Repeat.
That work doesn't disappear, but it stops being the high-leverage part of the job. AI eats the artifact work first, because the artifact work is the most structured, the most extractable, the most repetitive. The high-leverage work moves up a layer. Design system teams will likely focus more heavily on:
- Defining system architecture and structure — the schema patterns live in, the relationships between them, how they reference tokens and components
- Aligning systems with product strategy — making sure the patterns you encode actually reflect where the product is going, not where it was
- Building internal tooling and automation — not just consuming AI tools, but building the infrastructure that lets your team's AI tools reason about your product specifically
- Maintaining governance and long-term evolution — keeping the pattern layer accurate as the product changes, the way platform teams keep dependencies up to date
In short, the work shifts from producing every artifact manually toward designing the framework that lets those artifacts get produced correctly, by humans and models both. The system is no longer the kit of parts. The system is the thing that decides what belongs in the kit, and what doesn't, and why.
So, where does that leave us
The AI tools are here, and they're not waiting for us to catch up. They're going to generate something either way. The question isn't whether your team uses AI in design and engineering work — they already do, or they will by the end of the year. The question is whether what they generate looks like your product, or like a stranger wearing your logo.
That distinction lives almost entirely in the layer above the components — the layer most teams have never written down, because before AI, they didn't have to. Before AI, it lived in the heads of senior designers and the muscle memory of long-tenured engineers, and that was enough to keep the product coherent.
It's not enough anymore.
The teams that win the next few years aren't going to be the ones with the prettiest component libraries. They're going to be the ones that wrote down the decisions that produced their components — and made those decisions readable, governed, and alive.
A design system for AI, finally, is going to have to be what we always claimed it was: not a kit of parts, but the memory of how this product is built.
Prompts are instructions. Design systems are memory. And AI is, for the first time, making the industry act like that distinction matters.
Read next
AI-generated UI consistency: what breaks when you skip tokens
If the pattern layer is what makes your product yours, tokens are what keep the surface from drifting. Every hardcoded value is a small debt — and AI accumulates it faster than anyone can review.
