Governança de Design na Era dos Agentes
Na mesma semana, dois sinais independentes apontaram para a mesma direção. A Figma abriu seu canvas para agentes de IA via MCP. E um designer chamado Wenbin publicou no Medium uma pergunta que deveria tirar o sono de quem lidera produto: o que acontece com design systems quando a IA muda o produto?
As respostas se complementam. A Figma construiu a ferramenta. Wenbin articulou a teoria. Juntos, confirmam algo que argumentamos em Seu Sistema de IA Também Precisa de um Fiscal: design systems são governança. Não metaforicamente. Literalmente.
Agentes no canvas: o que a Figma fez
O anúncio de 24 de março é técnico e discreto, como deveria ser. Agentes de IA agora leem e escrevem diretamente em arquivos Figma. Criam e modificam assets de design reais. Não mockups. Não sugestões em texto. Artefatos dentro do canvas, usando componentes, variáveis e tokens do design system existente.
O mecanismo é simples. O agente recebe acesso à biblioteca de componentes via MCP. Lê o que existe. Constrói com o que encontra. Se o design system define um botão primário com cantos de 8px e cor #1A73E8, o agente usa esse botão. Não inventa outro.
A integração funciona em nove plataformas: Claude Code, Cursor, VS Code, Copilot CLI, Augment, Codex, Factory, Firebender, Warp. Qualquer pessoa que entende Figma pode criar Skills (arquivos markdown que definem como agentes trabalham no canvas). Não exige código. Exige conhecimento de design.
Três aspectos importam para quem pensa em governança.
Primeiro: o agente é restrito ao que o design system permite. Componentes que não existem na biblioteca não são criados do nada. O sistema estabelecido funciona como um perímetro. Como documentamos em Skills Não Estão Substituindo Agentes. Estão Tornando Agentes Governáveis., capacidades modulares são capacidades auditáveis. Skills no Figma seguem o mesmo princípio: instruções declarativas que delimitam o que o agente pode fazer.
Segundo: a rastreabilidade melhora. Cada ação do agente acontece dentro do canvas, com histórico de versão. Se um componente foi modificado de forma incorreta, é possível identificar quando, por qual agente e reverter. Compare isso com agentes de código que geram milhares de linhas sem registro claro de decisão.
Terceiro: designers mantêm autoridade sobre o sistema. O agente executa dentro de regras que humanos definiram. Não negocia exceções. Não contorna restrições. Não decide sozinho que um componente precisa de uma variação nova.
Operadores e tomadores de decisão
Wenbin faz uma observação que merece atenção. Design systems tradicionais foram construídos para operadores. Usuários que seguem fluxos passo a passo: clique aqui, preencha ali, confirme acolá. Cada tela tem um caminho predefinido. Cada componente existe para guiar o usuário por esse caminho.
IA muda a natureza da interação. O usuário deixa de ser operador e vira tomador de decisão. Em vez de seguir um fluxo, ele recebe sugestões geradas por IA e decide se aceita, modifica ou rejeita. A interface precisa comunicar incerteza. Precisa distinguir o que foi gerado por IA do que foi inserido manualmente. Precisa oferecer controle sobre resultados probabilísticos.
Componentes tradicionais não foram projetados para isso.
Wenbin lista padrões que faltam: indicadores de confiança, inputs mistos (IA e manual no mesmo campo), sugestões com níveis de certeza visíveis, controles para aceitar parcialmente uma recomendação. São problemas reais que a maioria dos design systems ignora.
A frase que resume a tese dele: “Design systems were built for operators. AI is turning users into decision-makers.” É uma observação precisa. Também é incompleta.
O que falta em ambas as conversas
A Figma resolveu o problema da execução. Agentes constroem dentro do design system existente. Wenbin identificou o problema da abstração. Design systems precisam de novos componentes para interfaces com IA. Os dois pontos são válidos. Nenhum aborda a questão central.
Quem decide quando o design system precisa mudar?
Quando agentes começam a gerar interfaces em volume, a pressão sobre o design system cresce. Cada nova interação com IA pode exigir um componente que não existe. Indicadores de confiança, por exemplo. Ou controles de granularidade para saída gerada por máquina. Se cada time resolve isso sozinho, o design system fragmenta em semanas.
Em IA em Fluxos de Design, documentamos como Atlassian, Meta e outras empresas estruturam o contexto que a IA recebe antes de executar. O mesmo princípio se aplica aqui. O design system precisa de um processo de governança para incorporar novos padrões de interação com IA, não apenas um catálogo de componentes estáticos.
Três necessidades emergem.
Critérios para novos componentes. Quando um padrão de interação com IA justifica a criação de um componente no design system? Se cada sugestão de IA gera um componente novo, o sistema infla até perder utilidade. Se nenhuma gera, o sistema se torna irrelevante para interfaces modernas.
Versionamento semântico para padrões de IA. Interfaces com IA mudam mais rápido que interfaces tradicionais. Modelos evoluem, capacidades surgem, comportamentos mudam. O design system precisa acompanhar sem quebrar o que já funciona. Isso exige versionamento explícito dos padrões de interação com IA, separado dos componentes tradicionais.
Feedback bidirecional. Agentes que constroem dentro do design system geram dados sobre o que funciona e o que falta. Esses dados devem alimentar a evolução do sistema. Se um agente frequentemente precisa de um componente que não existe, isso é um sinal. Ignorar esse sinal é repetir o erro que Klein descreveu: um sistema perfeito que ninguém consegue usar.
De catálogo a contrato
Design systems sempre foram mais do que coleções de componentes visuais. São contratos entre times sobre como interfaces devem se comportar. A Figma MCP torna esse contrato executável por máquinas. Os padrões que Wenbin descreve tornam esse contrato extensível para interfaces com IA.
A combinação é significativa. Se o design system é um contrato, agentes via MCP são signatários que cumprem o contrato automaticamente. E novos padrões de interação com IA são cláusulas que precisam ser adicionadas ao contrato com o mesmo rigor das originais.
Para organizações que ainda tratam design systems como responsabilidade exclusiva do time de design, o recado é claro. Quando agentes de IA constroem interfaces em produção, o design system se torna infraestrutura crítica. Sua governança não pode ser opcional.
Fontes
- Figma. “Design with Agents on the Figma Canvas.” Março 2026.
- Wenbin. “What Happens to the Design System When AI Changes the Product?.” Março 2026.
Victorino Group ajuda empresas a implementar sistemas de IA governados. contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa