Beta contrato de componentes para evitar drift de design com IA

O problema: drift entre design e código com IA no loop

A pergunta central do artigo é: qual é a verdadeira fonte de verdade no seu design system - os componentes no Figma ou o código no Storybook? Na teoria, ambos deveriam ser a mesma coisa. Na prática, com prazos apertados e pouca governança, design e implementação se afastam. A IA no loop tende a ampliar esse gap, não a fechá-lo.

Component Contracts como nova fonte de verdade

Christine Vallaure propõe os Design System Contracts: cada componente recebe uma descrição em linguagem natural - uma lista legível de propriedades, tokens, estados e interações. Sem visuais, sem código, apenas um acordo sobre o que o componente é.

Esses contratos se tornam a fonte de verdade. A partir deles, tanto a view no Figma quanto a implementação front-end são geradas automaticamente. A cada commit, um checker compara contrato, biblioteca Figma e código para sinalizar divergências.

Onde a IA entra - e onde sai

A maioria das tarefas de design system não precisa de IA: qual token de cor o botão primário usa, quais propriedades um card aceita, se Figma e código ainda estão alinhados. Como diz TJ Pitre, são "lookups determinísticos, não julgamentos probabilísticos".

A ideia é usar IA para autoria (produzir specs e extrair contratos) e depois tirá-la do caminho, deixando ferramentas determinísticas fazerem a enforcement. O resultado: output confiável toda vez, revisado por um checker não-AI.

Em um teste A/B, um agente sem governança construindo telas pontuou 69/100, com 90 violações, props inventadas, cores hardcoded e componentes reestilizados. O mesmo modelo, trabalhando a partir de um catálogo de contratos gerados, pontuou 100/100.

As seis camadas da experiência com IA

Emily Campbell propõe um modelo com seis camadas: Interface do Usuário, Contexto, Harness, Modelo, Governança e Emergência. O artigo destaca a camada Harness como crítica para garantir que a IA produza resultados dentro dos limites esperados.

Harness Engineering: guardrails determinísticos

Em vez de apenas dizer à IA para seguir regras (o que eventualmente falha), é preciso engenharia de guardrails determinísticos - o ambiente, as ferramentas e os feedback loops ao redor do modelo.

O artigo diferencia três práticas:

• Prompt engineering: molda o que o usuário diz ao modelo.
• Context engineering: molda o que o modelo pode ver.
• Harness engineering: molda o que o sistema pode e não pode fazer.

O objetivo não é explicar melhor as regras à IA, mas construir um ambiente onde o drifting seja pequeno, detectável e reversível.

Conclusão

Como resume TJ Pitre: autoridade pertence à camada que pode recusar deterministicamente, não à que instrui mais alto. Um modelo pode ser contornado por argumentos; um schema não. O futuro dos design systems pode ser AI-first em alguns momentos, mas não será AI-only - e isso é positivo: menos tokens, menos drift e design nas mãos de designers que estabelecem e fazem cumprir diretrizes.