O que foi medido
O texto, assinado por Cris Morales, descreve uma rodada de testes feita com o Open Design System Bench, ferramenta criada por Christoph Hellmuth que roda agentes de código contra uma biblioteca de componentes e dá nota ao que eles produzem. O formato do teste é três cenários, três repetições cada e dez tarefas de design, o que fecha noventa células de avaliação.
Cada célula olha para seis coisas: se o agente importou certo, se usou a API do componente como ela existe, se respeitou os tokens, se o resultado passa em acessibilidade, se compila, e um último eixo, chamado de julgamento, que é o único que não é mecânico.
O empate que diz muito
A consultoria rodou o mesmo teste no sistema que mantém e no Astryx, design system que a Meta desenvolveu internamente por oito anos e abriu em junho deste ano. O placar foi 95,68 contra 96,19, com as mesmas 77 células mecanicamente perfeitas nos dois.
Um sistema jovem empatando com outro de oito anos sugere que o que o agente precisa não é maturidade acumulada, e sim organização: código separado por responsabilidade, nomes estáveis e um lugar só para cada verdade.
Rodadas sem arquivo de instrução pontuaram mais
A parte mais útil do relato contraria o que a maioria dos times vem fazendo. Rodadas sem os arquivos de instrução, aqueles AGENTS.md e similares que viraram padrão, pontuaram mais alto nas dimensões mecânicas do que as rodadas com eles.
O motivo é simples quando se olha: esses arquivos congelam listas que deveriam ser descobertas no código. Listam componentes que já existem, levando o agente a criar de novo o que estava pronto, e às vezes trazem tokens que nunca existiram, inventados pelo próprio modelo que escreveu o arquivo.
Morales então refez o arquivo seguindo o princípio de apontar em vez de repetir. A primeira tentativa piorou a nota, de 90 para 72, porque sobrou uma lista de propriedades fixa. Depois de 107 linhas novas e um portão de validação melhor, o resultado voltou aos mesmos 90 pontos, com um documento 90% menor, custo de teste 41% menor e tempo de execução 22% menor.
Onde a medição não alcança
O eixo de julgamento é o que separa código correto de design correto, e o exemplo que o texto dá é bom: a pior tarefa nos dois sistemas foi um campo de senha com botão de mostrar e esconder. Como o campo de texto não tinha espaço previsto para esse botão, os agentes montaram um por cima. Tudo passou nas checagens técnicas, e o resultado era errado.
A conclusão é a frase que vale levar para qualquer time de design system: API que falta não é problema de documentação, e o conserto mora no componente. O agente não inventa o que o sistema não oferece; ele improvisa, e improviso aparece na interface.
Prontidão para IA como camada extra
Para quem cuida de design system no Brasil, o recado prático é parar de tratar prontidão para IA como camada extra, com arquivo de instrução, servidor de contexto e conjunto de regras por cima do que já existe. O que o teste mostra é que o ganho vem de higiene antiga: separar responsabilidades, manter contrato de componente gerado automaticamente e deixar a documentação apontar para a fonte em vez de copiá-la.
Instrução para agente continua valendo, mas para outra coisa: ensinar a linguagem do produto, hierarquia, ênfase, quando usar cada padrão. Lista de respostas envelhece em uma semana; princípio dura.
