Agentes podem falar o idioma do seu design system

Nomes como decisões registradas

O autor trabalha com design systems em uma grande empresa, onde parte do trabalho é garantir que o produto pareça um único produto mesmo com times diferentes construindo partes distintas. Em continuidade a um texto anterior - “You Don’t Have a Design System”, sobre decisões recorrentes de estrutura e comportamento que um sistema precisa capturar, e não apenas componentes -, este texto trata de como essas decisões chegam ao próximo construtor.

Nomes como Overview, PageHeader e SettingsFrame não são meros rótulos: são atalhos para decisões que o time não deveria reabrir em cada reunião de planejamento, revisão de design ou ciclo de implementação. A documentação de cada padrão deve dizer qual problema resolve, quais regras segue e quando não usá-lo. Nenhuma dessas regras é notável sozinha - importa que alguém decidiu uma vez, deu um nome e deixou registrado para o próximo construtor.

A vantagem do agente

Para uma pessoa, a fluência é cara: vem de repetição - ver componentes, aprender exceções, lembrar por que uma página tem determinada forma -, o que concentra o vocabulário em quem está mais perto do sistema. Um agente, com acesso ao repositório, pode inspecionar a implementação por trás do vocabulário, as orientações ao lado e exemplos de uso: o nome diz onde olhar, e a justificativa explica por que o padrão existe, quando serve e quando não serve. À medida que o padrão aparece pelo produto, o agente acumula evidência de como ele deve funcionar. Ele não tem bom gosto por mágica, mas pode recuperar precedentes e restrições que levariam meses para um novo colaborador acumular - o que o torna um tradutor útil entre quem descreve uma tela e um sistema que já sabe como telas semelhantes são construídas.

Vocabulário compartilhado encurta o caminho

A linguagem comum de produto deixa espaço demais em aberto: pedir “uma página que lista regras de firewall” faz cada ouvinte imaginar algo ligeiramente diferente, e o time gasta reuniões com decisões que o sistema talvez já tenha tomado. O autor endossa a observação de Marc Hemeon de que PMs, engenheiros e designers compartilham o mesmo trabalho - dar vida a ideias - e de que a IA desfoca essas fronteiras. Com limites mais fluidos, mais pessoas podem construir o produto diretamente; o design system dá um jeito de se referir a decisões que já existem, e o agente pode trabalhar nessa linguagem antes de alguém aprendê-la por inteiro.

No exemplo, um PM descreve a página de projetos sem conhecer cada layout; o agente inspeciona os padrões disponíveis e monta a tela, e as pessoas decidem se ela serve à experiência pretendida. O agente faz a montagem; o time faz o julgamento. Na mensagem “depois”, o agente já recomenda o layout Overview - linha de MetricCards, um ChartCard, uma seção de Table e nenhuma ação no PageHeader - no lugar da reunião para decidir como construir. Escrever no vocabulário do sistema exige experiência; reconhecer se um padrão proposto serve ao produto é tarefa menor, mas essencial.

Gerar a partir do sistema

Com os padrões nomeados, o agente pode transformar um pedido curto em uma tela: ao receber “Overview”, encontra o código que compõe o layout e o usa para montar uma tela que permanece, teoricamente, dentro do sistema. Se o pedido não se encaixa em nada nomeado, a lacuna fica visível em vez de se esconder numa página improvisada.

O que os agentes tornam visível

A maioria das pessoas nunca conhecerá o design system como seus mantenedores - e não deveria precisar. O vocabulário é uma interface para esse conhecimento: nomes como Overview e SettingsFrame permitem expressar uma intenção sem localizar arquivos ou lembrar regras, enquanto o agente segue esses nomes até o componente, a documentação e os exemplos existentes. Essa é a versão útil de “falar design”: a complexidade do sistema continua lá, mas a linguagem dá às pessoas um modo de endereçá-la.