Design systems como coleção de decisões avaliáveis por agentes

Design systems como coleções de decisões

O autor defende uma forma simples de enxergar design systems: eles são coleções de decisões já tomadas - qual componente usar, quais tokens aplicar, quais estados são suportados, como tratar ações destrutivas. Uma vez incorporadas ao sistema, essas decisões encerram o debate e liberam o time de reabrir a mesma conversa em cada nova tela.

Essa visão ganha relevância agora que agentes de IA consomem design systems e produzem trabalho real a partir deles. A partir de uma discussão sobre evals de design visual, o autor concorda com a tese de Murphy Trueman, de que ensinar o agente sobre o sistema não basta - é preciso verificar se ele seguiu o sistema -, mas discorda de onde traçar a linha do julgamento.

Começar pelo que o sistema pode provar

Para artefatos gerados, o autor prioriza evidência determinística: se dá para inspecionar se o agente usou um componente real, variante suportada, valores vinculados aos tokens corretos, sem instâncias desconectadas, não é preciso perguntar a outro modelo. O artefato em si pode provar o que aconteceu, algo que um avaliador visual só consegue estimar. Verificações mecânicas incluem uso de componentes existentes, propriedades e estados suportados, vínculo de espaçamento, tipografia, cor e raio às variáveis corretas, e requisitos de acessibilidade testáveis diretamente. Essa é a camada em que mais confia.

Julgamento com gabarito

Os problemas surgem quando o artefato é estruturalmente válido, mas errado: um agente cria uma ação destrutiva num modal correto, com tokens corretos, ignorando o padrão de confirmação exigido pelo sistema. Aí entra o LLM-as-judge, mas com um gabarito: o evaluator recebe a intenção da tarefa, o resultado gerado e a documentação do sistema, e verifica se o padrão, os estados e a interação seguem as diretrizes. O modelo raciocina, mas não raciocina do nada - o gabarito existe, ainda que em prosa em um arquivo markdown.

Os dois quartos

O autor cita o princípio da Anthropic de que um bom eval exige que dois especialistas diante do mesmo resultado cheguem ao mesmo veredito. Isso mapeia a diferença entre dois quartos: designers avaliando uma landing page divergem legitimamente sobre hierarquia, respiro e tensão visual; engenheiros avaliando se uma transação falha pode cobrar duas vezes conseguem, eventualmente, estabelecer se o comportamento está correto. Nos dois casos há expertise, mas só um deles tem algo próximo de um gabarito. O autor nota que a Anthropic trata revisão humana como checagem final de um modelo já calibrado - e discorda desse ponto para design, porque não há alvo calibrado para calibrar o modelo em primeiro lugar.

Quando evals visuais fazem sentido

Com uma referência conhecida - um design a ser reproduzido -, avaliar intensivamente faz sentido: comparar elementos esperados e inesperados, hierarquia, geometria, componentes e estados, usando conceitos como precisão e recall. O gabarito não precisa ser um screenshot perfeito; pode ser uma árvore de componentes esperada, estados conhecidos, conteúdo obrigatório ou fluxo de interação. O ceticismo do autor cresce quando uma composição original gerada por IA é entregue a outra IA com a pergunta "isso é bom design?" - segundo quem?

Na sua prática de benchmark de output de design systems, a ordem de confiança é conformance, governance, fidelity. Uma descoberta inesperada: modelos melhores não fecharam a lacuna de conformidade - só tornaram os erros mais difíceis de detectar, pois componentes alucinados agora parecem prontos para produção.

Gosto é um tipo diferente de decisão

O autor não considera crítica visual de IA inútil: para um engenheiro sem experiência de design, o modelo pode ser um crítico valioso. Mas, em organizações de design maduras, ele não quer que um escore visual se torne autoridade estética. O que ele não abre mão de terceirizar é a decisão sobre se uma nova direção visual merece existir. Cada decisão hoje codificada no sistema já viveu num estado não resolvido, em que não havia nada para um eval enforcementar. Enforçar decisões existentes não é o mesmo que fazer as decisões que expandem o sistema.

O designer nativo de IA

A IA pode explorar dez abordagens no tempo de duas, criticá-las e revelar tradeoffs; o designer decide que a opção seis é chata ou que a dez contém uma ideia que nenhum evaluator teria pontuado melhor. A síntese do autor: checagens determinísticas para o que é provável, evals assistidos por modelo para a governança contextual, avaliação visual quando há referência, e crítica de IA livre quando ajuda alguém a decidir melhor - sempre deixando espaço para uma pessoa olhar algo que passou em todos os evals e dizer "não é isso". Isso não é falha do sistema de avaliação: pode ser a razão de a próxima boa ideia existir. A próxima entrada no sistema ainda precisa de um ponto de vista.