Designing for humans and agents · LAB

Everyone is talking about AI in design. Few show what really happens when you use it seriously, on a product you need to maintain for months. At our November Runroom LAB, Agostina Lotierzo, AI Design System Designer at Manychat, and Thành Đỗ Long, iOS Developer on the same team, told that story from both sides of the table: design and engineering.

They opened with a warning that applies to everything that follows: this is their experience today. "This is not written in stone. Everything evolves and changes from week to week," said Agostina. And they offered three ideas to take home: how design and engineering work together, why they didn't kill Figma, and how to build a design system that agents can read.

The starting point: a design system with two kinds of users

Agostina has contributed to five design systems. This is the first one she leads full time, and the first one with a new audience: "It's the first time that the users are not only people, but also machines."

Before AI, the process was the usual one. She prepared the spec, handed it to the developers and every weekly meeting brought surprises. Their example says it all: the semantic colours proposal for mobile went into review on 28 January and was still being discussed in March. More than five weeks to close a decision that had to go through design, engineering, product and brand.

This year, two changes arrived at once. On one side, the chance to build a design system from scratch, much closer to the Manychat brand. On the other, the AI-native wave: the company asked every team to leave their old ways of working behind and adopt tools such as Claude or Codex.

What broke: slop and AI without taste

The first lesson came quickly. If the design system has to serve an agent, the agent needs to understand what is being built. And that's where a deeper problem appears, in Thành's words: "AI doesn't have a taste." It is trained on a huge amount of information and leans towards what most people like. For the result to carry human judgement, the voice and tone have to be written down in the repository itself.

On the design side, AI looked like the great liberation. Agostina, who until then fixed the UI through screenshots, got a GitHub account, learned to clone the repository and started opening pull requests with Claude's help. Today she has more than 300 contributions. "It was scary, trust me," she admitted.

The problem came when she left too many decisions in the hands of AI. She described a typical conversation: she asks for a red destructive button, then a lighter one, then a grey one for accessibility. To everything, the AI replies "you're absolutely right". And the result was still wrong. That's how the slop grenades arrived: AI-generated changes, undocumented and unreviewed, that end up contradicting the system's rules. In their case, a colour reserved for borders ended up being used on surfaces.

Thành summed it up as the difference between vibe coding and agentic programming. Vibe coding works for a personal project. For something you need to scale, "for the first time it can look right", until you check dark mode, larger text or contrast. Agentic programming uses AI to speed up your work while keeping your own voice.

How to build a design system that agents can read

The core idea of the technical part: documentation used to be for developers, and now machines need to read it too. Thành shared the lessons that have worked for them:

• When the agent gets it wrong, look for the cause before fixing the output. In their case, the documentation mentioned a component that didn't exist yet and the agent improvised a workaround. If you only fix the result, it will fail again next time. Ask it why it did it that way and fix the source.
• Give every token context. "Blue 300" tells an agent nothing. A semantic token such as color.background.warning already points to its use. And you can go further with intents: what it's for (banners, inline alerts), what it's not for (errors) and what it pairs with.
• Automate the repetitive work. When design changes a foundation token in Figma, an agent detects the change and opens a first pull request. Once Thành approves it, another process automatically generates the ones for iOS, Android and web. Work that used to take him days.
• One single source of truth. A registry file in the repository holds the status of every component. When it changes, the documentation, the showcase app and the manifest the agent reads first all update on their own. If something drifts, the system warns them.
• Put barriers before human review. AI-generated PRs are long and nobody can read everything. So they first go through several filters: the decisions documented by design, the compiler and the linter. That way the human can focus on what matters: is this what we want or not?

In the Q&A they added a nuance about documentation: the files for agents are structured (JSON or YAML) and kept in sync with the documentation for people and with the continuous integration pipelines. For designers, the source of truth is still Figma. For agents and engineering, it's the repository.

Why they went back to Figma

The talk opened with something a Manychat designer said a few months ago: they would rather die than go back to Figma. Today they've changed their mind. Agostina explained why the team went back, with four reasons:

1. Reinventing the wheel. Convinced that Figma was dead, they built their own space for handoff. It looked amazing. The developers didn't like it, and collecting feedback on a full prototype, screen by screen, became very hard.
2. Token burn. "No one talks about it" in those LinkedIn and Twitter posts about apps shipped in two hours: working this way is very expensive if you don't know how to prompt efficiently.
3. Slowness in the details. Asking by text for two or four more pixels of padding took minutes and still came out wrong. In Figma it takes two seconds.
4. Lack of taste. What the AI produced didn't satisfy them visually. One day they stopped, opened a Figma file and worked side by side for a week. The resulting redesign amazed the stakeholders.

Today their workflow combines the best of both. Agostina starts in Claude, connected to Linear, Drive, Slack, Notion and their research sources, to prepare the brief, frame the problem and explore with prototypes. Once the direction is clear, she moves to Figma for the final screens, the edge cases and fine-tuning by hand, with a plugin that connects Claude and Figma. That plugin, she said, cut their token spend by around 80%. When she's done, she publishes the library and opens the pull request herself for engineering to review. Documenting a component, which used to take her two weeks, now takes minutes.

The demo: an agent that knows the rules

In the demo, recorded on purpose "because every time someone does a live demo with AI, something breaks", Agostina created a button component in a new Figma file. The agent used the design system's semantic variables and respected the documented naming. "Every decision here has a doc behind it."

Then she tried to break the rules: she asked for a pink primary button. The agent warned her that it contradicted the system's decisions and didn't pass accessibility. It knows this thanks to ADRs (Architecture Decision Records), documents that explain the why behind each decision. They're what lets the AI answer whoever comes later asking why something is the way it is.

Lessons and conclusions

They closed with four ideas, which started out as three:

• Get closer to the code. If you're a designer, the code is within your reach today, whether you want it or not. It helps you design more carefully, because everything you hand off has a cost for whoever receives it.
• Don't let AI drive the car. "Imagine that AI is a super smart person and at the same time a six-year-old kid who you need to explain what you expect." You decide how it looks and how it tastes. AI speeds things up.
• Write documentation that AI can read. It's the condition for the agent to work the way you expect.
• Give tools that put designers in control another chance. Agostina confessed that at first she was afraid AI would take her job. The slop grenades proved her wrong.

The result, in numbers: building a design system used to take them between six months and a year. This time, in ten days the whole company had foundations, components and molecules to start building product. And product managers can validate ideas with those components without waiting for design, with the final decision still in the design team's hands.

The underlying message was one of humility. "What we just said can be outdated in the next couple of weeks," Thành insisted. His advice: find your own path, use AI to empower what you already do and be wary of anyone promising a design system in one day. They've already announced their next challenge: migrating the previous design system to the new one, because working on an existing product is harder than starting from scratch.

Runroom LAB is a free, in-person monthly event. You need to sign up to save your spot. Now also on streaming!