Design system e IA: como manter consistência quando a máquina gera componente

Tem um problema novo aparecendo em times de produto que adotaram IA para acelerar a interface: a consistência visual começa a ruir sem que ninguém tenha decidido nada. Não é uma decisão errada — são cinquenta decisões pequenas, cada uma tomada por uma ferramenta que não sabia que existia um padrão.

O sintoma é fácil de reconhecer. De repente o produto tem quatro tons de cinza para borda, três raios de canto diferentes e dois estilos de botão secundário. Ninguém aprovou isso. Cada peça foi gerada isolada, ficou boa isolada, e o conjunto virou colcha de retalhos.

Por que a IA quebra design system por padrão

Um modelo generativo produz o que é estatisticamente comum. Ele não tem acesso ao seu tokens.json, à sua escala de espaçamento nem à decisão que o time tomou há oito meses de que sombra não é usada em lugar nenhum. Ele produz o botão médio da internet: canto de 6px, sombra suave, azul #3b82f6.

Cada peça isolada parece razoável. O problema é de sistema, não de peça — e sistema é exatamente o que o modelo não enxerga quando você pede um componente por vez. É a mesma razão pela qual um time de dez freelancers sem briefing produz dez interfaces diferentes, mesmo sendo todos competentes.

Consistência não é a soma de peças boas. É a consequência de restrições compartilhadas — e a IA não compartilha as suas se você não as der.

1. Torne os tokens parte do pedido, sempre

A correção mais direta: em vez de descrever o visual em palavras ("um card claro com borda sutil"), cole os tokens e mande usar só eles.

Um pedido que funciona tem esta cara: "Use exclusivamente estas variáveis: fundo --surface, texto --ink, borda --line, destaque --accent. Espaçamento apenas na escala 4/8/12/16/24/32. Raio apenas 4px, 8px ou 12px. Nenhuma sombra. Se precisar de um valor que não está nessa lista, pare e me pergunte."

A última frase é a mais importante e a mais esquecida. Sem ela, o modelo inventa um valor intermediário quando a escala não encaixa — e é assim que nasce o padding: 14px que não existe em lugar nenhum do sistema. Com ela, a falta vira uma pergunta em vez de uma exceção silenciosa.

2. Dê um componente existente como referência

Mais eficaz do que descrever regras é mostrar um exemplo. Cole o código de um componente que já está no padrão e peça: "escreva o novo componente seguindo exatamente as convenções deste aqui — mesma estrutura de classes, mesma nomenclatura, mesmo tratamento de estado."

O modelo é muito bom em imitação de padrão, e imitação é justamente o que você quer aqui. Um exemplo real carrega dezenas de convenções tácitas que você nunca conseguiria enumerar: como você nomeia as variantes, onde ficam os estados de foco, se você usa atributo de dado ou classe modificadora, como trata o caso desabilitado.

3. Proíba explicitamente o que costuma vazar

Existe uma lista curta de coisas que a IA insere sem ser pedida, em praticamente todo componente. Vale ter essa lista pronta e colar sempre:

• Gradiente onde deveria ser cor sólida.
• Sombra difusa e "glow" — o clichê número um de interface gerada.
• Transição em tudo, inclusive onde não há mudança de estado.
• Cor fora da paleta, tipicamente um azul ou roxo de destaque que ninguém pediu.
• Ícone inventado em SVG inline, em vez do conjunto que o projeto já usa.
• Bibliotecas novas para resolver algo que o seu CSS já resolve.

Uma lista de proibições explícita economiza mais revisão do que qualquer descrição positiva de estilo. É chato de escrever uma vez e você reusa para sempre.

4. Feche a porta na revisão, não no gosto

Regra no prompt ajuda, mas não garante nada — o modelo pode ignorar. O que garante é a verificação automática, e ela não precisa ser sofisticada. Duas checagens pegam quase tudo:

1. Busca por valor cru. Um comando que procura cor em hexadecimal e pixel fora da escala nos arquivos de estilo. Se apareceu #4f46e5 no lugar de var(--accent), alguém saiu do sistema.
2. Lista de valores distintos. Rode de tempos em tempos um levantamento de quantos raios de canto, quantas cores e quantos tamanhos de fonte o projeto realmente usa. O número deveria ser pequeno e estável. Quando ele começa a crescer sozinho, você tem a medida objetiva da erosão.

Essa segunda checagem é a que eu recomendo mais. Ela transforma "acho que o produto está ficando inconsistente" — uma discussão de opinião que ninguém ganha — em "tínhamos 6 tons de cinza em janeiro e temos 19 agora". Contra número não tem gosto pessoal.

5. Deixe a IA fazer o trabalho que o design system realmente precisa

Vale inverter a pergunta. Em vez de "como impedir que a IA quebre o sistema", pergunte onde ela ajuda o sistema — e a resposta é: em tudo que é chato e ninguém faz.

• Documentar componente: gerar a descrição de props, estados e quando usar cada variante, a partir do código. É a tarefa que sempre fica para depois.
• Achar duplicata: "estes dois componentes fazem a mesma coisa?" em uma base com 80 componentes.
• Escrever os estados que faltam: dado o componente no caso feliz, gerar as variações de carregando, erro, vazio e desabilitado seguindo o mesmo padrão.
• Migrar valores crus para tokens em código legado — trabalho mecânico, verificável e insuportável de fazer à mão.
• Checar contraste de todas as combinações de cor da paleta e apontar as que reprovam em acessibilidade.

Repare no padrão: em todas essas, o sistema já existe e a IA opera dentro dele. É aí que ela rende sem custar consistência.

O ponto que importa

Design system nunca foi sobre ter uma biblioteca de componentes bonita. Sempre foi sobre reduzir o número de decisões que cada pessoa precisa tomar — para que as decisões que sobram sejam as que importam. A IA multiplica a quantidade de decisões tomadas por unidade de tempo. Se essas decisões não estiverem restritas, ela multiplica a inconsistência na mesma proporção.

A conclusão prática é quase banal, mas vale dizer: quanto mais IA você usa na produção de interface, mais rigoroso o seu design system precisa ser. Ele deixa de ser documentação de boas intenções e vira restrição executável — tokens que existem no código, exemplos que servem de referência, verificação que roda sozinha. Sem isso, você não automatizou design: automatizou a produção de dívida visual.