---
title: "A design system that powers AI in delivery. How to shorten the design-to-code cycle from days to hours"
url: "https://wzor.biz/en/blog/design-system-ktory-napedza-ai-przy-wdrozeniach-jak-skrocic-cykl-design-to-code-z-dni-do-godzin/"
description: "A well-designed design system becomes fuel for AI code-generation tools. We show how to lay out tokens, components and documentation so the design-to-code cycle shrinks from days to hours."
lang: "en"
---
[Design System](https://wzor.biz/en/blog/category/design-system/)

# A design system that powers AI in delivery. How to shorten the design-to-code cycle from days to hours

 [![](https://wzor.biz/_astro/patryk-korycki.D95uAkaq_Z1DJTgc.webp) Patryk Korycki CEO, Business Analyst](https://wzor.biz/en/team-and-partners/patryk-korycki/)

Published 15 November 2025 8 min read

![An AI-powered design system](https://wzor.biz/_astro/design-system-ai.BxTWAh3o_ZJGOxm.webp)

Your development team has just received the wireframes from Figma.

The designer says “it’s ready”. The developer looks at the design and wonders how to turn it into code. The AI assistant tries to help, but generates code full of `<div>`s instead of semantic components. The result? Three days of work, twenty rounds of fixes and an interface that looks “almost” like the design.

Sound familiar?

The problem isn’t in the AI. Nor in the designer. Nor in the developer.

The problem is a design system built for humans, not for machines.

For the past decade, design systems have been pattern libraries for teams. Documentation written on the assumption that the developer “gets the gist”. A colour, a spacing, a component - a human looks and understands the context.

**AI doesn’t have that context.**

When an AI agent reads your design system, it sees hex colours, pixels, rectangles. It doesn’t see intent. It doesn’t understand that a red button is a destructive action. It doesn’t know that this particular spacing is part of an 8px grid system.

The effect? Hallucinations in the code. Inconsistencies. Errors that cost money.

This article shows exactly how to build an AI-ready design system - one that shortens the design-to-code cycle from days to hours. With examples from Siemens and GitHub and a concrete implementation framework.

## Why your design system sabotages AI

A traditional design system assumes one thing: that a human will fill in the gaps.

The documentation says “use the Primary Button for the main action”. The developer knows from experience that this means: one per view, aligned to the right, with the right contrast. **Tacit knowledge.**

The AI agent reads that same documentation and sees an instruction. It doesn’t see the rules. It may generate five Primary Buttons on one screen - because no one explicitly coded the constraint.

[Figma’s article “5 shifts redefining design systems in the AI era”](https://www.figma.com/blog/5-shifts-redefining-design-systems-in-the-ai-era/) describes this gap between what the designer and developer know intuitively and what AI can infer from the data.

Research shows three types of knowledge in design systems:

**Explicit knowledge** - codified, in the documentation. AI handles this brilliantly.

**Implicit knowledge** - in workflows, habits. “We always use an 8px grid”, but we never wrote it down. Here AI loses the thread.

**Tacit knowledge** - deeply personal. The “feel” of the brand, intuition. The hardest to transfer.

The problem is that most design systems rely mainly on implicit and tacit knowledge. For AI, that’s a black hole.

Your agency may have 200 components in Figma, but if AI can’t _understand_ them - their semantics, usage context, constraints - every code generation is a lottery.

## Three foundations of a design system for AI

For AI to stop hallucinating and start composing, your design system needs three layers: semantic structure, a language of intent, and a context protocol.

Each layer eliminates a different kind of error.

### Foundation 1 - Semantic structure through Auto Layout

The first rule: **every element must have an explicit spatial relationship**.

When a designer in Figma manually aligns text inside a rectangle, to a human it looks like a button. To AI it’s two unrelated objects sharing coordinates.

[Auto Layout changes this radically.](https://www.designsystemscollective.com/how-ai-turns-figma-into-code-c20a3a0412b4)

It creates a parent-child hierarchy that AI can read deterministically. A “Horizontal layout” with “Space Between” in Figma translates 1:1 to `display: flex; justify-content: space-between;` in CSS.

Specifically:

**Without Auto Layout:** AI analyses the X/Y positions of all elements, tries to infer the layout, and generates a rigid `width: 345px`. The interface breaks at other resolutions.

**With Auto Layout:** AI reads `layoutMode: HORIZONTAL`, `counterAxisSizingMode: AUTO` and generates `flex flex-row w-fit`. Responsive by definition.

This isn’t a cosmetic difference. It’s the difference between code that works on all devices and code that requires manual refactoring.

Our framework requires 100% Auto Layout coverage in system components. No exceptions. Sounds restrictive? Last project: 89 screens, code generation with AI, zero layout problems. The saving: around 12 hours of developer time.

### Foundation 2 - Variables as a dictionary of intent

The second rule: **every value must have a semantic name**.

The difference between `#0055FF` and `sys.color.action.primary` is the difference between a value and a concept.

When the design uses a raw hex, AI sees a colour. When it uses a variable, AI sees _meaning_. And it can map that token to its corresponding token in code - `var(--sys-color-action-primary)`.

The result: 100% consistency between design and code. Zero “close-enough colour” hallucinations.

Variables do one more critical thing: **they constrain AI’s output space**.

Without tokens, the model can generate any colour, any spacing. With tokens? Only approved values. It’s like quantising design possibilities - you reduce entropy, you increase predictability.

### Foundation 3 - The Model Context Protocol as a bridge

The third rule: **AI must have access to the full design context in real time**.

This is where the [Model Context Protocol (MCP)](https://uxwritinghub.com/the-complete-guide-to-figma-mcp-server-vibe-coding/) comes in - an open standard from Anthropic, adopted by Figma.

Instead of sending AI a screenshot, you send structured JSON with the full semantics of the design.

The architecture looks like this:

-   **The Figma MCP server** (local or remote) exposes the design data
-   **The MCP client** in the IDE (VS Code, Cursor, Windsurf) queries the server
-   **The AI agent** receives not pixels but a schema - the node hierarchy, layout rules, references to variables, component properties

A sample JSON payload for a button:

```
{
  "nodeId": "123:456",
  "name": "Primary Button",
  "layoutMode": "HORIZONTAL",
  "primaryAxisSizingMode": "AUTO",
  "fills": "var:sys.color.action.primary",
  "componentInstance": "design-system/Button"
}
```

AI reads this and knows exactly:

-   Which component to import from the system
-   Which props to set
-   How to lay out the elements
-   Which tokens to use

Add [Code Connect](https://help.figma.com/hc/en-us/articles/23920389749655-Code-Connect) to that - mapping Figma components to specific files in the repository - and you get something powerful.

![Connecting a design with components in code](https://wzor.biz/images/blog/inline/720092c03c3c9ff23b8cf2827c2a195c4b262c46.gif)[Image source](https://help.figma.com/hc/en-us/articles/23920389749655-Code-Connect)

When AI encounters a mapped component, it doesn’t generate new code. It imports the existing component from the codebase. With the right props. With the full logic. With tests.

## What it looks like in practice

The theory sounds beautiful. But do these things work in production?

Yes. Companies like Siemens and GitHub are already implementing these solutions.

### Siemens - industrial interfaces with MCP

[Siemens described its approach](https://blog.siemens.com/2025/11/revolutionizing-design-to-code-workflows-with-figma-mcp-server/) to using the Figma MCP Server in the context of industrial interfaces.

The challenge they faced: complex, safety-critical interfaces. A huge component library. Compliance requirements that can be overwhelming.

The traditional handoff looked like this - the designer hands over files, the developer interprets, design debt accumulates, error rates are high.

Their solution is based on:

-   Implementing Figma MCP and Code Connect
-   Mapping the industrial component library to the codebase
-   Adding a semantic layer to the components

The result, according to Siemens: **the design-to-code cycle shortened from days to hours**. Accelerated validation of configurations across browsers and a significant reduction in manual QA effort.

### GitHub - automating token synchronisation

[GitHub and Figma are running a webinar](https://resources.github.com/events/figma-mcp-server-github-copilot-webinar/) showing how the Primer team (GitHub’s design system) uses the Figma MCP Server with GitHub Copilot.

GitHub’s approach:

-   The AI agent scans both the Figma files and the code repository
-   It automatically identifies discrepancies in tokens (e.g. different hex values for the same colour)
-   It generates synchronisation Pull Requests

This solves the “drift” problem - the slow divergence of values between design and code, which in large systems eats hours of work a week.

## Important caveats - technology in development

Before you implement MCP in your team, you need to know the [real limitations of current solutions](https://uxwritinghub.com/the-complete-guide-to-figma-mcp-server-vibe-coding/):

**Beta status:** The official Figma MCP server is still in public beta. This means potential stability issues and API changes.

**Licensing requirements:** Full functionality (especially Code Connect) requires Figma Professional or Enterprise plans.

**Setup complexity:** Configuring MCP requires solid technical competence. Small teams without dedicated DevOps resources may struggle to implement it.

**Design system maturity:** The greatest benefits are achieved by teams that _already have_ a well-organised design system with full Auto Layout and variable coverage. For teams starting from scratch - you have to build the foundations first.

## How to implement this in your project

You see the value. The question is - how to start?

The framework we use at WZÓR has 5 phases. Not steps. Phases. Because it isn’t a linear checklist.

**To begin - an audit of the current system**

A week of work. Two at most.

Review your design system and answer the questions that hurt:

-   What percentage of components use Auto Layout? (Target: 100%)
-   Are all colours, spacings and fonts variables? (Target: 100%)
-   Do the components in Figma have the same names as in the code?
-   Is there documentation on _when_ to use a component, not just _how_?

Analyse the baseline. Without it you won’t see progress.

**Next - semantic refactoring**

This is an investment of 2–3 weeks or half a year. It all depends on the current state of the file. But it pays off on the first project with AI.

Prioritise the most frequently used components. Add Auto Layout to all components. Replace raw values with variables. Align the Figma ↔ code naming - exactly the same prop names. Add descriptions like “Maximum 1 Primary Button per view”.

Sounds like a lot of work?

Yes. And it’s worth it.

**Now - implementing MCP**

The technical setup takes a week. Install the Figma MCP server - local or remote. Configure the connection in the team’s IDE. Test context extraction on a simple component. Document the setup for the team.

**And finally - Code Connect mapping**

Two weeks or more to connect Figma with the repository. Map the key Figma components → code. Add import and usage snippets. Write custom instructions for complex components. Connect GitHub for live sync.

**Pilot**

Choose one small feature. A Figma design with the new system. Code generation by AI with MCP. Measure implementation time, the number of fixes, the code quality. Gather feedback from the team.

Compare with previous projects.

The numbers speak for themselves.

Timeline? 6–8 weeks from audit to pilot under optimistic conditions. The cost depends on the size of the system. But ROI appears fast - on average, after 2–3 projects with the new system you’re in the black.

## Three mistakes that will ruin everything

I’ve seen many rollouts. Successful and totally botched.

Three mistakes recur in the latter.

**A half-measure rollout**

“We’ll do Auto Layout on 80% of components.”

No.

80% is too little. AI will hit that 20% and hallucinate. It’s like a chain - it breaks at the weakest link.

Either 100% or it’s not worth starting. Full stop.

**No enforcement**

The system is ready. It looks beautiful in the presentation. And so what?

A developer creates a component “quickly” without variables. A designer “just this once” skips Auto Layout. No one enforces it. No one reacts.

The consequence?

The system degenerates in no time. All for nothing.

The solution - linter agents that automatically flag deviations. Code review with a compliance checklist. No exceptions. No “just this once”.

**Ignoring people**

This is a change in the workflow. Designers have to think more structurally. Developers have to trust AI. That isn’t comfortable.

Without onboarding and training, the team will resist. Because people don’t like changes they don’t understand.

Invest in education. Show the metrics. Celebrate the quick wins. And listen to objections - sometimes they’re justified.

## What this means for your next project

An AI-ready design system isn’t a “nice to have”. It’s a competitive advantage.

When your team can move from a design to working code in hours instead of days, the rules of the game change:

-   Faster MVPs
-   More iterations in the same time
-   A lower cost of experiments
-   Higher team morale (less frustration with fixes)

For the Product Owner: you can test more hypotheses in the same sprint.

For the Project Manager: the risk of delays drops, estimates become more precise.

And all of this because you stopped treating the design system as a pattern library and started treating it as a **context engine for AI**.

## Next steps

If you manage a product with active interface development, run this simple test:

1.  Take the last project handed over to development
2.  Measure the time from “design ready” to “code in review”
3.  Count the rounds of fixes related to design ↔ code mismatch
4.  Sum up the time spent “translating” the design into code

If that’s more than 20% of total development time - you have a problem that a design system for AI solves.

**At Wzór, we’ve been designing delivery-ready interfaces for 9 years.** Recently something new has been added: we design design systems that accelerate delivery with AI. If you want to see how it works in practice - [book a free consultation](https://wzor.biz/en/free-consultation/).

We’ll show you exactly:

-   How to audit your current system
-   Where the biggest gaps for AI are
-   What ROI you can expect in your context
-   A concrete implementation plan

**Our designs are the blueprint for your company’s success in the world of AI.**

Share this article

LinkedIn Facebook X Send by email Copy link

![](https://wzor.biz/_astro/patryk-korycki.D95uAkaq_h035z.webp)

About the author

## [Patryk Korycki](https://wzor.biz/en/team-and-partners/patryk-korycki/)

CEO, Business Analyst

Co-founder and CEO of the UX agency Wzór. For 9 years he has been running UX/UI projects for startups, software houses and large companies - from audits, research and business analysis, through product strategy, to delivery. He specialises in projects at the intersection of e-commerce, SaaS and fintech. An Interactive design practitioner - designing UX/UI directly in code.

[LinkedIn](https://www.linkedin.com/in/patryk-korycki/) [Book a consultation](https://wzor.biz/en/free-consultation/)

Related posts

## Keep reading

[All posts →](https://wzor.biz/en/blog/)

-   ![Alternatives to a full-time UX/UI designer](https://wzor.biz/_astro/co-zamiast-zatrudnienia.CTbXh4KR_Z21s26V.webp)
    
    [Design System](https://wzor.biz/en/blog/category/design-system/)
    
    ### [What instead of hiring a full-time UX/UI designer when the project stream is irregular?](https://wzor.biz/en/blog/co-zamiast-zatrudnienia-na-etat-projektanta-ux-ui-gdy-strumien-projektow-jest-nieregularny/)
    
    Three alternatives to an in-house designer when the project stream is irregular - body leasing, white label and a project contract. When to choose which.
    
    ![](https://wzor.biz/_astro/patryk-korycki.D95uAkaq_JVaOi.webp) Patryk Korycki 5 min read
    
-   ![A UX agency collaborating with a software house](https://wzor.biz/_astro/agencja-ux-software-house.pgyfVwt-_1dcokf.webp)
    
    [Design System](https://wzor.biz/en/blog/category/design-system/)
    
    ### [How does a UX agency support a software house in sales, project management and UX/UI design?](https://wzor.biz/en/blog/jak-agencja-ux-wesprze-software-house-w-sprzedazy-zarzadzaniu-projektem-i-projektowaniem-ux-ui/)
    
    A UX partner strengthens a software house in three areas: the client conversation, project management and UX/UI design. The specifics of the visible and white-label models.
    
    ![](https://wzor.biz/_astro/patryk-korycki.D95uAkaq_JVaOi.webp) Patryk Korycki 3 min read
    
-   ![Design system - what it is and how to create one](https://wzor.biz/_astro/design-system-co-to.Dma-_GW1_Zz7O5o.webp)
    
    [Design System](https://wzor.biz/en/blog/category/design-system/)
    
    ### [Design system: what is it and how to create one?](https://wzor.biz/en/blog/design-system-co-to/)
    
    A design system lets you stop burning budget on graphic design work. We explain what it is, when it's worth building and how to start - from the audit to the components.
    
    ![](https://wzor.biz/_astro/katarzyna-adamczuk.BgcDb3aF_1mPSQl.webp) Katarzyna Adamczuk 7 min read