TL;DR AI is shrinking the gap between design and code. Design systems still matter, but the source of truth can increasingly live in the codebase, with clear foundations and guidance for both people and AI.
Figma still has an important role as a place to explore ideas and communicate with people who aren’t working in code, but it doesn’t necessarily need to be where the design system lives.
The bigger challenge is consistency. When everyone can build quickly with AI, it’s easy to end up with multiple versions of the same component and gradual visual drift. Design systems therefore need to provide not just reusable components and tokens, but also clear instructions that both humans and AI can understand and follow.
The opportunity is to build lean, code-first design systems with enough structure to keep the whole product coherent, while leaving enough flexibility for people to explore and evolve the design.
For a long time, design systems have helped bridge the gap between design and development. Designers would create components and patterns in tools like Figma, developers would translate those decisions into code, and the design system would help keep the two aligned.
AI-assisted development is changing that relationship.
When designers can work directly in code, and tools like Claude can turn an idea into a working interface in minutes, the traditional handoff between design and development becomes less important. But that doesn’t mean design systems become less important. If anything, it creates a new set of problems that a design system needs to solve.
The question is no longer simply whether the design system should live in Figma or in code. It is how we make the decisions behind the design system accessible to everyone who is creating the product, whether they are working in a design tool, the codebase or through an AI assistant. The answer? Keep Figma as the place to explore and communicate design, make the codebase the source of truth for what ships, and document the decisions and conventions that both people and AI need to follow.
The gap between design and implementation is getting smaller
AI has made it much cheaper to move from an idea to something real. A designer can describe an interaction to Claude, make a change, see it running in the browser and iterate from there. Developers can work much more directly with visual decisions, and designers are increasingly comfortable making changes in code themselves.
That means the old separation between the design side and implementation side is starting to become less useful.
This is where the role of the design system starts to change. It doesn’t necessarily need to be a bridge between two completely separate disciplines in the way it traditionally has been. Instead, it becomes the shared set of decisions, components and constraints that everyone works from.
The important thing is not so much where those decisions are stored, but whether they are clear, reusable and accessible to the people and tools making changes to the product.
Figma isn’t going away
It is tempting to frame this as Figma versus code, but that’s probably not particularly helpful.
Figma isn’t just a place where finished designs are stored. It is also a playground. Designers can quickly move a component, try a different hierarchy, change a colour or deliberately break something to see how it behaves in a new context. That kind of exploration can lead to a completely different idea, and it doesn’t always make sense to start by implementing the whole thing in code.
There is also the communication side. A product manager, founder, marketer or content designer may need to understand and contribute to the design without wanting to work directly in the codebase. Figma remains a very accessible way of doing that and for some designers, faster to get alignment on early ideas.
We predict this may change in the future as people become more familiar with AI.
Figma still has a place in the process, but its role changes. It is the playground for exploring ideas and an accessible way to communicate design with the wider team.
The codebase should be the source of truth for what actually ships. Figma doesn’t need to mirror every implemented component or variation. It should help people explore and understand the design, while the code defines the system that the product actually uses.
That distinction is becoming increasingly relevant as tools themselves start to blur the boundary between design and code. Figma, for example, is now explicitly exploring workflows that move between code and editable design, rather than treating them as completely separate stages.
Code can become the source of truth
It’s a hot topic in the industry between designers and developers - who owns the source of truth? Is it the designer, setting the standard, or is it the developer who’s output is what the end user sees? As these roles blur with forward deployed engineers, does this matter?
Regardless, if a team is designing and building directly in code, the implemented design system to live there too.
That might mean shared design tokens for colour, typography and spacing, reusable components, interaction patterns and accessibility conventions, all of which are actually being used by the product rather than existing separately in a design file.
There is an additional advantage when AI is involved: the system can become something the AI can actually use.
A designer might look at an interface and instinctively know that a particular colour shouldn’t be introduced, or that an existing component should be reused rather than creating a new one. An AI assistant doesn’t necessarily have that context unless we give it to them.
This means the design system needs to capture more than just the visual appearance of a component. It needs to capture some of the decisions and conventions behind it.
Design systems need to become instructions too
This is one of the more interesting changes AI introduces.
Traditionally, a component library could communicate a lot through the components themselves. You could see the available buttons, inputs and cards and infer how they were intended to be used.
With AI, some of that implicit knowledge needs to become explicit.
For example, a project might tell Claude to check whether a component already exists before creating a new one, to use existing spacing and colour tokens rather than introducing arbitrary values, or to extend an existing component when a new use case comes up rather than creating another version.
These conventions should be explicitly documented somewhere the AI can discover them, such as a CLAUDE.md file, documentation alongside the components, or both. That documentation should answer practical questions such as: should I reuse an existing component or create a new one? When should an existing component be extended? Which tokens should I use? When is a new pattern justified?
The goal is to turn the design system’s implicit knowledge into explicit instructions that both humans and AI can follow.
This is already becoming an area of focus for design-system tooling. Figma has written about the need for design systems to provide more of the context that humans previously inferred, while Storybook is developing ways for AI agents to discover existing components, documentation and usage information.
The risk is that everyone builds their own version
There is an interesting downside to making building so easy.
If several people can independently ask Claude to create a card, a modal or a navigation pattern, there is nothing stopping them from ending up with three slightly different versions of the same thing. Each one might be perfectly reasonable in isolation, but over time those small differences start to accumulate.
This is probably a bigger risk than moving away from Figma.
The individual components might all be well designed, but the product as a whole can start to drift. Colours get slightly different, spacing becomes inconsistent and components start to behave differently depending on where they are used.
This is where the broader purpose of a design system becomes important. It isn’t just about making individual components consistent. It is about helping the whole product feel like it belongs together.
We still need a way to see the system
Even if the codebase becomes the source of truth, there is still value in having a visual representation of the system.
That might continue to be Figma, particularly when the team wants to explore an idea collaboratively. It could also be something like Storybook, which provides a visual catalogue of the components that already exist in code, along with their different states, variations and documentation.
For a team working heavily in AI-assisted development, this can be particularly useful because it gives both humans and AI a clear picture of what is already available. Instead of asking Claude to create a button, there is an obvious place to discover the buttons that already exist.
The important thing is not to create two separate design systems that have to be maintained in parallel. The visual reference should help people understand and explore the system, while the code remains the place where the implemented components live.
The role of design-system work is changing
This also changes the kind of skills that are valuable in design-system work.
Designers who understand code, and developers who understand design, are increasingly well positioned to work on these systems because they can see both sides of the decision. They can explore an idea, understand the constraints of the implementation and make sure the final component works as part of the wider system.
At thoughtbot, this is the way our designers have always worked. We recently created Roux, a boilerplate of CSS defined styling, your shortcut for consistency.
The work becomes less about maintaining a library of components and more about maintaining the relationships between them.
That is particularly important when AI is doing more of the implementation. Someone still needs to think about whether all of these individually reasonable decisions make sense together.
Start small and let the system evolve
The answer isn’t to build a huge design system before anyone is allowed to start using AI.
A lean approach is likely to be more useful. Start with the things that are already repeated across the product: colours, typography, spacing, buttons, links, forms, navigation and common interaction patterns. Make those reusable, make the rules around them clear, and make them easy for both humans and AI to discover.
The system can then evolve alongside the product.
This is also important when the visual identity itself is still developing. There is little value in spending months trying to perfectly formalise every colour, spacing value and component variation if the brand and visual language are going to continue evolving. The design system should give you enough structure to make those decisions consistently as they develop, rather than making today’s decisions unnecessarily difficult to change later.
So what does a design system look like now?
It shouldn’t be a Figma file full of components, or a code library sitting completely independently from design.
It is increasingly a combination of things: the tokens and components that actually power the product, the documentation that explains how they should be used, the visual references that allow people to explore them, and the instructions that allow both humans and AI to make use of them consistently.
The biggest change is that the boundary between those things is becoming much less rigid.
Design might start in Figma, in code or in a conversation with an AI. It might move between all three several times before something ships. That is not necessarily a problem for design systems. It is an opportunity to make the system more useful by putting the underlying decisions closer to the work itself.
AI can make it dramatically easier for more people to build.
The challenge for design systems is making sure that all of that new capability still adds up to a product that feels coherent, intentional and considered.