Construindo o Lastro, o design system AI-First da Barte

O problema que todo time enxuto conhece

A Barte é uma empresa que cresce de forma acelerada, e nosso ecossistema digital cresce junto. Com o tempo, acumulamos uma série de dívidas de experiência, como variações de componentes parecidos mas não iguais, espaçamentos decididos no olho e telas reinventando padrões que já existiam em outras partes do produto.

Mosaico de componentes e telas dos portais da Barte antes da padronização — botões, tabelas e cards com variações — Mapeamento inicial de inconsistências de componentes entre produtos

A solução começou pela visão de produto

Antes de escrever qualquer linha de código ou definir a solução, o primeiro passo foi definir uma visão de produto. Precisávamos normalizar a experiência entre os nossos portais e estabelecer um padrão visual de interface: o que é a cara da Barte, como nossos produtos se comportam, o que o usuário pode esperar de consistência ao navegar entre eles.

O design system apareceu como a resposta natural a essa visão, pois é a forma mais consistente e eficiente de sustentar esse padrão pensando na escala do produto. A questão passou a ser como construí-lo.

A resposta tradicional seria montar uma squad dedicada (designer + devs), reservar de 6 a 8 meses e construir componente por componente. Não tínhamos nem o time nem o tempo. Então meu plano foi partir para outra abordagem.

Telas dos portais da Barte — Tesouraria, Gestão de POS e pagamentos — demonstrando o padrão visual unificado — Primeira versão de visão de design dos produtos

Era final de 2025 e o assunto do momento na comunidade de design era construir um design system em 2 horas. Acredito que via magia negra. Então aprofundei pesquisas, conversei com algumas pessoas no mercado e contratamos uma pessoa especialista para nos ajudar no projeto.

O objetivo era construir um design system que atendesse nossa necessidade atual, com o princípio de usar IA para fazer o trabalho de volume e concentrar o esforço humano em arquitetura e decisão.

Dois meses depois, nascia o Lastro, o design system da Barte: 23 componentes documentados, mais de 10 mil linhas de código 100% TypeScript, arquitetura de tokens escalável e documentação viva no Storybook.

IA como dev, humano como arquiteto

Desde o início, tratamos a IA como um desenvolvedor muito rápido, que fosse bom em executar tarefas bem especificadas, mas sempre junto com um humano para decidir o que importa. Essa premissa definiu a divisão de trabalho:

Humano: arquitetura, decisões de design, especificação, QA e julgamento final.
IA (Claude): boilerplate, conversões repetitivas, testes, documentação. Tudo que fosse volume.

Chamamos isso de esteira de automação, onde cada etapa do processo tem um responsável claro, e a IA nunca opera sem uma especificação que ela consiga seguir.

Estados e variações do componente de botão do Lastro no Storybook — default, disabled e botões com ícones — Componente de botão: estados e variações com ícones

A arquitetura em duas camadas

Antes de automatizar qualquer coisa, precisávamos de uma fundação que suportasse escala. Separamos o sistema em duas camadas independentes:

Camada 1: Barte Design Tokens (a fundação) Um repositório agnóstico que guarda apenas a “verdade visual”: cores, tipografia, espaçamento. Usamos Style Dictionary para transformar essas decisões em variáveis consumíveis por qualquer plataforma.

Camada 2: Lastro (a lógica) Um repositório de componentes React que consome a camada 1. A lógica é desacoplada do estilo: se o branding mudar nos tokens, todo o sistema herda a mudança sem refatorar uma linha de componente.

Essa separação pode parecer excessiva para um time pequeno, mas é o que torna a automação segura: a IA pode gerar componentes à vontade, porque a fonte da verdade visual fica protegida em outra camada.

Componente de badge/pill do Lastro no Storybook — estados, variantes fill, light e ghost, e tamanhos — Componente de badge: estados, variantes e tamanhos

O pipeline: da variável no Figma ao pacote no NPM

Com a arquitetura no lugar, desenhamos um pipeline de cinco etapas que transforma decisão de design em código de produção:

1. Definição (Figma). Tudo começa com a estrutura semântica de variáveis e os componentes desenhados no Figma. Essa etapa é 100% humana, é onde as decisões de design acontecem.

2. Extração (Gladi, plugin próprio). Desenvolvemos o Gladi Export Tokens, um plugin que escaneia o Figma, converte unidades (px → rem) e gera automaticamente o JSON para o repositório de tokens, incluindo a paleta semântica. Um trabalho manual e propenso a erro virou um clique.

3. Orquestração (MCP + agente). Um servidor MCP conecta o Claude diretamente ao Figma. O agente lê a estrutura de nós do design e gera o boilerplate React já consumindo os tokens corretos, com cerca de 96% de precisão. O trabalho humano passa a ser revisão, não digitação.

4. Refinamento e testes. Enquanto ajustamos detalhes finos à mão, um segundo agente gera os testes unitários (Vitest) e a documentação de cada componente.

5. Publicação. O pipeline versiona o pacote, publica no NPM privado e atualiza o Storybook. O componente está disponível para qualquer portal da Barte no mesmo dia.

Especificação do componente Search do Lastro no Figma — anatomia, estados e layout com tokens de spacing — Componente de busca (Search): anatomia, estados e spacing

Skills: transformando processo em ativo reutilizável

No meio do caminho, percebemos que automatizar tarefas não bastava: precisávamos também estruturar o conhecimento sobre como fazer as tarefas.

Foi aí que entraram as skills do Claude. Uma skill é, na prática, um documento de processo que o agente carrega antes de trabalhar, como as regras do nosso design system, os tokens, os padrões de cada portal e o formato esperado de uma spec.

Hoje, nosso ciclo de design roda sobre um conjunto de skills encadeadas: discovery (transforma material bruto em brief), design (transforma brief em spec usando os componentes do DS), protótipo (gera a página React no repositório certo), review (crítica o protótipo como um UX sênior) e handoff (consolida tudo para engenharia).

Reparem que o design system deixa de ser só uma biblioteca de componentes e passa a ser a fonte da verdade para que pessoas e agentes usem para construir produto.

Isso revelou um efeito colateral valioso, que um design system bem estruturado é a melhor documentação possível para uma IA. Tokens semânticos, componentes tipados e regras explícitas são exatamente o tipo de contexto que faz um agente gerar código certo de primeira.

Tela de Financeiro do portal Seller da Barte construída com os componentes do Lastro — saldo, antecipação e extrato — Tela pronta: página de Financeiro construída sobre o Lastro

O que aprendemos

1. A IA amplifica a arquitetura que encontra, boa ou ruim. Sem a separação de camadas e a estrutura semântica de tokens, o agente geraria inconsistência em escala. A automação só funcionou porque a fundação era rígida.

2. Especificação virou o gargalo. Quando gerar código custa minutos, o tempo caro passa a ser decidir o que gerar. Investir em briefs, specs e skills bem escritas rendeu mais do que qualquer otimização de prompt.

3. O humano muda de função no processo. Ninguém do time escreveu menos: escrevemos coisas diferentes. Menos boilerplate, mais decisões. O papel de designer que coloca mão em código virou realidade na Barte.

4. Ferramentas próprias compensam rápido. O Gladi levou dias para ser construído e economiza horas toda semana. Quando a IA reduz o custo de criar ferramentas internas, o cálculo de “vale a pena construir?” muda completamente.

E por que “Lastro”?

O nome não foi por acaso, e carrega dois significados que se completam.

No sentido financeiro, lastro é o que dá valor e estabilidade a uma moeda. Fundação e confiança, exatamente o que pede uma infraestrutura de pagamentos como a Barte.

No sentido náutico, é o peso que mantém o navio estável. Uma metáfora ainda melhor para o que o design system faz, pois enquanto o produto avança rápido, é o Lastro que dá a estabilidade para não virar no caminho.

Próximos passos

O Lastro é um organismo vivo. Os próximos passos incluem expandir a cobertura de componentes, refinar a integração entre Figma x Código e, principalmente, evoluir skills e processos para que cada vez mais do ciclo de produto, do discovery ao handoff, rode sobre o mesmo vocabulário compartilhado entre pessoas e agentes.

E esse vai ser assunto para um próximo artigo!