Agentes de programação podem ler seu repositório. Figma Specs tenta dar a eles as decisões por trás do produto

Um agente de programação pega um ticket: adicionar um filtro à página de pedidos. Ele lê o repositório, encontra a biblioteca de componentes, escreve código limpo e abre um pull request. O revisor rejeita em um minuto. O filtro deveria ter sido ocultado para um segmento de cliente, o estado vazio precisava do texto da equipe jurídica, e o time de design já tinha decidido que filtros ficam em um painel lateral, não em um dropdown. Nada disso estava no repositório. Estava em uma reunião, um arquivo de design e um documento a três links de distância.

É uma das formas mais comuns de agentes de programação falharem. O código é plausível e o produto está errado, porque o agente teve acesso à implementação e não à intenção.

O que a Figma lançou

Em 15 de outubro, na Config India, a Figma apresentou o Specs: um workspace baseado em Markdown que fica no canvas da Figma ao lado de designs, diagramas do FigJam e camadas de código. Uma spec pode incorporar frames e qualquer nó do canvas junto com texto. Arquivos Markdown existentes podem ser arrastados para o canvas e se tornarem specs. Conectores como GitHub e Hex podem trazer contexto externo, e o agente da Figma pode documentar o uso de componentes do design system e responder a comentários.

A parte que importa para a IA enterprise é a saída: specs se conectam ao servidor MCP da Figma, então agentes externos como o Codex podem ler uma spec junto com seus frames vinculados, diagramas, camadas de código e snippets do Code Connect. As camadas de código, que colocam protótipos interativos com código no canvas, entraram em beta aberto no mesmo dia.

O Specs em si está sendo lançado em beta aberto para planos pagos, na web, desktop e mobile.

Contexto é uma cadeia de suprimentos

A ideia está certa. A Microsoft descobriu que agentes de programação continuam usando uma API incorretamente quando sua documentação é ruim; o mesmo vale para produtos. Um agente não pode respeitar uma decisão que nunca vê. Colocar requisitos em um formato legível por máquina, ao lado dos designs que descrevem, e expô-los através de um protocolo padrão encurta a distância entre o que foi decidido e o que é construído.

Mas contexto sobre o qual agentes agem se comporta como qualquer outro insumo para produção: tem uma fonte, uma versão e um dono, ou deveria ter. O anúncio da Figma diz pouco sobre o lado da governança:

• Qual versão o agente leu? Uma spec pode ser duplicada para que colegas de equipe trabalhem em versões separadas antes de alinhar. Duas versões de um requisito, ambas legíveis através do MCP, é receita para um agente implementar a errada.
• Quem aprovou? Engenheiros podem marcar frames como prontos para desenvolvimento, mas o anúncio não descreve aprovação para uma spec em si. Um rascunho e uma decisão parecem a mesma coisa para um agente.
• Quem pode ler? O acesso do agente através do MCP depende de permissões. Specs que incorporam pesquisa com clientes ou planos não lançados precisam do mesmo cuidado de acesso que os documentos de onde vieram.

Faça da spec parte do registro de mudanças

Times que adotam o Specs, ou qualquer abordagem similar, podem fechar a maioria dessas lacunas com processo em vez de recursos:

1. Marque quais specs são autoritativas, e mantenha rascunhos fora das pastas que os agentes leem.
2. Referencie a spec e sua versão no pull request. Quando um revisor rejeita a mudança de um agente, a primeira pergunta deve ser se o agente leu a decisão correta.
3. Escreva critérios de aceitação que um agente possa verificar, não apenas texto que ele possa parafrasear. “Filtros aparecem no painel lateral” pode ser testado; “torne a filtragem intuitiva” não pode.
4. Dê um dono aos requisitos, como defendemos que definições de negócio precisam de donos quando agentes as leem.

Uma spec legível não é uma implementação verificada

O próprio enquadramento da Figma é cuidadoso, e os compradores devem manter a distinção: uma spec torna a intenção disponível; ela não faz um agente segui-la. Protótipos em camadas de código também não são software de produção; codebases complexas não são necessariamente suportadas. A verificação ainda acontece onde sempre aconteceu, em revisão e testes.

O que o Specs muda é a qualidade da pergunta que um revisor pode fazer. Em vez de “por que o agente fez isso?”, passa a ser “o agente fez o que a spec diz?” Essa segunda pergunta tem resposta, e move a conversa de gosto para evidência.