Três Agentes, Um Ticket: A Auditoria de Drift Que Seu Design System Nunca Rodou

Matt Rothenberg deu a três agentes isolados a mesma biblioteca de componentes, os mesmos design tokens e o mesmo shell de aplicação, e entregou a cada um um ticket idêntico de página de configurações. Voltaram três páginas. Um agente organizou as configurações em abas. Outro construiu seções longas. O terceiro empilhou cards. A avaliação do próprio Rothenberg sobre o resultado: “um token linter provavelmente aprovaria as três”.

Esse resultado soa familiar para quem mantém um design system em produção. As cores estavam certas em todas as páginas. O espaçamento estava certo. Os componentes eram os componentes sancionados. E as três páginas ainda pareciam três produtos diferentes, porque o sistema codificou componentes e tokens, mas nunca codificou as decisões sobre como montá-los.

Rothenberg então rodou o experimento de novo. Mesmos agentes, mesma biblioteca, mesmos tickets, com uma adição: regras escritas. Um vocabulário compartilhado de padrões nomeados (SettingRow, SettingsGroup, ConfirmableSwitch) e convenções explícitas, incluindo um template que posiciona ações destrutivas por último. As páginas convergiram.

Duas rodadas, uma variável alterada. O delta entre a rodada 1 e a rodada 2 é uma medição de tudo o que o seu design system deixou sem documentar.

O que o linter certifica, e o que ele nunca vai certificar

Um token linter certifica conformidade de material. Confirma que o botão é o botão sancionado, que o azul é o azul sancionado, que o espaçamento cai na grade. Ele nada diz sobre configurações viverem em abas ou em seções, sobre uma ação perigosa ficar no topo de um grupo ou no fim, sobre controles relacionados se agruparem ou se espalharem.

Essas são decisões. Times as tomam o tempo todo, e com frequência elas vivem na cabeça de designers seniores, em threads de Slack que já rolaram para longe, no precedente implícito de qual página foi lançada primeiro. A formulação de Rothenberg é precisa: “Agentes expõem a lacuna rapidamente: constroem a partir do que você codificou e fazem inferências razoáveis, porém diferentes, em todo o resto.”

Cada inferência que um agente faz é uma decisão que o seu sistema não tomou por ele. Desenvolvedores humanos fazem as mesmas inferências. Só que devagar, um PR de cada vez, com bom gosto e contexto de corredor suficientes para o drift parecer plausível. O agente comprime esse drift em uma única rodada e coloca três variantes lado a lado, onde ninguém consegue fingir que o sistema cobria o caso.

Josh Puckett, citado no texto de Rothenberg, descreveu como fica a versão humana e lenta desse fenômeno em escala: “seis funcionalidades principais no X construídas sobre quatro arquiteturas de visualização diferentes”. Nenhum linter sinalizou isso. As decisões de arquitetura nunca foram codificadas em lugar algum que um linter enxergasse.

A divergência é a leitura do instrumento

O instinto, quando saídas de agentes divergem, é arquivar o caso como falta de confiabilidade do agente. Mesmo prompt, respostas diferentes, o modelo é estocástico, abaixe a temperatura. Essa leitura descarta o sinal mais útil de todo o exercício.

As três páginas de configurações divergiram exatamente ao longo dos eixos que o sistema nunca especificou. Onde o sistema tinha resposta (qual componente de botão, qual token), as três páginas cumpriram o combinado. Onde o sistema silenciou (arquitetura da página, agrupamento, ordem das ações destrutivas), cada agente preencheu o silêncio com um palpite razoável. O mapa da divergência e o mapa das decisões sem documentação são o mesmo mapa.

Rothenberg incorporou o artefato vivo no próprio post, para o leitor alternar entre as rodadas e observar diretamente. A instrução dele para a leitura dobra como método: o que se move entre as rodadas é o drift.

Isso muda o que um agente é dentro de uma organização de design. Aplicado em isolamento contra um ticket compartilhado, um agente é uma sonda repetível. Ele carrega zero memória das suas conversas de corredor, zero lealdade à página que foi lançada primeiro, zero constrangimento em escolher abas quando o designer sênior escolheria seções. Constrói a partir do que você escreveu, e apenas do que você escreveu. A saída é uma renderização honesta da sua documentação.

Times humanos jamais entregam essa leitura. Peça a três desenvolvedores a mesma página de configurações e eles vão conversar entre si, olhar as páginas existentes, perguntar ao designer. As decisões sem registro vazam por canais que uma auditoria não controla. O isolamento do agente, geralmente listado como limitação, é o que faz o instrumento funcionar.

A auditoria que qualquer time roda esta semana

O experimento exigiu de Rothenberg uma biblioteca de componentes, um shell de aplicação e três tickets. Nada no arranjo pede infraestrutura de pesquisa. Um protocolo concreto:

1. Escolha um tipo de página que seu produto constrói repetidamente. Configurações é um bom padrão. Formulários, telas de detalhe e dashboards funcionam igualmente bem. O requisito é que o time já tenha construído esse tipo de página mais de uma vez, então convenções deveriam existir.
2. Escreva um ticket realista. Do tipo que um desenvolvedor pleno receberia. Nenhuma orientação extra além do que um ticket real carrega.
3. Entregue a três sessões isoladas de agente. Mesmo modelo, mesma biblioteca de componentes, mesmos tokens, mesmo shell. Sem contexto compartilhado, sem acesso à saída dos outros, sem acesso às páginas existentes além do que o próprio sistema fornece.
4. Compare as três páginas estruturalmente. Ignore conformidade de tokens, o linter já cobre isso. Compare arquitetura de página, agrupamento, ordenação e padrões de interação para ações de risco. Cada eixo de desacordo é uma decisão que o seu sistema delega ao julgamento individual.
5. Escreva as regras que faltam e rode de novo. Nomeie os padrões, declare as convenções, repita os mesmos três tickets. Convergência indica que as regras aterrissaram. Divergência residual indica quais regras continuam ambíguas como estão escritas.

A ressalva honesta: isso é um método demonstrado, e ainda longe de um estudo. Rothenberg rodou três agentes e duas rodadas sobre um tipo de página. O que a demonstração pequena estabelece é o mecanismo, e o mecanismo é verificável no seu próprio codebase pelo custo aproximado de três sessões de agente.

Argumentamos antes que a razão codificada é a verdadeira camada de restrição de um design system, e que agentes já escrevem contra esses sistemas mais rápido do que humanos revisam a saída. Este experimento fornece o instrumento que faltava aos dois argumentos. Antes de codificar as decisões, você precisa de um inventário de quais decisões estão faltando. A auditoria de drift produz esse inventário mecanicamente.

Rode antes que a frota rode por você

A versão desconfortável do argumento: se você está adotando agentes para trabalho de UI, esse experimento vai rodar com ou sem agendamento. Cada página construída por agente no seu produto é uma tentativa da rodada 1. Sem regras escritas, cada página amostra uma inferência razoável diferente, e o drift se acumula em produção em vez de em um sandbox.

Então rode de propósito. Esta semana, um engenheiro, uma tarde. Três sessões isoladas, um ticket, um diff estrutural. Leve os eixos de divergência para a próxima reunião de design system como pauta: cada eixo é uma regra a escrever. Depois repita e confirme a convergência.

Os times que tratarem divergência de agentes como ruído vão continuar ajustando prompts. Os que a tratarem como leitura de governança vão concluir a auditoria que o design system nunca rodou, e a rodada 2 deles vai convergir.

---

Fontes

• Matt Rothenberg. “You Don’t Have a Design System.” Agosto de 2026.

A Victorino ajuda organizações de engenharia e design a transformar divergência de agentes em auditorias de governança e sistemas de decisão codificados: contato@victorino.com.br | www.victorino.com.br