There is a question I ask at the start of every Design System I build: how do we name things? How do we name, say… the token for the blue colour?
brand-color. main. primary. blue. sky.Every team has a name, and every name carries a different meaning, a different role, a different place in the hierarchy. They are not interchangeable. And figuring out which one, and why, deserves a real conversation before a single line of code is written.
This has been my obsession for many years. Not the colours. Not the components. The agreement on the basics, before anything else is built on top of them.
When we built Panot at Fotocasa Group, we settled on main. A variable in Figma. In CSS, --colors-main. In Kotlin, a resource reference. In Swift, something else again. Every platform translated it differently. Every platform called it the same thing.
I did not know, when we made that decision, that there would be a fifth reader of that token within a year. An AI agent. But when it arrived, main was already there, waiting, legible. Not because we could read the future. Because we had agreed.
The agreement has always had more readers
I have been building Design Systems since 2017. At eDreams. At Schibsted, and then across Adevinta, which was the umbrella for Kleinanzeigen, Leboncoin, and many others. Across countries and companies that often had nothing in common except the problem they were trying to solve. The tools changed: Sketch became Figma, Sass became CSS Variables, JS became TypeScript, KSS became SUI Studio, SUI Studio became Storybook, then MDX. The problem never did.
The problem is always: how do you make a decision that survives the gap between the person who made it and the person who needs to execute it? That gap started between two humans in the same room. Then between designers and developers on different floors. Then between teams in different countries, working in different codebases. Each time it widened, the system had to become more legible, more structured, more explicit.
The agent is just the newest reader across that same gap. But the most unforgiving one. A developer can ask a question. An agent cannot. A developer can infer your intent from context, history, and the coffee conversation last Tuesday. An agent reads what is written. Nothing more.
If a pattern is broken and undocumented, the agent copies the broken pattern. If a decision was made in a Slack thread that nobody saved, the agent has no access to it. If your token naming is inconsistent, the agent interprets the inconsistency as intent.
This is not a new problem. It is the oldest Design Systems problem, running faster and at greater scale than ever before.
Rules still come first
I have moved my work from one tool to another a Million times. Corel to Flash, from Flash to Photoshop, from Photoshop to Fireworks, from Fireworks to Sketch, from Sketch to Figma. Each move felt significant at the time. Each tool changed how I worked, what I could do, how I communicated with developers.
None of them changed what came first.
Rules. Then processes. Then tools.
This remains true in the era of AI. I hear conversations every day about which AI tool is the right one: Cursor or Claude, Lovable or something else, GitHub Copilot or a custom agent. These are not the wrong conversations. But they are the third conversation. The first conversation is: what are the rules your system operates by? What are the agreements? What is the source of truth?
An AI agent given access to a poorly governed Design System will not fix it. It will accelerate it. The entropy compounds faster. The inconsistencies multiply with every generation. Governance has never mattered more than it does right now, precisely because the tools are so powerful.
Adoption of a Design System will be easier with AI. Any developer can now use a well-documented component without deep system knowledge: the agent can translate the intent into correct code. But diverging from the Design System will be easier too. Anyone can generate a bespoke component in seconds. The pull away from the system is faster than it has ever been.
Direction, governance, and vision are not administrative overhead. They are the product.
What it means to build for a reader who cannot ask questions
A Design System that can be read by agents needs the same thing as one that can be read by developers from a different country, speaking a different language, working in a different codebase: explicit decisions, structured naming, and documentation that does not assume shared context.
The token work is the foundation.
Semantic naming is not an aesthetic preference. It is the contract. The agent needs to know not just what colour to use, but why that colour exists, what surface it belongs to, what it signals to the user. Tokens without semantics are just variables. Semantics without documentation are just intentions.
The agent needs to know what to reuse and what to respect.
For reuse: examples for every component, clear prop definitions and types, and test coverage that confirms the component behaves as specified. Without this, the agent defaults to whatever pattern it has seen most often in the wild. And the most common pattern on the web is not your brand. It is everyone else’s.
For respect: automated tests that catch regressions, and human sign-off before components reach production, which is not a bottleneck but where the agreement gets enforced.
Documentation is easier to produce than it has ever been.
An AI can generate documentation for a component in seconds. The problem is maintenance. The problem is changelogs. Current AI workflows do not track history. They do not know that this component used to work differently, or why the decision was made to change it. Documentation that cannot be maintained is not documentation. It is debt that looks like progress.
The organisations that will build the best agentic Design Systems are the ones that treat documentation as infrastructure, not output. That means versioning, changelogs, decision records, and a culture of writing down not just what, but why.
AI earns its place. Just not at the top of the org chart.
There is a version of the AI-first workflow story that goes like this: AI generates the options, AI selects the best one, AI ships the result. Humans review, optionally, when there is time.
IMO, that’s the wrong version. Not because AI is unable to generate good options: it can, and watching it work is genuinely remarkable. But because taste is not a filter applied at the end of a process. Taste is the process. And taste is where brand lives.
If you let the machine decide which of its own outputs is best, you will get competent, legible, optimised experiences that look like everything else on the web. The homogenisation of digital products is not a distant risk. It is already visible. It is what happens when every team uses the same tools, the same models, and the same defaults, without a human in the room who has a point of view.
The human’s job in an AI-first workflow is not to approve or reject. It is to set direction, hold the brand, and make the calls that the machine cannot make: not because the machine is incapable of generating an answer, but because the answer requires conviction, not calculation.
Here is what only humans can do in this new model.
Adoption. Building a Design System that people actually use requires humans to trust that other humans are going in the right direction. You cannot automate that trust. I have seen it at every scale: Developers by a coffee machine at eDreams, ten brands across four verticals at Adevinta Spain, twenty builders and hundreds of consumers across four countries at Spark. The technology was never the hardest part. The belief was.
Agreements under conflict. When a team is divided on a direction: which pattern to adopt, which brand aesthetic to commit to, which tradeoff to accept, a machine will give you its most statistically likely answer. But organisations do not run on statistical likelihood. They run on intentions and agreement. And that requires a human to say: we are going this way, and I am accountable for that decision.
Visibility and advocacy. An agent can generate a dashboard, track adoption metrics, produce a report. What it cannot do is walk into a room full of sceptical designers, PMs, and engineers and make them believe the system is worth committing to. That is a human activity. It always has been.
The craft itself. There is something about how we design together: in a shared canvas, handing work between collaborators, watching someone else continue what you started, that is core to the profession. AI agents can do something that looks like this. But they are taking out the experience of designing. The friction of collaboration is not inefficiency. It is where the ideas improve.
The greatest moment for the craft
None of this makes me pessimistic about AI. It gives me clear confidence: This is the greatest moment in the history of our craft.
For as long as I have been designing, there has been a drawer. Every team has one, physical or metaphorical. It is where the good ideas go when development capacity runs out. The beautiful flow that was too expensive to build. The interaction that was technically correct but nobody had time to code. The experience that would have been spectacular and never shipped because the cost was prohibitive.
That drawer won’t be needed anymore. The distance between an idea and a working prototype has collapsed. Designing spectacular experiences is no longer expensive. It is fast. What was a constraint of resources is becoming a constraint of imagination only.
The constraints that shaped how we worked are falling away one by one. Designers will finally work with real data: actual content, actual users, actual edge cases, not representative samples and placeholder text. The blank page is disappearing, replaced by ten starting points in the time it used to take to open a new file. And the pitch deck is ending. Everything can now be a living prototype. A design leader in a strategy meeting can show, not tell.
In a world where everyone can ship, the rarest thing is not execution. It is vision. When any developer with an AI agent can build a functional interface in an afternoon, the question is no longer can we build it. It is should we, and does it feel like us, and does it serve our users better than what we had yesterday.
Designers will not lead with prototypes in this era. They will lead with direction. With opinion. With the kind of point of view that makes other people want to follow. Ideas matter more than ever. Not the ability to execute them: that gap has narrowed dramatically. The ones that will define products and brands are the good ones. The original ones. The ones that require a point of view about the world, not a statistical model of what has been done before.
It is still about people
There is something that I think will finally get fixed, and that has frustrated me for most of my career: the tension between design and development. Between platforms and languages. Between the Figma file and the pull request. That tension existed because the translation was expensive and error-prone. The handoff was where intent went to die. AI does not eliminate that gap, but it compresses it in ways that make real collaboration possible for the first time. We are not there yet. But I can see it from here.
I wrote years ago that a Design System is not a Figma file. It is an agreement.
That definition has not aged. If anything, it has become more load-bearing. The system is now not only the agreement between designers and developers, between platforms and languages, between the brand and the product. It is the agreement that tells the machine what to do. The rules the agent follows when no human is watching.
Building a Design System that can scale is as hard as it has ever been. Not because the technology is harder: the technology is extraordinary, and it is only going to get better. But because the technology is only as good as the agreements behind it. And agreements are made by humans, between humans, in rooms where someone has to say: this is the direction, and I am responsible for it.
I do not have all the answers for what comes next. I do not think anyone does.
What I have is twenty-five years in design, nine of them building these systems, at every scale they come in. In companies that were growing and companies that were splitting. With two people and with twenty. Across four countries and four brands and too many Slack threads to count.
And what I know is this: when the system is working, it goes quiet. The friction disappears. The arguments stop. The developers build without worrying about the CSS. The designers focus on the next problem instead of re-solving the last one.
That silence is still what we are building towards. The same silence as before.
Just, now, with more readers in the room.
Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.