AI Automates the Easy Part of Design Systems, But Governance Remains Human

You've probably seen the LinkedIn post: someone builds a "complete design system" in 20 minutes with Claude, or 15 with Gemini. Journalist Anna Lefour, from UX Collective, admits she fell for that bait: she tried to reproduce the feat and realized she was confusing a UI kit with an actual design system (the full account is here). The confusion isn't hers alone: it's the most common mistake made by anyone who measures a design system by its number of components.

After listening to two talks at UXDX Berlin in May 2026, Lefour interviewed three people who live this problem every day: Marianne Ashton-Booth, Head of Product Design at ITV; David Sward, Chief Design Officer at Siemens; and Nicolas Chatelain, a freelancer specialized in Design System and Design Ops. The three accounts, read together, convince me of one thing: AI solved exactly the part that was always the easiest part of a design system, and left the hard part even more exposed.

The Easy Part Has Already Been Automated, and That Was Never the Problem

Nicolas Chatelain puts it bluntly: the UI is the easy part of a design system. Anyone today can build a component kit with a generative AI tool.

The hardest part, the one that makes a DS work or not, is governance and adoption.

Nicolas Chatelain, a freelancer specialized in Design System and Design Ops

Marianne Ashton-Booth saw the same pattern in a different context. At ITV, when a design system fails, she says, it's almost never because of the components: those tend to be fine. What breaks are the invisible layers underneath, trust, communication, prioritization, relationships, and shared belief between whoever designs and whoever decides the roadmap.

One data point supports this reading: the Zeroheight report on the state of design systems, published in early 2026, shows that 59% of professionals attribute the system's adoption to the communication and community around it, not to the technical quality of the components. No generative AI tool moves that number.

The Bottleneck Didn't Disappear, It Just Moved Address

David Sward leads the design system for a company with hundreds of products depending on it. A mistake there, he says, costs a few hundred million euros to fix. His problem today is a different one.

My biggest problem is trying to slow people down with AI.

David Sward, Chief Design Officer at Siemens

That doesn't mean slowing down AI adoption itself: it means keeping teams within the security and compliance rules of a large company, while production speed keeps rising. In short: when AI removes the bottleneck from production, it reappears in review, in validation, in whoever ensures everything stays coherent. Nicolas Chatelain saw this in an even more radical way: on a project for an international group, product teams supercharged by AI started producing faster than the central design system team, whose original strategy was to lock everything down.

With AI, it's a total rollback. We have to become much more flexible, because tomorrow people could create a kit in five minutes. If we become useless, they'll find an even easier way to bypass us.

Nicolas Chatelain, a freelancer specialized in Design System and Design Ops

One technical workaround for this is Figma's slots, which let teams insert their own content inside a standardized component without breaking the pattern. At ITV, the workaround was organizational: "design system representatives" in design and engineering, people with enough weight to make final decisions without stalling the flow. There's no single answer, and that in itself is telling: the type of bottleneck that shows up depends on the organization's risk level and how much AI has already been accepted internally, not on which generative AI tool was chosen.

Making the System Machine-Readable Doesn't Solve Who's in Charge of It

The part of Lefour's account that most resembles "the future" is already present: making the design system machine-readable. Nicolas Chatelain's team spent the second half of 2025 watching tools like V0 and Lovable, concluded it was still too early to adopt them, and decided to prepare the system instead of switching tools: they migrated the tokens to the DTCG standard (Design Tokens Community Group), the shared format for color, spacing, and typography that lets any tool, and any AI agent, read the same values.

A field study published in July 2026 by Kaelig Deloumeau-Prigent analyzed 21 open-source design systems and found a significant mismatch:

• 20 of the 21 systems already offer an MCP (Model Context Protocol) server, either official or community-maintained, which lets an AI agent query the design system directly instead of guessing which component or token to use;
• only 3 have set up Figma Code Connect, which links a Figma component to the actual code that implements it.

In other words: far more systems let AI read them than systems that manage to tie their components back to the design. That's exactly the opposite of what the "AI-ready design system" pitch usually sells. Preparing the token format is necessary technical work, but it doesn't resolve who decides what goes into the system, nor who approves the pull request that changes a component used across fifty products.

Code as the Source of Truth: a Bet I Think Is Right, With One Caveat

Lefour reaches a conclusion I'd sign off on: code, not the design file, is becoming the source of truth for design systems. Nicolas Chatelain is categorical about it.

Today, the source of truth has to be the code. Absolutely.

Nicolas Chatelain, a freelancer specialized in Design System and Design Ops

Working from code removes a layer of abstraction between AI and production. The argument also appears in the article "Code as the Source of Truth", by Tony Ward, cited by Lefour: the central point isn't removing humans from the process, it's keeping "a subject matter expert involved at every step of the way." David Sward agrees, and explains why that matters in practice, not just in principle.

You can't remove a human from the loop and then expect them to step back in to operate the system if they don't understand the state the system is in.

David Sward, Chief Design Officer at Siemens

Here's the caveat I'd add to Lefour's argument: code as the source of truth only works if code review actually becomes a governance decision, not an automated checklist. If no one with authority over the system understands its state, swapping the design file for the repository solves nothing, it just moves where the problem lives.

Where I Disagree a Bit With the Piece's Optimism

The weakest point in Lefour's conclusion, in my reading, is treating "preparing the system for AI" (DTCG tokens, MCP server) as if that were already part of the governance solution. It isn't. It's a technical prerequisite, necessary but insufficient: the same study that shows 20 of 21 systems with MCP shows only 3 with Code Connect, and the Zeroheight report shows that adoption is explained by communication, not token infrastructure.

An AI agent that reads your design system perfectly can still be instructed, by a rushed team, to ignore the right component and generate a "just this once" shortcut. What prevents that isn't MCP: it's exactly the trust, prioritization, and shared belief that Marianne Ashton-Booth describes as the layers that break first. She herself closes the argument leaving no room for doubt.

There might be parts of a design system that become more AI-generated or automated. But a design system isn't just that part, you know, it's the people and it's the process as well. And that's the bit that I think we'll still retain.

Marianne Ashton-Booth, Head of Product Design at ITV

What I'd Bring to a Design System Here in Brazil

If you maintain or are about to build a design system now, the question worth asking isn't "which generative AI tool to use for the components." It's a different one: when your team doubles its screen-production speed, who's going to review all that speed, and with what authority?

A few concrete questions to bring to the next design system meeting:

1. Do our tokens already follow a machine-readable standard (like DTCG), or does each tool interpret color and spacing its own way?
2. If we expose an MCP server, who guarantees it reflects the code in production, and not an outdated Figma file?
3. Who has the authority to accept or reject an AI-generated component before it goes to production, and is that person available at the speed the team demands?
4. Is the problem blocking adoption today a lack of components, or a lack of trust in whoever decides on them?

Your company's answer to these questions will differ from ITV's, Siemens's, or Nicolas Chatelain's client's, because each context has its own risk level and its own maturity with AI. But the question itself doesn't change: AI removed the excuse that building components is the hard work. What's left, governance, trust, judgment over what enters the source of truth, has always been, and remains, human work.