Design systems are the foundation AI builds on.

Everyone is asking the wrong question

Right now, the loudest question in design is some version of how do I get AI to generate my product. People want to type a prompt and watch a full interface appear. They want screens, flows, whole apps, out of thin air. And the tools are good enough now that you can actually do this. You can point an AI at a blank canvas and get something that looks like software in seconds.

Here is the part nobody wants to hear. That is the easy part. The quality of what comes out has almost nothing to do with the prompt and almost everything to do with what the AI had to draw from. If you give it a clean, well-built design system, you get work that looks like you and fits together. If you give it a folder of one-off screens that never agreed with each other, you get a faster version of the same mess you already had.

So the real question is not how do I get AI to design my product. The real question is whether my system is good enough to be worth copying. Because copying is exactly what the AI is going to do.

AI generates from patterns, not from taste

I have spent 15 years leading and doing design. Hands on, in the file, not just pointing at a roadmap from a corner office. And the thing I keep coming back to is that AI is a pattern machine. It looks at what exists and it produces more of that. It does not have taste. It does not have a point of view about your brand. It has your examples, and it averages them.

This matters more than people think. When you ask an AI to design a settings page, it is not inventing your settings page from first principles. It is looking at what a settings page tends to look like, and if you have given it your own components and your own rules, it is looking at how you do settings pages. The closer your examples are to a tight system, the closer the output lands to something you would actually ship.

A pile of inconsistent screens teaches the AI inconsistency. Three different button styles in your product become three different button styles in the generated work, plus a fourth one the AI made up to split the difference. The model is not going to fix your mess. It is going to learn from it, and then it is going to produce more of it at a speed you cannot keep up with.

This is the whole game. AI does not replace your design system. It raises the price of not having a good one.

Your system just changed jobs

For most of my career, a design system had one job. It kept things consistent. It was the thing you maintained so that twelve designers and forty engineers did not each invent their own version of a dropdown. It was a discipline you imposed on a team, and the payoff was a product that felt like one product instead of forty.

That job has not gone away. But the system picked up a second job, and the second job might be the bigger one now. Your design system is now the source of truth that the AI draws from. It used to be the output you protected. Now it is also the input you feed in.

Think about what that shift means. A system used to be valuable in proportion to how many people followed it. Now it is valuable in proportion to how good it is as raw material for a machine that generates at scale. A messy system used to slow down a team. A messy system now poisons every single thing the AI makes on top of it. The cost of a bad system did not stay the same. It went up, and it went up a lot.

I think a lot of teams are about to learn this the hard way. They will buy the AI tools, they will point them at their existing design debt, and they will be confused about why the output feels off. It feels off because the foundation was off, and now the foundation is being copied a thousand times a day.

What good actually looks like

When I talk about a good system, I am not talking about a giant component library with a thousand variants nobody uses. I am talking about a small, tidy set of components, a clean set of tokens for color and spacing and type, and a clear set of rules for how things go together. Tokens are the part people skip, and they are the part that matters most for AI. They are the named, reusable decisions. This is the spacing scale. This is the color for a primary action. This is the type ramp. When those decisions are named and consistent, the AI has something solid to grab. When they are not, it guesses, and it guesses differently every time.

Good also means the system is honest. The components in the file match the components in the code. The rules that are written down are the rules people actually follow. A system that lies, where the documentation says one thing and the real product does another, is worse than no system, because now you are feeding the AI a confident, well-organized version of the wrong answer.

And good means opinionated. A system that tries to do everything ends up saying nothing. The best systems make choices. They say this is how we do empty states, this is how we do errors, this is the one way we handle a primary button. Those choices are what give the generated work a point of view. Without them, the AI defaults to the blandest average of everything it has ever seen, and your product comes out looking like every other product.

The Kinjo proof

I watched this play out years before AI generation was even on the table, and it is the clearest example I have of why the system is the thing. For Kinjo we needed to launch two iOS apps, and we needed to do it fast. The obvious path would have been two teams, two sets of components, two of everything. We did the opposite. We built one shared design system and launched both apps off it.

The speed was not magic. The speed came from the fact that once the system existed, most of the decisions were already made. A new screen was not a blank page. It was an assembly job. Grab the components, follow the rules, ship. The second app was faster than the first because the system was already paying us back. We were not designing screens anymore. We were composing them from parts we trusted.

That is the exact discipline that makes AI generation usable today. When I tell an AI to build a screen now, the experience is the same as what Kinjo felt like, just faster and more of it. If the parts are good and the rules are clear, building is composition, not invention. The system did the hard thinking up front, and everything after that is assembly. AI did not create that advantage. It just turned the volume way up on a system that was already good, the same way it would turn the volume way up on a system that was bad.

I have seen the expensive version of this

I led an AI-first transformation inside a multi-billion-dollar design org, the kind of place with a B2B side and a B2C side and design systems work spread across both. At that scale, the math on a bad system is brutal. Every inconsistency is not one bug. It is a pattern that gets reproduced across hundreds of surfaces, and once you put AI on top of it, it gets reproduced faster than any team can clean up.

What that experience taught me is that the transformation people imagine, where you flip on AI and everything gets faster, only happens if the foundation is ready. The orgs that win are not the ones with the fanciest AI tools. They are the ones whose system was already clean enough that the AI had something good to copy. The tooling is roughly the same for everybody. The foundation is the part that is different, and the foundation is the part that decides the outcome.

I have also built this from zero. With Story Genie I run an agentic production pipeline, where a lot of the work is generated rather than hand-placed. That only works because the system underneath it is tight. The patterns are clear, so the generation stays on the rails. The day the system gets sloppy is the day the output gets sloppy, and you feel it immediately. Generation is a magnifier. It makes a good foundation look great and a weak foundation look broken.

What this means for how you build a team

This changes the work, and it changes who you hire and what you ask them to do. The job is shifting from drawing every screen by hand to building and tending the system that everything else gets generated from. That is a different muscle. It is closer to designing the rules than designing the pixels. I have written more about what an AI-first design process actually looks like day to day, and about what it takes to build a team built for AI speed, because the org chart and the workflow have to change too, not just the tools.

But it all routes back to the foundation. A team built for AI speed that is sitting on a broken system is just a team that produces broken work quickly. The system is the leverage point. Get it right and everything downstream gets easier. Get it wrong and you have bought yourself a very fast way to make the same mistakes at scale.

The instinct to chase the generation tools is understandable. They are the shiny part. They are the part that demos well. But the team that wins is not the one with the best prompt or the newest model. It is the one whose system gives the AI something good to generate from.

How to audit your system the way AI reads it

Here is a job you can run this week. Sit down with your design system the way an AI would read it. Not as the person who built it and remembers the intent, but as a machine that only sees what is actually there. The AI does not know what you meant. It knows what you wrote down. So the audit is simple. Go find every place where the file says one thing and the truth is another. That gap is where AI will copy your mess and hand it back to you faster than you can clean it up.

Start with components. Open your library and count how many ways there are to do the same thing. How many button variants exist. How many cards. How many input fields. If you find one button with clear states, you have a system. If you find nine buttons that are almost the same, you have a museum of old decisions. AI will treat all nine as valid, because nothing tells it which one wins. The fix is consolidation. One component, real variants, clear names. Fewer choices, each one correct. That is what gives the machine something worth copying.

Now check your tokens. A token is a named decision, like a color or a spacing value or a type size. The question is not whether tokens exist. The question is whether they are used everywhere. Pick a screen and inspect it. Are the colors pulling from named tokens, or are there raw hex values hand typed into the corners. Are the gaps built on your spacing scale, or did someone nudge it to thirteen pixels because it looked right that day. Every raw value is a place where AI learns that the rules are optional. Tokens that are named but not used are worse than no tokens at all, because they promise order and do not deliver it.

Then do the hardest check. Put the design file next to the shipped product and compare them screen by screen. This is where most systems fall apart. The file shows the clean version. The live app shows what really happened under deadline. If the two do not match, your system is fiction, and AI built on fiction produces confident nonsense. You do not need both to be perfect. You need them to agree. When they disagree, decide which one is right and make the other one follow. That single act of alignment is worth more than a month of new components.

Read your rules out loud and ask if they are opinionated or wishy-washy. A good rule says use this, not that, and here is why. A weak rule says consider using, or prefer when appropriate. Soft language is the enemy here. AI cannot act on a maybe. It needs a yes. Every place your documentation hedges is a place the machine will guess, and it will guess toward the average. If your system is full of suggestions instead of decisions, the AI output will feel generic, because you taught it to be.

Finally, go hunt the drift. Drift hides in the boring places. The old marketing page nobody updated. The settings screen three clicks deep. The one flow that a different team shipped on their own. Drift is not loud. It accumulates quietly while everyone looks at the homepage. Walk the edges of your product, not the center, and write down every spot where the system slipped. By the end of the week you will have a real list. Not a feeling that things are messy, but a map of exactly where. Fix the top five. Then you have something an AI can build on, and so can you.

Before you ask how to get AI to design your product, ask whether your system is good enough to be worth copying. Because that is exactly what the AI is going to do.

Start with the foundation

So here is where I would put your energy. Not on the prompt. Not on picking the perfect tool. On the foundation. Audit your system the way an AI would read it. Are the components consistent. Are the tokens named and clean. Do the rules say something, or do they hedge. Does the file tell the truth about the product.

If the answer is yes, AI is going to feel like a superpower, because it will take your good system and run with it. If the answer is no, fix that first. The work you do on the foundation is the work that makes everything else possible. It always was the highest-leverage thing in design. AI just made it the only thing that matters.

Everyone wants AI to generate their UI. Fine. Let it. Just make sure that when it looks at your work to figure out what to make, it finds something worth copying. Build the foundation. The AI builds on top of it. That order never changes.