Design system para agentes de IA: como manter a marca no código

Peça para uma IA criar um botão e ela cria. Peça de novo, em outra conversa, e ela cria outro: um pouco mais arredondado, num azul um pouco diferente, com outro espaçamento. Depois de vinte telas, o produto parece ter sido feito por vinte pessoas que nunca se falaram.

Luke Wroblewski, que trabalha com design systems há mais de 20 anos, descreveu esse risco num texto de 1º de outubro de 2026: “Each of their agents will happily implement its own tone and voice, colors, spacing, etc.” Cada agente implementa, de bom grado, seu próprio tom, suas cores, seu espaçamento. A resposta dele é tratar o design system como o manual que os agentes leem.

O que muda quando quem lê o design system é um agente

Todo designer sabe a frustração: você documenta o design system com cuidado e quase ninguém lê. Wroblewski aponta a virada com uma frase curta: “Agents read it every single time.” O agente lê a documentação toda vez.

Por isso ele define o design system para agentes como “a steering layer for a site’s design and front-end code”. Uma camada de direção. Em vez de um documento que fica desatualizado, o design system passa a guiar, em tempo real, o que cada agente escreve.

O modelo é colaborativo. Os líderes de design e de front-end definem uma vez o grid, as fontes, as cores, o espaçamento e os componentes. A partir daí, o agente de cada pessoa do time trabalha dentro dessas regras.

As três peças: tokens, AGENTS.md e Figma via MCP

No texto, Wroblewski usa como exemplo o site da Intent. Dá para separar o que ele descreve em três peças.

Tokens

Uma folha de estilo global define cores, fontes, tamanhos de texto, o grid responsivo e os temas claro e escuro como valores nomeados e compartilhados. O agente não escolhe um azul: ele usa a variável do azul da marca.

AGENTS.md

Arquivos de instrução dizem aos agentes para reaproveitar as classes de tema e as variáveis de CSS que já existem, em vez de duplicar valores. No exemplo da Intent, um botão novo reaproveita o componente Button existente e se adapta ao modo escuro sem ninguém pedir.

Figma via MCP

O design system da Intent começou como especificação no Figma, levada ao código por uma conexão MCP com o Figma. Depois disso, o código virou a fonte da verdade, e não foi preciso que os agentes escrevessem mudanças de volta no Figma.

Ele cita ainda dois projetos, Sol e Aria, em que as páginas de documentação do design system são geradas a partir do mesmo código dos sites. Assim, a documentação nunca fica para trás.

Por que isso importa para um founder

Marca inconsistente não é só um problema estético. É um problema de confiança. Um usuário que vê três estilos de botão no mesmo fluxo começa a desconfiar do produto, mesmo sem saber explicar por quê.

E há um custo escondido: cada componente duplicado é código duplicado. Cada vez que você quiser mudar a cor da marca ou o raio dos cantos, vai precisar caçar todas as versões. O design system para agentes resolve os dois problemas no mesmo lugar.

Como mantemos a IA dentro da marca no Studio

No Studio, usamos Claude Code e Figma no design e no build. O princípio que seguimos é o mesmo que Wroblewski descreve: a IA escreve, mas dentro de regras que nós definimos antes.

O caminho, em linhas gerais:

1. A marca vira variável antes de virar tela. Cores, tipografia e espaçamento entram no Figma como variáveis. [Estrutura de coleções de variáveis que o Studio usa, por exemplo primitivos e semânticos: Leonel completar.]
2. Os componentes principais nascem no Figma. [Confirmar: botão, campo, card, modal, navegação, cada um com seus estados.]
3. O código recebe os mesmos nomes. [Confirmar: os tokens do Figma viram variáveis no código com os mesmos nomes, para que design e build falem a mesma língua.]
4. O repositório tem instruções para o agente. [Conteúdo típico do arquivo de instruções do Studio para o Claude Code, como regras de reaproveitamento de componentes e proibição de valores soltos: Leonel completar.]
5. Revisão antes de entrar. [Confirmar: todo código gerado é revisado, e um valor de cor solto ou um componente duplicado é tratado como erro, não como detalhe.]

[Como o Studio conecta o Figma ao Claude Code via MCP e qual é a fonte da verdade em cada fase do projeto: Leonel completar.]

Checklist rápido para o seu produto

Se você já tem um produto feito com IA, estas perguntas mostram se a marca está sob controle:

• As cores do produto vêm de variáveis nomeadas ou estão escritas direto em cada tela?
• Existe um único componente de botão, ou vários parecidos?
• Mudar a fonte da marca exige editar um arquivo ou cinquenta?
• O repositório tem instruções que o agente de código lê antes de trabalhar?
• O modo escuro, se existir, funciona em todas as telas sem ajuste manual?

Se a resposta for ruim em mais de duas, o design system não está guiando a IA. Ela está guiando o design.

O que isso muda para você

Com IA no build, o design system deixou de ser documentação para a equipe e virou instrução para a máquina. Isso torna o investimento nele mais barato de manter e mais caro de ignorar.

Quando entregamos um sistema, ele sai com as regras da marca dentro do código, com preço fechado depois do diagnóstico e prazo escrito no contrato. E todo sistema sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido.

Se você vai construir um sistema ou SaaS com IA e quer que a última tela tenha a mesma cara da primeira, é assim que o Studio monta o seu produto.