Chamamos o Design System de Camada de Restrição. Agora Agentes o Escrevem.

Há cerca de um ano escrevemos que o design system é a camada de restrição para agentes. É o que diz a um agente autônomo de código o que é um botão, qual espaçamento é permitido e onde ficam as fronteiras da marca. Argumentamos que o próprio substrato estava se adaptando à era dos agentes. Argumentamos que a governança de design estava se tornando o ponto de controle. Vimos a Figma colocar um agente na tela e tratamos o design system como o regulamento que o agente tinha de obedecer.

O chão se moveu sob esse enquadramento. O design system deixou de ser apenas um alvo de leitura para os agentes. Virou um alvo de escrita.

O sistema passou de leitura para escrita

Murphy Trueman, estrategista de design systems, montou a linha do tempo em junho de 2026. A Figma abriu a tela aos agentes via MCP em março, depois lançou um agente nativo de tela no Config 2026. O Storybook 10.3 lançou um servidor MCP para React. O Google publicou o DESIGN.md como especificação aberta em abril. A Anthropic publicou a especificação SKILL.md ainda em dezembro de 2025. Leia essa lista como um único movimento e o padrão fica claro: agentes agora escrevem no design system, não apenas leem dele.

Eles escrevem tokens. Geram documentação de componentes. Editam o DESIGN.md que descreve a intenção e escrevem os arquivos SKILL.md que instruem o próximo agente. A camada de restrição que passamos um ano descrevendo agora é escrita, em parte, pelas coisas que ela deveria restringir.

O que mudou aqui é a autoria. Quando um mantenedor humano era dono do arquivo de tokens, a revisão estava implícita no trabalho. Alguém cujo nome estava no design system lia cada mudança nele. Quando um agente propõe renomear um token, uma nova descrição de componente ou uma edição no próprio arquivo de instrução, essa propriedade implícita evapora, a menos que alguém a reconstrua de propósito.

A trilha de auditoria piorou justo quando precisava melhorar

Trueman faz uma observação que merece ficar no centro disto: “Um histórico de commits do Git se lê como um relato humano do porquê. O histórico de prompts de um agente está mais perto de uma caixa preta.”

Um commit humano carrega intenção. A mensagem diz o que mudou e, quando o autor é bom, por quê. Dá para reconstruir o raciocínio. A contribuição de um agente chega com um diff e uma trilha de prompts que raramente explica o julgamento por trás da mudança. O token foi renomeado. A descrição do componente foi reescrita. O DESIGN.md ganhou uma regra nova. O registro do porquê é fino, e o registro de quem aprovou costuma ser mais fino ainda.

Pergunte quem aprovou uma dada mudança na camada de restrição. A resposta de Trueman, vinda dos times com quem ele conversa, é direta: “quem por acaso olhar o próximo PR.” Isso é uma loteria com nome de processo de revisão. E está rodando exatamente sobre o arquivo que governa o comportamento de todo agente a jusante.

O modo de falha se compõe. Um agente edita um token. Um agente posterior lê esse token como verdade absoluta e gera vinte componentes contra ele. Um terceiro agente lê os componentes resultantes e atualiza a documentação para bater. Três saltos adiante, a decisão original sem revisão se propagou para a estrutura, e nenhum humano decidiu nada disso. A camada de restrição derivou, e a deriva agora sustenta peso.

Quatro coisas que preparam um design system para autoria por agentes

Trueman oferece um modelo de prontidão. Reduzido às partes que sobrevivem ao escrutínio, quatro fatores importam.

Tokens como APIs versionadas. Um token que um agente pode escrever é uma superfície de API. Precisa da disciplina de uma: caminhos de depreciação, caminhos de migração e revisão humana de PR em cada mudança. Se o seu arquivo de tokens não tem história de versão, um agente editando-o está editando produção sem narrativa de rollback.

Descrições de componente guiadas por propósito. Um agente escolhe um componente pela descrição. “Botão primário” é um rótulo. “Use para a única ação mais importante de uma tela; nunca mais de um por visão” é um propósito. Descrições escritas para humanos passarem os olhos falham com o agente que precisa escolher sem ter gosto. A descrição virou uma instrução, então precisa carregar intenção.

Documentação em formato duplo. A documentação agora tem dois leitores. O humano quer prosa que explique o raciocínio. O agente quer estrutura que consiga parsear sem adivinhar. Um design system que serve só um leitor força o outro a improvisar, e um agente que improvisa é um agente inventando regras que você não escreveu.

Propriedade atribuída de revisão sobre a saída do agente. Esta é a que a maioria dos times pula, e é o ponto de controle. Alguém precisa ser dono da revisão do que os agentes escrevem na camada de restrição, com nome e sobrenome, como responsabilidade permanente. Não a próxima pessoa a abrir o PR. Um dono nomeado, do jeito que um design system mantido por humanos sempre teve um mantenedor nomeado.

Os três primeiros fatores tratam de tornar o sistema legível para agentes. O quarto trata de manter um humano responsável pelas regras sobre as quais os agentes rodam. Um time pode acertar a legibilidade e ainda assim não ter resposta para “quem aprovou a mudança na camada que governa todo o resto.” Essa pergunta é o jogo inteiro agora.

Quem revisa as regras sobre as quais o revisor roda

Aqui está a recursão que a virada criou. O design system revisa o trabalho do agente. O agente agora escreve parte do design system. Então quem revisa as regras sobre as quais o revisor roda?

Se a resposta for outro agente, você moveu a responsabilidade um nível acima e não resolveu nada. Se a resposta for “quem por acaso olhar o próximo PR”, você não tem responsabilidade nenhuma. A única resposta que se sustenta é um humano nomeado, dono da revisão da camada de restrição como responsabilidade de primeira classe, com a mesma seriedade com que um time de segurança é dono da revisão de política de IAM. A camada de restrição é o IAM do design. Deixá-la ser editada pela carga de trabalho que ela governa, sem revisor atribuído, é o mesmo erro que deixar um serviço reescrever as próprias permissões.

Faça isto agora

Abra o repositório do seu design system. Encontre os últimos dez commits no arquivo de tokens, nas descrições de componente ou em qualquer DESIGN.md e SKILL.md. Para cada um, responda a duas perguntas: isto foi escrito por um agente e qual nome está na revisão. Se você não consegue nomear um revisor para as mudanças escritas por agentes, encontrou seu ponto de controle. Atribua um dono, ainda esta semana, cujo trabalho permanente seja revisar o que os agentes escrevem na camada de restrição. Não o próximo PR. Um nome.

O controle do design na era dos agentes pertence aos times que mantiveram um humano responsável pelas regras sobre as quais esses agentes rodam. Ter os agentes mais espertos escrevendo tokens não coloca ninguém no controle.

---

Fontes

• Murphy Trueman. “Your design system’s newest author is an agent.” Junho de 2026.

A Victorino ajuda times a atribuir propriedade de revisão sobre as camadas de restrição que seus agentes agora escrevem: contato@victorino.com.br | www.victorino.com.br