Design systems precisam de regras estruturais, não só componentes

Deriva estrutural apesar da mesma biblioteca

Matt Rothenberg observa que organizações de produto acumulam um problema silencioso: times usam a mesma biblioteca de componentes e o mesmo conjunto de tokens, mas produzem telas que não combinam. O que deriva não é a aparência superficial, e sim a forma da coisa: como uma página é organizada, o que uma ação perigosa transmite, quando algo pertence a uma tabela em vez de uma lista. Páginas de configurações ilustram o caso: um time empilha cartões, outro usa abas; um salva automaticamente, outro exige botão explícito de salvar. Todas as escolhas são razoáveis, mas a mesma biblioteca e os mesmos tokens podem gerar respostas diferentes para a mesma pergunta: o que uma página de configurações deveria ser aqui? O trabalho ausente é escolher uma resposta, torná-la canônica e colocá-la onde o próximo construtor a encontrará. Para o autor, um sistema verdadeiro precisa carregar decisões adiante, não apenas distribuir componentes.

Agentes expõem decisões ausentes

Agentes tornam decisões ausentes visíveis rapidamente. Rothenberg deu a vários agentes a mesma biblioteca e os impediu de ver o trabalho uns dos outros; depois comparou as decisões. Usou três prompts simples de páginas de configurações - um produto de gestão de projetos, um de tráfego e um de cobrança - com configuração idêntica: mesma biblioteca (shadcn/ui sobre Base UI), mesma camada de tokens e mesmo app shell. Não havia página existente para copiar nem outro trabalho para inspecionar. Os resultados compartilhavam linguagem visual, mas a composição divergia: configurações atrás de abas, cartões ou formulário longo. Um linter de tokens provavelmente aprovaria todos. A falha não está nos componentes, está na composição: ninguém forneceu uma resposta canônica sobre o que uma página de configurações deveria ser. A divergência não é falha de gosto, e sim o resultado quando vários padrões estabelecidos podem plausivelmente caber na mesma tela. Cada agente escolheu um padrão viável; o problema é que escolheram diferentes. Josh Puckett fez observação semelhante em escala maior, contando seis recursos principais no X construídos sobre quatro arquiteturas de visão distintas.

Por que decisões maiores ficam fora do sistema

Atomic design ofereceu uma hierarquia útil: átomos compõem moléculas, que compõem organismos, templates e páginas. A alegação útil é que um sistema precisa também dos padrões maiores, não só dos componentes dentro deles. Mas botões são problemas tratáveis: estados finitos, variantes, tokens e uma página Storybook que mostra tudo de uma vez. Podem ser concluídos, e concluir coisas satisfaz. Padrões maiores resistem a isso: uma página de configurações não é um componente com props, e sim um conjunto de juízos sobre o que pertence junto e quão difícil deve ser alterar algo. Essas decisões muitas vezes permanecem apenas como precedente, transmitidas apontando para uma tela existente.

Tornar decisões reutilizáveis

Times que constroem configurações não deveriam decidir do zero se uma configuração é linha, cartão ou formulário, nem como alterações salvam ou ações destrutivas funcionam. Esses são padrões de produto, e o design system deveria possuí-los. Usando a estrutura do atomic design, o autor descreve camadas: átomos (botões, switches, inputs, selects), moléculas (comportamentos recorrentes, como switch confirmável ou input validado), organismos (layout que faz configurações parecerem configurações), template (a página em si, com coluna legível, grupos em ordem fixa e ação destrutiva por último). Nomear essas camadas cria vocabulário compartilhado: ValidatedInput, ConfirmableSwitch, SettingRow. Um agente pode ler esse vocabulário como contexto, assim como uma pessoa, sem inferir decisões do zero.

O que muda quando se escreve

Em um segundo experimento, os agentes receberam os mesmos tickets, a mesma biblioteca e o mesmo app shell - mais o vocabulário e regras explícitas para páginas de configurações: usar SettingsFrame, seções em vez de abas, detalhes de identidade primeiro, danger zone por último, salvar cada linha ao mudar o valor, exigir digitação do nome antes de exclusão. Com regras compartilhadas, as três páginas passaram a ler como um produto mais coerente. O autor recomenda colocar cada decisão recorrente no padrão que pode aplicá-la: código pode tornar algumas escolhas inevitáveis, mas só código não explica por que abas são proibidas ou por que alterações salvam imediatamente. As regras devem ficar ao lado dos padrões, onde pessoas e agentes as encontrem. Ele prevê que trabalho de design system agêntico tornará esse ciclo rotineiro: agentes podem construir contra regras, verificar resultados e avaliar quais ambiguidades restantes ainda produzem telas divergentes mas plausíveis.