Your design system now talks to an AI: what's really changing in Figma in 2026

The day an agent read my design system better than my client did

On a recent assignment for a Quebec-based multi-brand SME, I plugged a code agent into Figma's MCP server and asked it to generate a registration form from the mock-up. Within fifteen seconds, it was outputting React code that used the right color tokens, the right spacing, the right button component - not a visual approximation, the real named variables from the library. My client, on the other hand, was still detaching components by hand three months earlier. That's when the shift became obvious: the design system is no longer just about aligning humans. It's about making a design intent machine-readable.

This is the shift that Figma itself put into words at Schema 2025, its conference dedicated to design systems, on October 28, 2025: design systems move "from static standards to living systems", and become "the translation that AI needs to understand design and code". For twenty years, the design system has been sold as a source of truth for the team. In 2026, this is still true, but it has become secondary. The real value lies elsewhere: a well-tokenized system is now a productivity factor for everything you generate with AI, and a poorly designed system produces code that's just as incoherent as your mock-ups.

Why the translation layer is more important than the library

The technical link in this switchover is Figma's MCP server, which came out of beta and went into general availability in 2025. The Model Context Protocol enables an agentic coding tool - Claude Code, Cursor, the editor of your choice - to fetch context directly from Figma: screen structure, component names, associated variables. Coupled with Code Connect, which maps each Figma component to its actual coded equivalent in your repository, the agent no longer sees a generic CSS extract: it sees the Button component of your design system, with its props.

The new feature of 2025 that changes the game for small teams is Code Connect UI. Previously, establishing this design-code link meant writing configuration files by hand - a real hindrance when working alone or in pairs. Now, you connect Figma directly to a GitHub repository from the interface, and an AI suggestion function suggests which code file to map to which component, without writing a line. For a long time, I thought of Code Connect as a platform team luxury. With this version, it has become accessible to a one-person studio, and I now enable it by default on any project that has a coded design system.

My conviction, after testing it on real mandates: the quality of your AI generation is capped by the quality of your tokenization. If your colors are called blue-2 and light-blue-final-v3, no agent will guess which is your action color. If they're called color/action/primary, he'll guess - and so will a human. Naming discipline is no longer a maniacal designer's quirk; it's what determines whether your system is machine-readable.

The Design Tokens spec is finally stable - and it expires your old pipeline.

The second major event at the end of 2025 went more unnoticed, but it was a structuring one. On October 28, 2025, W3C's Design Tokens Community Group released the first stable version of its specification, 2025.10. For years, we worked with a moving draft - I myself built pipelines on formats that changed with each release. No more: there is now a neutral, stable exchange format supported by over ten tools, including Figma, Tokens Studio, Penpot, Sketch and Framer.

What 2025.10 brings in concrete terms and justifies revisiting an old setup: support for modern color spaces - Display P3, Oklch and the CSS Color Module 4 set - whereas the old format was limited in practice to hexadecimal. A color is no longer a #0066FF string, but an object bearing its color space, its components, its alpha and a hexadecimal fallback value. The same logic applies to dimensions and durations, which become structured objects with a value and a unit (value 16, unit px) instead of an ambiguous string. For someone who generates CSS, Swift and Compose from a single source, this is exactly the precision that's been missing.

On the tooling side, Style Dictionary - the reference for transforming tokens into code - has been upgraded to version 5, aligned with this spec. The default export format is now JSON DTCG, transformations natively handle new object types, and the version requires Node 22. If you're still running Style Dictionary v4 on an old token format, you're not broken, but you're accumulating a debt that will be paid off at the next theme refactor. And good news for those who stick with Figma: the long-awaited native import/export of variables arrived in November 2025 - Figma deliberately waited for the DTCG spec to reach 1.0 before delivering it, precisely so as not to lock people into a proprietary format.

What Figma actually delivered in 2025 (beyond the marketing)

It's important to separate the spectacular announcements from the real workflow gains. Config 2025 was mostly about four new products - Figma Sites, Figma Make, Figma Buzz and Figma Draw - which are interesting but peripheral for a design system. The real giveaway was less sexy: Figma completed a massive rewrite of its design system architecture. The result, measured and announced by Figma, is that updating variables or changing modes is 30 to 60% faster, and certain heavy state switching operations have been reduced from 3500 ms to 350 ms. When you work all day in a complex system file, this is the kind of gain you can feel physically.

Element	Before	In 2026
Spec Design Tokens W3C	draft (Second Editor's Draft)	stable version 2025.10 (Oct. 28, 2025)
Style Dictionary	v4	v5 (default DTCG export, Node 22)
Figma variable modes	4 maximum	10 (Professional) / 20 (Organization)
mode switching (perf)	slow on large files	30-60% faster; 3500 ms → 350 ms
design-code link	manual config	Connect UI code + MCP (GA) server

Three Schema 2025 features are well worth adopting. Extended collections finally solve the multi-brand headache: one team can publish a "white label" version of the system that the others extend with their own theme, while automatically inheriting updates from the parent system. On my multi-brand mandate, this is precisely what I needed to avoid duplicating entire collections. Slots correct a limitation as old as Figma components: you can now insert your own layers into an instance - think of a drop-down list to which you add items - without detaching the component and breaking the link with the system. And the Check designs linter detects raw values that should be variables and suggests the right token before handoff, eliminating the eternal question from the dev: "which token did you use, exactly?"

A detail that counts if your system gets bigger: the limit on variable modes, long stuck at four, has been raised to 10 on the Professional plan and 20 on Figma Organization. Four modes were enough for light/dark plus two marks; beyond that, we were stuck. It's not a revolution, but it's exactly the wall that successful systems hit.

Building for 2026 without building a gas factory

The risk, when reading all this, is to want to plug everything at once - MCP, Code Connect, pipeline Style Dictionary, ten modes - into a project that doesn't need it. I say it clearly because I've done it: over-architecting a design system is just as expensive as not having one. Most of the SMEs I work with don't need twenty modes or a CI/CD pipeline of tokens. They need three things done right: a semantic naming convention that translates as is into code (color/surface/primary becomes --color-surface-primary), twenty or so well-chosen color tokens rather than two hundred never-used shades, and the design-code link activated once the system is stable.

Order counts. I always start with token discipline, because that's what makes everything else possible - including AI readability. I add Code Connect and the MCP only when the design system has proven itself to be stable, never on a system that is still in motion, otherwise we maintain links to components that change every week. And I resist the temptation to adopt every new feature announced: a system that isn't maintained is a dead system, no matter how many features are checked off.

The real question of 2026 is no longer "do I need a design system". It's "Is my system clean enough for a machine to understand without me? If the answer is no, it's not Figma that needs updating - it's your naming convention. The tooling has already caught up with the rest.