👋 Get weekly insights, tools, and templates to help you build and scale design systems. More: Design Tokens Mastery Course / YouTube / My Linkedin
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 and check if you can have fewer variants, what you can optimize, etc.
→ Check the code and 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.
→ 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.
→ What’s up with accessibility? Dig in and make a report.
→ 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 the 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 (my plugin): 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 loooong 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. If you need inspiration on how others do it, 🔗 check my database of design systems and explore them.
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. I already wrote about this, so you can read a detailed article.
4. Semantic binding rule
Components need semantic or component tokens (depending on your design token logic). If you use color.action.primary for all primary actions, agents will know this token is used across themes for every primary action.
But be careful. Also define scopes. Sometimes I find border design tokens applied to background, text on icons, and so on.
5. Decision log
The decision log is 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). Write what happened that day, why, who was involved, and date it. So next time someone wants to change a dialog design, you have a decision and a reason why it’s not a good idea (for example).
This also creates timestamps for understanding analytics better.
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. If not, you still have plenty of options to make it work. I use my own Tidy MCP (you can get Tidy Core here). There is also an unofficial Figma Console from TJ. The next step is setting up a pipeline that turns variables into CSS variables (Style Dictionary or your own script).
7. MCP
I already wrote about the knowledge graph, so I will only share the basics here.
If you haven’t yet, first connect either Figma MCP, Tidy Core, or Figma Console to the repo. Then start by adding other MCPs. I use Granola, GitHub, PostHog, … Add whatever is SAFE. Do not share info that is not allowed inside the org.
Do not forget to connect your .md files. You also need to feed CLAUDE.md with your rules. We call that your agent’s harness.
#4 Respect devs, because they know their sh**
Just last month, a product manager opened 114 PRs. Wow, let’s give him a high 5. NOOO! Not just that. Development teams got around 60% more PRs than in a record month last year. And who reviews those [N] PRs? And when?
I know we all love self-initiative people and ideas. But 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. You do not want this. Ever.
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. And again, instead of talking about improvements, we start talking about what should be there in the first place, what the initial problem was, and how components should be used.
That is step one, c’mon.
#4 Collaborate, talk, discuss
Not long ago, kick-off meetings, longer (UX) sessions, and weekly reviews were totally normal. Today we are only talking about speed. “Okay, so this can be done by tomorrow?”, “Just ask AI!” Okay, the benefit is that we finally realized longer meetings serve no one, but that doesn't mean we should skip them entirely.
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. Feels insane. 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. Who is measuring this??
Change is the only constant, but not in UI.
I know there is a tendency to say, “it can be reverted fast,” but users aren't ready to play with your UI experiments every day. Consistency exists for a reason.
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. It’s way easier and faster to prioritize user problems and improve them. And yes, this is how I imagine integrating AI for the UX.
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.
You know how the famous saying goes: “Trust me, I’m a designer. “😅
Enjoy exploring 🙌
PS. Would love to hear your stories about emerging PR’s :)
The distinction between making a design system machine-readable and making it actually useful to an agent is important.
Tokens, component descriptions and documentation give an agent information, but the decision logs, semantic rules and governance provide the context for how that information should be used.
Otherwise you can end up with an AI that has access to the whole system but still has no idea which constraints are actually important.