Ensinando dois sistemas de design a se comunicarem: como usei agentes de IA para reduzir um processo de 36 para 1 hora de trabalho
Wave é uma plataforma online que facilita a gestão de serviços essenciais, ajudando empresas a venderem e gerenciarem planos de celular e internet. Ela oferece ferramentas simples para controlar o uso da rede, cobrar os clientes e criar experiências digitais fáceis de usar.
Visão geral
A Wave desenvolve produtos digitais para clientes de telecom, cada um com seu próprio design system, enquanto a implementação acontece sobre a sua biblioteca interna de blocos. Nessa estrutura, todo handoff exige uma tradução entre duas linguagens: no design system do cliente, um componente é uma unidade completa; na biblioteca interna, ele se decompõe em blocos menores, cada um com propriedades e atributos próprios.
Essa tradução era feita manualmente e o processo envolvia: identificar os blocos de cada componente, mapear propriedades, documentar tudo no Figma e repassar aos desenvolvedores para a geração dos JSONs de implementação. Um trabalho repetitivo que consumia cerca de 36 horas da minha semana, quase uma dedicação exclusiva.
Desenhei uma orquestração de agentes com o Claude que executa essa tradução de ponta a ponta, da leitura da biblioteca à documentação final no Figma, por meio de um plugin que também construí. O mesmo processo passou a levar 1 hora, às vezes menos, com revisão humana como etapa permanente.

Aprendizados
Automatizar não era a palavra certa
Meu primeiro instinto foi pedir ajuda aos desenvolvedores para escrever um script que fizesse a correspondência entre componentes do Figma e blocks. Era o caminho que me parecia mais óbvio para diminuir um trabalho repetitivo.
O problema é que os dois sistemas funcionam com lógicas diferentes. No design system do cliente, um componente é uma unidade completa. Na nossa biblioteca, esse mesmo componente pode se quebrar em vários blocks ou simplesmente não ter equivalente nenhum. Não existe correspondência direta para um script seguir.
Um script segue regras, e o que o problema pedia era interpretação de contexto. Foi essa constatação que me levou à orquestração de agentes com o Claude. Não parti do domínio da ferramenta, parti do diagnóstico: aquele problema precisava de uma solução que raciocinasse, não bastava apenas executar um conjunto de regras encadeadas.

Como um componente é 'quebrado' em blocks.
Um tradutor que entende gramática, não um dicionário
A lógica central da orquestração: o agente lê a biblioteca inteira de blocks, com propriedades, variantes e regras, e depois lê o componente do cliente. Em vez de buscar uma correspondência de um para um, ele desmonta o componente até a menor unidade possível e o reconstrói usando o vocabulário dos blocks.
O trabalho se divide entre três agentes, cada um com um papel:
Quando um block ou propriedade não existe na biblioteca, a agente não ignora: sinaliza e documenta em uma planilha. Esse mapa de gaps virou parte do processo e alimenta uma decisão futura, avaliar se vale criar blocks novos ou repensar a abordagem.
Processo de orquestração dos agentes.
A revisão humana é parte do sistema
Os agentes erram. Não com frequência, mas erram, especialmente em componentes muito customizados, onde a distância entre as duas linguagens é grande demais para uma interpretação sem ruídos. O caso mais comum: quando o espaçamento de um autolayout do Figma está definido como "auto", o agente interpreta como zero, e os blocks aparecem colados na renderização. Erro pequeno, regular o suficiente para estar no radar, e hoje corrigido manualmente.
Por isso a revisão final continua sendo minha: depois que a documentação é gerada, reviso o output, ajusto o que não foi encontrado na API e concluo. O objetivo nunca foi eliminar o julgamento do time, foi eliminar o trabalho mecânico que consumia a semana.
No fim, a IA fez o trabalho pesado, mas o design do processo foi 100% humano: as regras de comparação, a estrutura do output, os casos de exceção. Pensar bem no problema antes de escolher a ferramenta foi o que viabilizou tudo.
Veja também o meu artigo no Medium, em que eu conto o processo com mais detalhes.
Impacto
Cajá ・ Senior Product Designer ・ 2026
Ensinando dois sistemas de design a se comunicarem: como usei agentes de IA para reduzir um processo de 36 para 1 hora de trabalho
Wave é uma plataforma online que facilita a gestão de serviços essenciais, ajudando empresas a venderem e gerenciarem planos de celular e internet. Ela oferece ferramentas simples para controlar o uso da rede, cobrar os clientes e criar experiências digitais fáceis de usar.
Visão geral
A Wave desenvolve produtos digitais para clientes de telecom, cada um com seu próprio design system, enquanto a implementação acontece sobre a sua biblioteca interna de blocos. Nessa estrutura, todo handoff exige uma tradução entre duas linguagens: no design system do cliente, um componente é uma unidade completa; na biblioteca interna, ele se decompõe em blocos menores, cada um com propriedades e atributos próprios.
Essa tradução era feita manualmente e o processo envolvia: identificar os blocos de cada componente, mapear propriedades, documentar tudo no Figma e repassar aos desenvolvedores para a geração dos JSONs de implementação. Um trabalho repetitivo que consumia cerca de 36 horas da minha semana, quase uma dedicação exclusiva.
Desenhei uma orquestração de agentes com o Claude que executa essa tradução de ponta a ponta, da leitura da biblioteca à documentação final no Figma, por meio de um plugin que também construí. O mesmo processo passou a levar 1 hora, às vezes menos, com revisão humana como etapa permanente.

Aprendizados
Automatizar não era a palavra certa
Meu primeiro instinto foi pedir ajuda aos desenvolvedores para escrever um script que fizesse a correspondência entre componentes do Figma e blocks. Era o caminho que me parecia mais óbvio para diminuir um trabalho repetitivo.
O problema é que os dois sistemas funcionam com lógicas diferentes. No design system do cliente, um componente é uma unidade completa. Na nossa biblioteca, esse mesmo componente pode se quebrar em vários blocks ou simplesmente não ter equivalente nenhum. Não existe correspondência direta para um script seguir.
Um script segue regras, e o que o problema pedia era interpretação de contexto. Foi essa constatação que me levou à orquestração de agentes com o Claude. Não parti do domínio da ferramenta, parti do diagnóstico: aquele problema precisava de uma solução que raciocinasse, não bastava apenas executar um conjunto de regras encadeadas.

Como um componente é 'quebrado' em blocks.
Um tradutor que entende gramática, não um dicionário
A lógica central da orquestração: o agente lê a biblioteca inteira de blocks, com propriedades, variantes e regras, e depois lê o componente do cliente. Em vez de buscar uma correspondência de um para um, ele desmonta o componente até a menor unidade possível e o reconstrói usando o vocabulário dos blocks.
O trabalho se divide entre três agentes, cada um com um papel:
Quando um block ou propriedade não existe na biblioteca, a agente não ignora: sinaliza e documenta em uma planilha. Esse mapa de gaps virou parte do processo e alimenta uma decisão futura, avaliar se vale criar blocks novos ou repensar a abordagem.
Processo de orquestração dos agentes.
A revisão humana é parte do sistema
Os agentes erram. Não com frequência, mas erram, especialmente em componentes muito customizados, onde a distância entre as duas linguagens é grande demais para uma interpretação sem ruídos. O caso mais comum: quando o espaçamento de um autolayout do Figma está definido como "auto", o agente interpreta como zero, e os blocks aparecem colados na renderização. Erro pequeno, regular o suficiente para estar no radar, e hoje corrigido manualmente.
Por isso a revisão final continua sendo minha: depois que a documentação é gerada, reviso o output, ajusto o que não foi encontrado na API e concluo. O objetivo nunca foi eliminar o julgamento do time, foi eliminar o trabalho mecânico que consumia a semana.
No fim, a IA fez o trabalho pesado, mas o design do processo foi 100% humano: as regras de comparação, a estrutura do output, os casos de exceção. Pensar bem no problema antes de escolher a ferramenta foi o que viabilizou tudo.
Veja também o meu artigo no Medium, em que eu conto o processo com mais detalhes.
Impacto
Ensinando dois sistemas de design a se comunicarem: como usei agentes de IA para reduzir um processo de 36 para 1 hora de trabalho
Wave é uma plataforma online que facilita a gestão de serviços essenciais, ajudando empresas a venderem e gerenciarem planos de celular e internet. Ela oferece ferramentas simples para controlar o uso da rede, cobrar os clientes e criar experiências digitais fáceis de usar.
Visão geral
A Wave desenvolve produtos digitais para clientes de telecom, cada um com seu próprio design system, enquanto a implementação acontece sobre a sua biblioteca interna de blocos. Nessa estrutura, todo handoff exige uma tradução entre duas linguagens: no design system do cliente, um componente é uma unidade completa; na biblioteca interna, ele se decompõe em blocos menores, cada um com propriedades e atributos próprios.
Essa tradução era feita manualmente e o processo envolvia: identificar os blocos de cada componente, mapear propriedades, documentar tudo no Figma e repassar aos desenvolvedores para a geração dos JSONs de implementação. Um trabalho repetitivo que consumia cerca de 36 horas da minha semana, quase uma dedicação exclusiva.
Desenhei uma orquestração de agentes com o Claude que executa essa tradução de ponta a ponta, da leitura da biblioteca à documentação final no Figma, por meio de um plugin que também construí. O mesmo processo passou a levar 1 hora, às vezes menos, com revisão humana como etapa permanente.

Aprendizados
Automatizar não era a palavra certa
Meu primeiro instinto foi pedir ajuda aos desenvolvedores para escrever um script que fizesse a correspondência entre componentes do Figma e blocks. Era o caminho que me parecia mais óbvio para diminuir um trabalho repetitivo.
O problema é que os dois sistemas funcionam com lógicas diferentes. No design system do cliente, um componente é uma unidade completa. Na nossa biblioteca, esse mesmo componente pode se quebrar em vários blocks ou simplesmente não ter equivalente nenhum. Não existe correspondência direta para um script seguir.
Um script segue regras, e o que o problema pedia era interpretação de contexto. Foi essa constatação que me levou à orquestração de agentes com o Claude. Não parti do domínio da ferramenta, parti do diagnóstico: aquele problema precisava de uma solução que raciocinasse, não bastava apenas executar um conjunto de regras encadeadas.

Como um componente é 'quebrado' em blocks.
Um tradutor que entende gramática, não um dicionário
A lógica central da orquestração: o agente lê a biblioteca inteira de blocks, com propriedades, variantes e regras, e depois lê o componente do cliente. Em vez de buscar uma correspondência de um para um, ele desmonta o componente até a menor unidade possível e o reconstrói usando o vocabulário dos blocks.
O trabalho se divide entre três agentes, cada um com um papel:
Quando um block ou propriedade não existe na biblioteca, a agente não ignora: sinaliza e documenta em uma planilha. Esse mapa de gaps virou parte do processo e alimenta uma decisão futura, avaliar se vale criar blocks novos ou repensar a abordagem.
Processo de orquestração dos agentes.
A revisão humana é parte do sistema
Os agentes erram. Não com frequência, mas erram, especialmente em componentes muito customizados, onde a distância entre as duas linguagens é grande demais para uma interpretação sem ruídos. O caso mais comum: quando o espaçamento de um autolayout do Figma está definido como "auto", o agente interpreta como zero, e os blocks aparecem colados na renderização. Erro pequeno, regular o suficiente para estar no radar, e hoje corrigido manualmente.
Por isso a revisão final continua sendo minha: depois que a documentação é gerada, reviso o output, ajusto o que não foi encontrado na API e concluo. O objetivo nunca foi eliminar o julgamento do time, foi eliminar o trabalho mecânico que consumia a semana.
No fim, a IA fez o trabalho pesado, mas o design do processo foi 100% humano: as regras de comparação, a estrutura do output, os casos de exceção. Pensar bem no problema antes de escolher a ferramenta foi o que viabilizou tudo.
Veja também o meu artigo no Medium, em que eu conto o processo com mais detalhes.
Impacto
Cajá ・ Senior Product Designer ・ 2026