In the same week, two teams each build a screen with an AI coding assistant. One builds the order list, the other the customer profile. Both work, and each looks "right" on its own. Put them side by side, though, and they look like products from two different companies: different shades of blue, different button heights, different spacing. You have a design system, but the AI isn't using it.
Short answer: Give an AI agent a rules file and it will follow those rules most of the time. Give it a design system that lives in code and it uses the system; it doesn't make things up. That's why the way to prepare a design system for AI is to separate it from the brand, turn it into a neutral core, and keep it alive and evolving in a repo.
Where does design happen now?
For years, design systems lived in Figma. Components were drawn there, color styles were defined there, and the development team "translated" them into code.
Production works differently today. Design increasingly happens directly in code, with AI tools. Instead of drawing a screen and handing it over, a designer builds it with real components, in the browser, together with an agent. That changes where the design system belongs: it has to live where screens are actually made, which is in code.
Figma doesn't disappear. It's still a great tool for exploration, quick sketches and visual discussion. But it's no longer the source. The source is the repo.
A rules file or a system in the repo?
Rules files like design.md are often presented as the way to make AI follow a design system. They're useful, but they have a limit worth being honest about.
A rules file is probabilistic. The agent reads it and tries to follow it, and most of the time it does. But AI agents don't apply rules files like design.md 100% of the time. You can write "the primary button appears once per page", and in the middle of a long task the agent may still add a second one. A rule points the way; it doesn't guarantee anything.
A design system in the repo is deterministic. When the system lives in code as real components, tokens and types, the agent doesn't guess; it imports and uses them. If the Button component only accepts its defined variants, the agent can't invent a third. If colors are defined as tokens and code review rejects hard-coded color values, the wrong blue can't reach the screen. An AI agent reads the design system in the repo as it is; it doesn't make things up.
The difference: a rules file tells the agent what it should do. The system in code sets what it can do. One is advice; the other is the floor.
Think back to the two teams in the opening. They had the same rules file, and the agent interpreted it two different ways in two different tasks. Had both teams built their screens from shared components in the repo, the order list and the customer profile would have used the same button, the same blue and the same spacing, because both would have imported the same code.
So design.md's place is as one of the files inside the repo: it explains why the system is built the way it is, and covers things like voice that can't be expressed in code. We cover the file itself in what is design.md. But the guarantee comes from the system in code, not from that file.
Why separate your design system from the brand?
In an enterprise project, the design system is usually born tangled up with that project's brand. Buttons are in the brand's color, corners have the brand's radius, copy is in the brand's voice. When the project ends, the system is locked to that brand. The next product, or another company in the group, has to copy and rework it, or start from scratch.
The best thing you can do as a designer is to separate the project's design system from its brand elements, make it neutral, and keep it alive and evolving in a repo.
That separation means two layers:
| Neutral core | Brand layer | |
|---|---|---|
| What it holds | Components, interaction patterns, states (loading, empty, error), spacing and grid logic, accessibility rules | Colors, typography, logo, voice, imagery |
| Where it lives | A shared, versioned repo | Each brand's theme files |
| Who changes it | A small group representing every brand | That brand's design lead |
| How often it changes | Slowly, through review | As the brand needs |
The neutral core describes how a product works. The brand layer describes how it looks and speaks. Once the core is built right, the brand goes on top as a theme.
What do large companies gain?
New products don't start from zero. A new product in a group of companies takes the shared core and writes its own theme. Tables, forms, filters, notifications and the other components every product repeats are already built and already tested.
Consistency comes for free. Because every brand uses the same components, behavior is the same.
Design and development look at the same source. The component the designer sees on screen and the component the engineer imports are the same file.
Every project grows the system. A component added in one project that fits the core becomes available to everyone in the next. The system stops being a project deliverable and becomes a company asset.
AI works correctly for every brand. When the agent builds a screen for a brand, it uses the same core components; only the theme changes. The risk of picking the wrong color largely disappears, because the theme chooses the colors, not the agent.
What does a system living in a repo look like?
For a fictional system called "Atlas", a typical layout might look like this:
atlas/
├── core/ ← neutral core, brand-independent
│ ├── tokens/ ← spacing, grid, radius, shadow scales
│ ├── components/ ← Button, DataTable, Form, Toast ...
│ └── patterns/ ← empty state, error, loading
├── themes/
│ ├── brand-a/ ← color, typography, logo
│ └── brand-b/
├── docs/
│ └── design.md ← voice and reasoning
└── CHANGELOG.md ← what changed in each version
File names vary from team to team; three principles matter:
- The core knows no brand. A core component never says "navy"; it says "primary color". The theme provides the value.
- Components carry their own limits. Which variants a component accepts is defined in its types.
- The system is versioned. Every change ships with a version number; products know which version they use and decide for themselves when to upgrade.
How do you prepare a design system for AI in four stages?
We do this work with an AI native process. AI native means a studio that builds AI into every step of the process. Here's how the four stages adapt to a design system.
Discover. AI scans the existing screens and codebase and lists inconsistent colors, duplicate components and naming differences. The team decides which differences are deliberate and which are accidents. The gain: the system's real state becomes visible. We explain how this scan works in how to do UX/UI analysis with AI.
Define. The team decides which parts of the system belong to the core and which to the brand. AI scans the components and flags brand-bound values; the team makes the final call on the split. The gain: a plan for a reusable core that's independent of any brand.
Deliver. The core moves into a repo and is defined in code as components, tokens and types. The first brand goes on top as a theme. Design happens on this repo, directly in code; the agent builds screens from core components and the team reviews them. The gain: what's approved in design reaches the browser the same way. We go into detail in design to code with AI.
Grow. Every new project contributes to the core. AI reports patterns that repeat across products; the system's owner decides which ones join the core. The gain: the system gets a little stronger with every project.
Readiness checklist
Copy the list below and fill it in with your team to see where your system stands.
DESIGN SYSTEM READINESS CHECKLIST
Separating from the brand
[ ] Are there brand colors or typefaces hard-coded in components?
[ ] Does every value come through a token?
[ ] Are brand values in a separate theme file?
[ ] Have you tried putting a second theme on the same core?
Repo
[ ] Is the source of your design system a repo, or Figma?
[ ] Are the variants each component accepts defined in its types?
[ ] Does code review catch hard-coded colors or sizes?
Versioning and contribution
[ ] Is the system released with version numbers?
[ ] Is it written down what changed in each version?
[ ] Is there a rule for how a project adds a component to the core?
AI
[ ] Does the agent build screens from core components?
[ ] Do rules files cover only what can't be expressed in code?
Every "no" is a place where the agent has to guess. You don't need to fix them all at once; starting by separating your most used components from the brand makes the most visible difference in the shortest time.
Let's prepare your design system for AI together: send a short note to hello@things.ist and we'll get back to you within 48 hours.
Who runs the core?
The hard part isn't technical; it's ownership.
A setup that works in large organizations usually looks like this: theme changes are approved by that brand's design lead. Changes to the core go through a small group that represents every brand. Every change arrives as a review request, with its reasoning written down.
A simple example: a sub-brand wants rounder buttons on its campaign pages. If that only changes the brand's theme, the brand's design lead approves it and that's it. If it changes how the button component behaves, the shared group reviews it: will it cause problems for the other brands, does it affect accessibility? The decision ships as a new version, and products move to it when they're ready. We explain how redesigns are managed in group structures in how enterprises should approach a product redesign.
FAQ
Is design.md unnecessary now? No. It points the way: it explains the system's reasoning, voice and the rules that can't be expressed in code. But it doesn't guarantee anything; agents don't apply rules files 100% of the time. The guarantee comes from the system in code.
Should we drop Figma? There's no need. What changes is where the source lives: the true version of a component isn't the drawing in Figma, it's the code in the repo.
If we don't have a design system, where do we start? In the repo, directly. Building a new system as a brand-independent core with a separate theme from day one is much easier than separating it later.
Doesn't separating from the brand make design generic? No. The core describes how the product works; the theme gives it character. Color, typography, visual language and voice can stay different for every brand.
Does the designer's job change? Yes. Redrawing the same component in every project goes down; evolving the core, building themes and reviewing the screens the agent produces come forward. Designers' judgment is written into the system and used on every screen.
How long does this take? It depends on scope. Most projects take 10–16 weeks from kickoff to launch; separating the design system usually runs as part of that process.
Let's look at your system together
In short, here's who we are: a studio that works with AI and does design and development in one team. Things is one of the pioneering and leading companies in AI-driven design in Turkey. Since 2018 we've brought more than 50 products to life, and our work has won a Red Dot award.
Let's prepare your design system for AI together: send a short note to hello@things.ist and we'll get back to you within 48 hours. You can also reach us through our contact page.
Design. Engineering. Mastery.