Foundations maxxing: Why your design system is not ready for AI

As soon as you start with AI, it feels like crushing a piñata on the first punch. Especially if you skipped the early versions of ChatGPT and got disappointed when something didn’t work. Any of your non-coder coworkers can literally get from Figma to working prototypes in minutes. So why do you feel a little sarcasm in my writing?

Because you focus too much on having a “machine-readable” design system and skip everything that should happen in between. That’s why I am foundations maxxing.

Let me explain how and WHY.

What do I even mean by foundations maxxing?!

Instead of spending a crazy amount of tokens (credits), let’s focus more on what our foundations are. Running wild and spending tons of tokens doesn’t mean you will create a scalable product. Without a strong foundation, you can't scale. Even if you find your perfect workflow, does it lead to a scalable product if the ground stays shaky?

#1 Your design system is infrastructure

I want to set one thing straight. A design system is infrastructure. I see it as the API that allows AI to build your products safely. The same way your CI/CD pipeline is infrastructure. The same way your database is infrastructure.

When anyone can generate a screen or app, the only thing that sets you apart from your competitors is the system behind it. Yes, the whole combination of brand, consistency, uniqueness, and so on.

Plus, let’s not forget that a design system directly supports business outcomes. Just developing a single page or screen becomes at least 50% faster with a design system than coding from scratch. Rules and guidelines for building with AI will speed everything up even more. So, to sell it to leadership, it is much easier to frame it as infrastructure.

#2 How I audit a design system in 2026

Before you even think about making your design system machine-readable, you need to do an audit. I know, it is boring; it takes time, but it will give you insights you've never thought of.

My process:

• Go through libraries: Check design tokens (Figma variables). Dig in for hidden layers, applied tokens, raw hex colors. Check whether scopes are applied correctly and whether any unwanted layers, variables, or themes show up in Figma.
• Review components: Check if you can have fewer variants, what you can optimize, etc.
• Check the code: Compare hard-coded stuff. Use linters.
• Read the docs and decisions: Read .md files, use them, compare results. Are there any useful machine-readable docs? What is there? You can use them as a starting point for your knowledge graph.
• Team distribution: How are things shared across the teams? How are others designing and using AI? What’s their process and tech stack? This step is especially important if you work in large companies where each team tends to have its own processes.
• Accessibility: Dig in and make a report.
• Workflows: Review the design <> development workflows and governance.

You can also start by pointing an agent to your Figma file, docs, or code and let it compare, count the drift, find detached components, ... and then, after you get a report, you can decide and prioritize what to fix first.

Send out a survey to get the pulse from different teams. Include developers, product design, and the design system team. You need to hear different perspectives.

Useful tools

I use a variety of tools, but these are my most used:

• Playwright: screenshots your product in every state; it’s free.
• Figma MCP: connect Figma with your AI tool and share everything about variables, components, descriptions.
• Tidy Core: finds detached instances, ghost variables, naming, Figma-to-code parity.
• Claude Code, Cursor or any other AI tool for building.
• GitHub MCP: reads code.
• Storybook: your library of all the components.
• Style Dictionary: reads the pipeline.
• PostHog MCP: reads usage.

Checklist before you connect an MCP

The audit report should fit on one page. Add straight-to-the-point observations that serve as a checklist for next steps. Nobody will read a long report, everyone just wants to know "what's next!".

#3 Time to fix or prepare the foundations

1. Set up design token naming structure: A useful tool here is Name Design Tokens Builder. You can also use AI tools like Cursor or Claude and create a set of tokens based on your preferred naming structure.
2. Add descriptions to your components: You can do it manually or kick-start this process with AI. Just prompt it: “add descriptions to my Figma files”.
3. Create .md files: Describe the components, variants, usage, and relationships between them. Include everything agents need to know, and anything helpful for building screens.
4. Semantic binding rule: Components need semantic or component tokens. If you use color.action.primary for all primary actions, agents will know this token is used across themes for every primary action.
5. Decision log: A document with all your tiny decisions about what you chose instead of X. Keep it short, straight to the point, and share it with your agents in your folder (ideally knowledge graph).
6. Pipeline to code: You need to connect your Figma to your code. If you have an Enterprise plan, it is much easier, since the API exposes Figma Variables directly.
7. MCP: If you haven’t yet, first connect either Figma MCP, Tidy Core, or Figma Console to the repo. Then start by adding other MCPs. Do not forget to connect your .md files. You also need to feed CLAUDE.md with your rules.

#4 Respect devs, because they know their sh**

Just last month, a product manager opened 114 PRs. Development teams got around 60% more PRs than in a record month last year. They were not trained as UX designers; they don’t have years of experience, not in design, nor in testing. They don't know how design systems work and usually skip existing components because they feel restricted. What happens next is that you put all the pressure on developers, who then become cleaners and have to review all the PRs. Instead of focusing on quality code, they review lines of gibberish.

#4 Collaborate, talk, discuss

I see skipping meetings as a shortcut to using only AI. Product is people. By skipping discussions, the collaborative part of building the product, you are also skipping the needs of people. AI is capable, but it does not know or can’t predict things that you and YOUR USERS experience along the way.

#5 UX first, UI second

Imagine people who have never worked with user experience and have no prior knowledge can now create apps, screens, decide, and prioritize content. Instead of making UX better and better, you end up arguing who is “more” right. So all the time gained with AI is suddenly lost in explaining UX 101 and design principles.

Change is the only constant, but not in UI.

I don’t want to pretend AI isn't useful for user experience. IT IS! You can use AI to get feedback from multiple streams in seconds. Connecting analytics tools, support tools, and just using MCP or API to get metrics in real time feels like a superpower.

Time to do it yourself

Every story I shared today has one thing in common: People who are SKIPPING the steps. So the next time your super enthusiastic “no-code builder” creates a PR introducing shitty new styles, just send him this article. Engage with your team and strive for constructive discussions. Soon, you should see the gaps.