Hoje a Figma anunciou que agentes de IA podem escrever diretamente no canvas. Criar componentes, aplicar variáveis, editar frames, usando o design system que já existe no seu projeto.
Funciona via MCP, o protocolo aberto que conecta agentes a ferramentas externas. Claude Code, Codex, Copilot, Cursor e outros já conseguem usar. Na prática, um agente pode receber uma instrução em linguagem natural e montar uma tela inteira no Figma, respeitando tokens, variáveis e componentes da sua biblioteca.
Mas o detalhe que me chamou mais atenção são as "skills". São arquivos markdown que definem como o agente se comporta dentro do Figma. Qualquer pessoa pode escrever uma skill, sem código, sem plugin. Você descreve as regras do seu design system em texto e o agente segue. É como um lint de design, mas conversacional.
Isso muda a dinâmica entre design e desenvolvimento de um jeito que ainda não está claro pra ninguém. Se um dev pode pedir pro agente "cria a tela de settings usando nosso DS" e o resultado aparece direto no Figma como frames editáveis, o handoff tradicional perde sentido. O arquivo do Figma vira uma superfície compartilhada onde humanos e agentes trabalham juntos.
Ainda é beta. Ainda vai ser pago por uso. E a qualidade do output depende muito de como você estrutura as skills e o design system. Ou seja, times com design systems bem documentados vão ter vantagem desproporcional aqui.
A Figma fez uma aposta interessante: em vez de competir construindo IA própria para tudo, abriu o canvas como plataforma. Quem quiser construir agentes de design, constrói. É uma resposta diferente do que o Google fez com o Stitch.
Sem biblioteca o agente desenha fora do sistema
O use_figma opera com componentes e variáveis que já estão no arquivo. Se a biblioteca é um conjunto de frames soltos, o agente monta mais frames soltos. Se há tokens de cor, spacing, tipografia e componentes com auto layout, o output tem onde se encaixar. A Figma descreve isso sem rodeio: contexto de design system é o que separa tela genérica de tela da marca.
Code Connect e syntax de variáveis no Dev Mode reforçam o mesmo ponto do outro lado. Agente que gera código a partir do frame precisa do mapeamento. Agente que gera frame a partir de um pedido precisa da biblioteca. Os dois lados pobres produzem UI que ninguém quer manter.
Antes de ligar o MCP para o time inteiro, faça um inventário curto: quais componentes cobrem os fluxos pedidos com mais frequência, quais variantes existem de verdade, quais variáveis o arquivo usa, o que ainda é texto solto fingindo token. Buraco no inventário vira retrabalho, não "criatividade do modelo".
Times sem design system podem usar o agente para bootstrap. O risco é publicar o bootstrap como se fosse sistema. Trate a primeira leva como rascunho para humanos nomearem, enxugarem e conectarem ao código.
Skills descrevem o rito, a revisão fecha o arquivo
Skill é Markdown. Qualquer pessoa do time pode escrever uma. Isso baixa a barreira e espalha regra informal. Sem dono, cada squad manda o agente seguir um /figma-generate-design diferente, com nomenclatura conflitante. O arquivo vira um campo de variantes que o DS não reconhece.
O skill base /figma-use ensina o agente a circular no canvas. Os outros (gerar biblioteca a partir de código, gerar tela a partir de componentes, aplicar spacing, sincronizar token) são fluxos. O time escolhe quais entram no repositório de skills e quem aprova mudança. É o mesmo cuidado de um linter: regra sem manutenção vira ruído.
Auto-checagem com screenshot ajuda o modelo a iterar. Não dispensa review. Espaçamento hierárquico pode até ficar aceitável; estado vazio, erro, permissão, i18n e conteúdo real quase nunca nascem certos no primeiro passe. Design olha o arquivo. Acessibilidade olha o nome da camada e o contraste. Produto olha se aquele fluxo existe.
A skill pode pedir ao agente para parar depois de N frames e listar o que inventou. Esse relatório é mais útil que um arquivo cheio. Invenção sem lista é dívida.
Permissão de escrita no canvas nesta fase beta
A Figma avisou: beta, grátis agora, cobrado por uso depois. MCP herda a segurança da conta. Ainda assim, um agente com use_figma escreve no arquivo que o time trata como fonte. Sem controle de quem conecta o cliente (Claude Code, Codex, Copilot, Cursor, Warp), o canvas ganha autores que não aparecem no ritual de critique.
Defina um arquivo ou uma página de sandbox para o agente. Produção do DS (biblioteca publicada, team library) fica em modo leitura até o fluxo provar que o agente reusa componente em vez de duplicar. Duplicar é o defeito caro: o sistema perde adoção e o código perde mapeamento.
Cobrança por uso muda a conta quando o beta acabar. Enquanto é grátis, o hábito se forma mais rápido que a disciplina de sandbox. Time que deixa o agente escrever em todo arquivo vai ter que desaprender na hora do price. Melhor já ter a página-sandbox e o allowlist de clientes MCP.
A paridade com a Plugin API ainda não é o objetivo cumprido. Imagem e fonte custom estão na lista de expansão. Fluxos que dependem disso hoje falham de um jeito opaco. Não prometa ao design "o agente faz o que o plugin faz".
O frame compartilhado altera o handoff
Handoff clássico: design fecha, dev implementa, o arquivo envelhece. Com agente nos dois lados, o dev pede um fluxo de settings e recebe frames editáveis no mesmo arquivo em que o design já trabalha. Isso reduz transcrição. Também mistura autoria. Sem convenção de página ("agente / humano / pronto para build"), ninguém sabe o que está estável.
Uma convenção mínima: página ou seção com prefixo, status no nome do frame, e regra de não publicar library a partir do que o agente gerou no dia. Design revisa, promove, aí o componente entra no sistema. O agente continua podendo editar o rascunho.
O ganho de tempo aparece em tela que o sistema já cobre: settings, lista, formulário, empty state padrão. Some em fluxo inédito, em marketing, em ilustração, em motion. Aí o canvas aberto ainda ajuda a explorar, mas o critério de pronto continua humano e lento, como deve.
Stitch e geradores isolados produzem UI fora do arquivo. Aqui o artefato já nasce onde o time discute. Essa é a diferença operacional. Ela só vale se o time de fato abrir o arquivo depois, em vez de mergear o frame no produto sem passar por design.
O que deixar de fora da primeira semana de uso
Na primeira semana, não peça rebrand, não peça 72 variantes de um botão em cima da library publicada, não peça o agente para "alinhar o app inteiro ao DS". Peça um fluxo conhecido, num arquivo de sandbox, com a skill de gerar design a partir de componentes existentes. Meça: quantos componentes reusou, quantos criou, quanto o design reescreveu, quanto tempo até critique.
Se a taxa de reescrita for alta, o problema é biblioteca ou skill, não o modelo. Ajuste tokens, nomes, regras de composição. Só então abra para mais pessoas. Abrir cedo para o time todo, com MCP ligado em arquivos de produção, gera volume que ninguém revisa.
Acessibilidade não vem de brinde. Há skill comunitária de spec de screen reader; ela não substitui teste. Se o agente nomeia camada "Frame 12" e o contraste falha, o canvas ficou mais rápido e o produto pior. Inclua no critério de pronto o mesmo checklist de sempre: foco, nome acessível, estado de erro, texto verdadeiro.
A aposta da Figma (canvas como plataforma, skills como documentação executável) só retribui time que já escrevia a regra. Para os outros, o MCP torna visível a ausência. Vale o experimento de uma semana se o critério de pronto estiver escrito antes de abrir o arquivo de produção.
