AI and Design Systems: Governance and the Role of Code

AI saves time for design teams, but shifts the constraint towards validation and consistency. Leaders at Siemens and ITV, along with a Design Systems specialist, describe different responses: loosening the framework, delegating locally, or instrumenting with MCP servers and LLMs. Recent data shows an accelerated preparation for machine-readable systems, while some defend code as the source of truth.

Machine-readable systems, MCP, and tokens in support

Several teams are steering their Design Systems towards direct consumption by AI tools and agents. Nicolas Chatelain's team observed V0 and Lovable in the second half of 2025 and deemed their adoption premature, preferring to prepare the existing framework. Tokens have been migrated to the DTCG standard, so that colors, spacing, and typography are interpreted uniformly by tools and agents. An MCP server allows agents to query the system to identify the correct component or token instead of guessing. In July 2026, Kaelig Deloumeau-Prigent studied 21 open-source Design Systems: 20 offer an MCP server, either official or community-based, but only 3 have implemented Figma Code Connect. In other words, many systems are becoming machine-readable, but fewer connect their design components to their code equivalents. At Siemens, an LLM compares team implementations to what the system prescribes and flags what needs correction, with AI remaining a tool among others, like a motor for harmonizing thousands of icons. David Sward emphasizes the importance of keeping a human in the loop to maintain an understanding of the system's state. Marianne Ashton-Booth points out that even if some parts can be generated or automated further, a Design System still involves people and a process.

Adoption: the difficulty is human, not in the components

Creating prototypes in minutes has become commonplace, but the gap with feasibility, brand compliance, or alignment with existing components remains real, according to Marianne Ashton-Booth. For Nicolas Chatelain, the UI is the easy part: what makes a Design System work is its governance and adoption. Neither he nor Marianne Ashton-Booth identifies components as the main problem; a kit can even be assembled quickly. The challenge is consistency at the team and enterprise level, in other words, a matter of people, processes, and relationships. According to Zeroheight, communication and community account for 59% of successful adoption cases. When a Design System fails, Marianne Ashton-Booth locates the causes in invisible layers such as trust, communication, prioritization, relationships, and shared belief, rather than in basic operations.

Speed increases, the bottleneck shifts to review

Artificial intelligence allows for accelerated production up to the delivery phase, to the point that David Sward indicates he has to slow his teams down to maintain the security and compliance requirements typical of a large enterprise. At Siemens, the Design System conditions several hundred products, and a simple error could lead to correction costs of several hundred million euros; therefore, it is essential to ensure nothing is compromised. Productivity gains are evident, while the main bottleneck shifts from the execution phase to those of proofreading, validation, and consistency assurance. Nicolas Chatelain and Marianne Ashton-Booth observe the same evolution in their respective contexts.

Three organizational responses to cadence pressure

In a mission led by Nicolas Chatelain, AI-accelerated product teams have outpaced the central Design System team, which was initially tempted by a lock-in strategy. His observation is that flexibility must be gained; otherwise, teams will circumvent the framework. Mechanisms like Figma slots, where content is inserted into standardized components, ease the constraint. At ITV, the approach relies on representatives from the Design System, both in design and engineering, who have increased visibility and influence in final decisions to avoid bottlenecks. Instead of isolating AI as a separate topic, ITV has examined its concrete effects on the system and evolved its processes. These insights converge: the right response depends on the context, level of risk, and degree of acceptance of AI, and human intervention remains crucial to determine when and how to arbitrate.

Code claimed as the source of truth by some practitioners

Nicolas Chatelain argues that the source of truth for a Design System should today be the code, which removes a layer of abstraction between AI and production. He suggests that if documentation lives directly in the code, Figma might no longer be necessary, while admitting he could be wrong and acknowledging Figma's usefulness for exploration and refinement. In a related reflection, Tony Ward recommends keeping a subject matter expert in the loop at every stage when code becomes the reference.

Misleading shortcuts and the real scope of a Design System

Viral narratives promise a complete Design System in 15 to 20 minutes with models like Claude or Gemini. These promises blur the line between a UI kit and a Design System, whose scope includes governance, adoption, and processes. Three experts with distinct approaches illuminate this scope: Nicolas Chatelain advocates for a flexible framework ready for AI, David Sward for speed framed by safeguards with a human in the loop, and Marianne Ashton-Booth for treating the Design System as a product, driven by people and processes. The first two recently spoke at UXDX Berlin in May, and their positions, like that of Nicolas Chatelain, are explained by their respective contexts.