PT

EN

BEMOBI WAVE

TELECOM

UTILITIES

IA

Teaching two design systems to communicate: how I used AI agents to reduce a process from 36 hours to 1 hour of work

Wave is an online platform that simplifies the management of essential services, helping companies sell and manage mobile and internet plans. It provides simple tools to control network usage, bill customers, and create easy-to-use digital experiences.

Overview

Wave develops digital products for telecom clients, each with its own design system, while implementation occurs over its internal block library. In this structure, every handoff requires a translation between two languages: in the client's design system, a component is a complete unit; in the internal library, it breaks down into smaller blocks, each with its own properties and attributes.

This translation was done manually, and the process involved: identifying the blocks of each component, mapping properties, documenting everything in Figma, and passing it to developers for generating the implementation JSONs. A repetitive task that consumed about 36 hours of my week, almost a full-time dedication.

I designed an orchestration of agents with Claude that executes this translation end-to-end, from reading the library to final documentation in Figma, through a plugin that I also built. The same process now takes 1 hour, sometimes less, with human review as a permanent step.

Learnings

Automating was not the right word

My first instinct was to ask developers for help in writing a script that would match components from Figma to blocks. It seemed the most obvious way to reduce repetitive work.

The problem is that the two systems operate on different logics. In the client's design system, a component is a complete unit. In our library, that same component can break into several blocks or simply have no equivalent. There is no direct mapping for a script to follow.

A script follows rules, and what the problem required was context interpretation. This realization led me to the orchestration of agents with Claude. I didn't start from the tool's mastery; I started from the diagnosis: that problem needed a solution that could reason, not just execute a set of chained rules.

How a component is 'broken' into blocks.

A translator that understands grammar, not a dictionary

The central logic of the orchestration: the agent reads the entire library of blocks, with properties, variants, and rules, and then reads the client's component. Instead of seeking a one-to-one match, it dismantles the component down to the smallest possible unit and reconstructs it using the vocabulary of the blocks.

The work is divided among three agents, each with a role:

Margaret inspects the file, generates the JSON for developers, and proposes new blocks when necessary;

Grace reviews the implementation and validates if everything follows the library standards, returning for correction when it does not;

Clarice documents the blocks in Figma and checks the properties against the file, ensuring that the documentation is a reliable source.

When a block or property does not exist in the library, the agent does not ignore it: it signals and documents it in a spreadsheet. This gap map became part of the process and feeds into a future decision, assessing whether to create new blocks or rethink the approach.

Agent orchestration process.

Human review is part of the system

The agents make mistakes. Not frequently, but they do, especially in highly customized components, where the distance between the two languages is too great for interpretation without noise. The most common case: when the spacing of an autolayout in Figma is set to "auto," the agent interprets it as zero, and the blocks appear glued in the rendering. A small error, regular enough to be on the radar, and now corrected manually.

That’s why the final review remains mine: after the documentation is generated, I review the output, adjust what was not found in the API, and conclude. The goal was never to eliminate the team's judgment; it was to eliminate the mechanical work that consumed the week.

In the end, AI did the heavy lifting, but the design of the process was 100% human: the comparison rules, the output structure, the exceptions. Thinking carefully about the problem before choosing the tool made everything possible.

Also, check out my article on Medium, where I detail the process.

Impact

  • From 36 weekly hours to 1 hour, with human review preserved as a step in the process.
  • 50% reduction in developers' implementation work, with JSONs generated in the complete structure using a direct plugin in Figma.
  • Gaps automatically mapped: what does not exist is signaled and documented in a spreadsheet, becoming input for the evolution of the block library.

PT

EN

BEMOBI WAVE

TELECOM

UTILITIES

IA

Teaching two design systems to communicate: how I used AI agents to reduce a process from 36 hours to 1 hour of work

Wave is an online platform that simplifies the management of essential services, helping companies sell and manage mobile and internet plans. It provides simple tools to control network usage, bill customers, and create easy-to-use digital experiences.

Overview

Wave develops digital products for telecom clients, each with its own design system, while implementation occurs over its internal block library. In this structure, every handoff requires a translation between two languages: in the client's design system, a component is a complete unit; in the internal library, it breaks down into smaller blocks, each with its own properties and attributes.

This translation was done manually, and the process involved: identifying the blocks of each component, mapping properties, documenting everything in Figma, and passing it to developers for generating the implementation JSONs. A repetitive task that consumed about 36 hours of my week, almost a full-time dedication.

I designed an orchestration of agents with Claude that executes this translation end-to-end, from reading the library to final documentation in Figma, through a plugin that I also built. The same process now takes 1 hour, sometimes less, with human review as a permanent step.

Learnings

Automating was not the right word

My first instinct was to ask developers for help in writing a script that would match components from Figma to blocks. It seemed the most obvious way to reduce repetitive work.

The problem is that the two systems operate on different logics. In the client's design system, a component is a complete unit. In our library, that same component can break into several blocks or simply have no equivalent. There is no direct mapping for a script to follow.

A script follows rules, and what the problem required was context interpretation. This realization led me to the orchestration of agents with Claude. I didn't start from the tool's mastery; I started from the diagnosis: that problem needed a solution that could reason, not just execute a set of chained rules.

How a component is 'broken' into blocks.

A translator that understands grammar, not a dictionary

The central logic of the orchestration: the agent reads the entire library of blocks, with properties, variants, and rules, and then reads the client's component. Instead of seeking a one-to-one match, it dismantles the component down to the smallest possible unit and reconstructs it using the vocabulary of the blocks.

The work is divided among three agents, each with a role:

Margaret inspects the file, generates the JSON for developers, and proposes new blocks when necessary;

Grace reviews the implementation and validates if everything follows the library standards, returning for correction when it does not;

Clarice documents the blocks in Figma and checks the properties against the file, ensuring that the documentation is a reliable source.

When a block or property does not exist in the library, the agent does not ignore it: it signals and documents it in a spreadsheet. This gap map became part of the process and feeds into a future decision, assessing whether to create new blocks or rethink the approach.

Agent orchestration process.

Human review is part of the system

The agents make mistakes. Not frequently, but they do, especially in highly customized components, where the distance between the two languages is too great for interpretation without noise. The most common case: when the spacing of an autolayout in Figma is set to "auto," the agent interprets it as zero, and the blocks appear glued in the rendering. A small error, regular enough to be on the radar, and now corrected manually.

That’s why the final review remains mine: after the documentation is generated, I review the output, adjust what was not found in the API, and conclude. The goal was never to eliminate the team's judgment; it was to eliminate the mechanical work that consumed the week.

In the end, AI did the heavy lifting, but the design of the process was 100% human: the comparison rules, the output structure, the exceptions. Thinking carefully about the problem before choosing the tool made everything possible.

Also, check out my article on Medium, where I detail the process.

Impact

  • From 36 weekly hours to 1 hour, with human review preserved as a step in the process.
  • 50% reduction in developers' implementation work, with JSONs generated in the complete structure using a direct plugin in Figma.
  • Gaps automatically mapped: what does not exist is signaled and documented in a spreadsheet, becoming input for the evolution of the block library.

PT

EN

BEMOBI WAVE

TELECOM

UTILITIES

IA

Teaching two design systems to communicate: how I used AI agents to reduce a process from 36 hours to 1 hour of work

Wave is an online platform that simplifies the management of essential services, helping companies sell and manage mobile and internet plans. It provides simple tools to control network usage, bill customers, and create easy-to-use digital experiences.

Overview

Wave develops digital products for telecom clients, each with its own design system, while implementation occurs over its internal block library. In this structure, every handoff requires a translation between two languages: in the client's design system, a component is a complete unit; in the internal library, it breaks down into smaller blocks, each with its own properties and attributes.

This translation was done manually, and the process involved: identifying the blocks of each component, mapping properties, documenting everything in Figma, and passing it to developers for generating the implementation JSONs. A repetitive task that consumed about 36 hours of my week, almost a full-time dedication.

I designed an orchestration of agents with Claude that executes this translation end-to-end, from reading the library to final documentation in Figma, through a plugin that I also built. The same process now takes 1 hour, sometimes less, with human review as a permanent step.

Learnings

Automating was not the right word

My first instinct was to ask developers for help in writing a script that would match components from Figma to blocks. It seemed the most obvious way to reduce repetitive work.

The problem is that the two systems operate on different logics. In the client's design system, a component is a complete unit. In our library, that same component can break into several blocks or simply have no equivalent. There is no direct mapping for a script to follow.

A script follows rules, and what the problem required was context interpretation. This realization led me to the orchestration of agents with Claude. I didn't start from the tool's mastery; I started from the diagnosis: that problem needed a solution that could reason, not just execute a set of chained rules.

How a component is 'broken' into blocks.

A translator that understands grammar, not a dictionary

The central logic of the orchestration: the agent reads the entire library of blocks, with properties, variants, and rules, and then reads the client's component. Instead of seeking a one-to-one match, it dismantles the component down to the smallest possible unit and reconstructs it using the vocabulary of the blocks.

The work is divided among three agents, each with a role:

Margaret inspects the file, generates the JSON for developers, and proposes new blocks when necessary;

Grace reviews the implementation and validates if everything follows the library standards, returning for correction when it does not;

Clarice documents the blocks in Figma and checks the properties against the file, ensuring that the documentation is a reliable source.

When a block or property does not exist in the library, the agent does not ignore it: it signals and documents it in a spreadsheet. This gap map became part of the process and feeds into a future decision, assessing whether to create new blocks or rethink the approach.

Agent orchestration process.

Human review is part of the system

The agents make mistakes. Not frequently, but they do, especially in highly customized components, where the distance between the two languages is too great for interpretation without noise. The most common case: when the spacing of an autolayout in Figma is set to "auto," the agent interprets it as zero, and the blocks appear glued in the rendering. A small error, regular enough to be on the radar, and now corrected manually.

That’s why the final review remains mine: after the documentation is generated, I review the output, adjust what was not found in the API, and conclude. The goal was never to eliminate the team's judgment; it was to eliminate the mechanical work that consumed the week.

In the end, AI did the heavy lifting, but the design of the process was 100% human: the comparison rules, the output structure, the exceptions. Thinking carefully about the problem before choosing the tool made everything possible.

Also, check out my article on Medium, where I detail the process.

Impact

  • From 36 weekly hours to 1 hour, with human review preserved as a step in the process.
  • 50% reduction in developers' implementation work, with JSONs generated in the complete structure using a direct plugin in Figma.
  • Gaps automatically mapped: what does not exist is signaled and documented in a spreadsheet, becoming input for the evolution of the block library.