Equipes de software passaram décadas construindo determinismo em seus toolchains. Lockfiles para gerenciadores de pacotes. Imagens base fixadas para containers. Builds reproduzíveis para artefatos compilados. O princípio é bem compreendido: as mesmas entradas devem produzir os mesmos outputs, sempre, em qualquer máquina, a qualquer momento.

O design handoff nunca aplicou esse princípio. Por padrão, sempre foi um processo fundamentalmente humano e, portanto, não determinístico. Um designer explica o design para um desenvolvedor. O desenvolvedor o interpreta. A interpretação varia por pessoa, por dia, pela clareza com que o comentário no Zeplin foi escrito. Você não pode repetir isso. Não pode testá-lo. Não pode fazer diff.

Em um mundo de agentes de codificação com IA, o handoff não determinístico agora é um problema de engenharia de primeira classe. O figmascope resolve isso com um bundle de contexto congelado e portátil.

Por que as ferramentas atuais são não determinísticas para agentes

Zeplin e Avocode fornecem números extraídos do Figma — dimensões de camadas, valores de cores, tamanhos de fonte. Mas os servem como uma UI navegável, não como um artefato legível por máquina. Um agente apontado para o Zeplin precisa navegar por uma UI para encontrar os valores, o que é frágil, sujeito a rate limiting e dependente de como as anotações foram escritas.

O Figma Dev Mode vai mais longe: fornece snippets de código gerados inline a partir do design. Mas os snippets são stateless — regenerados sob demanda, não versionados. Não há bundle que você possa commitar. Não há arquivo que você possa dar diff. Se o designer atualizar o design, a visão do Dev Mode atualiza silenciosamente. Você não sabe quando o design subjacente mudou em relação ao que você exportou pela última vez.

Screenshots são o pior caso: dados de pixels puros, totalmente não determinísticos para analisar, produzindo inferência de estrutura diferente a cada vez.

Conexões MCP ao vivo — ferramentas que dão aos agentes acesso à API do Figma em tempo real — são não determinísticas por definição. O arquivo muda enquanto o agente o está lendo. A execução do agente às 9h e sua execução às 14h veem entradas diferentes. Você não pode reproduzir a execução das 9h porque a fonte mudou.

Agentes são sistemas probabilísticos. Dar-lhes entradas não determinísticas não apenas produz variância — torna o sistema impossível de testar. Você não consegue dizer se um output ruim foi causado pelo modelo, pelo prompt ou pelo fato de alguém ter movido uma camada entre as execuções.

O bundle como unidade de compilação

O modelo mental correto para um export do figmascope é um artefato de compilação. Assim como um compilador pega código-fonte e produz um binário determinístico — mesma fonte, mesmos flags, mesmo binário — o figmascope pega um estado de arquivo do Figma e produz um bundle determinístico: mesmo estado do arquivo, mesmo bundle, sempre.

O bundle é um snapshot congelado. Ele captura uma versão específica do design e serializa todas as propriedades relevantes: layout espacial, identidade de componentes, vinculações de tokens, conteúdo de strings, hierarquia. Uma vez exportado, o bundle é imutável. O arquivo do Figma pode mudar; o bundle não. Se você quiser incorporar essas mudanças, re-exporte e obtenha um novo bundle.

Esse é o modelo de unidade de compilação. O arquivo de design é a fonte. O bundle é o artefato. Agentes consomem artefatos, não fontes.

Quatro propriedades de um handoff determinístico

Pode ser capturado em snapshot. O artefato de handoff deve representar um ponto específico no tempo. Não "o estado atual do arquivo do Figma" — um export nomeado e versionado. Os bundles do figmascope carregam um _meta.json com um timestamp de export e uma impressão digital do que foi incluído. O bundle é um snapshot, não uma visualização ao vivo.

Portátil. O artefato deve ser autocontido. Sem dependências de serviços externos, APIs ao vivo ou sessões logadas. Um bundle do figmascope é um ZIP de arquivos simples — JSON, Markdown, PNG. Você pode copiá-lo, enviá-lo por e-mail, commitá-lo no git, anexá-lo a um PR, entregá-lo a um desenvolvedor júnior ou a um agente de codificação sem nenhuma configuração.

Inspecionável. Um artefato determinístico é inútil se você não consegue verificar o que há nele. Cada arquivo no bundle é legível por humanos. CONTEXT.md é Markdown. tokens.json tem estrutura parecida com W3C. A IR por tela é JSON com nomes de campos claros. Um engenheiro pode abrir o bundle e auditar exatamente o que o agente foi instruído a fazer. Isso é qualitativamente diferente de "colei o screenshot e obtive algum código."

Reproduzível. Dado o mesmo estado do arquivo do Figma, dois exports separados devem produzir bundles funcionalmente equivalentes. Não idênticos em bytes (os timestamps diferem), mas semanticamente idênticos: mesmas estruturas de nós, mesmos valores de tokens, mesmo inventário de componentes. Se você exportar duas vezes a partir de um arquivo não alterado e os bundles diferirem semanticamente, algo está errado. Essa propriedade permite validar seu pipeline de export e detectar regressões no extrator.

Como isso se desenrola na prática

Um designer termina as telas de um sprint. Ele exporta um bundle. O bundle é commitado no repositório junto com o ticket — ou anexado à issue do Jira, ou colocado no drive compartilhado, dependendo do seu fluxo de trabalho. Nesse ponto, o artefato de handoff está fixado. O agente (ou o desenvolvedor) trabalha a partir do bundle, não do arquivo do Figma ao vivo.

No meio da implementação, o designer atualiza três telas. Sem problema: o bundle de trabalho do desenvolvedor está inalterado. As novas telas recebem um novo export. Agora você tem dois bundles e pode fazer diff entre eles: o que mudou entre o design com que o desenvolvedor começou e o design atual. Esse tipo de visibilidade de mudança é impossível com fluxos de trabalho baseados em screenshot ou em conexão ao vivo.

Em um fluxo de trabalho de múltiplos agentes — um agente constrói a biblioteca de componentes, outro constrói os layouts de tela, um terceiro escreve os testes — cada agente recebe o mesmo bundle como sua fonte de verdade. Todos estão trabalhando a partir do mesmo estado de design congelado. Seus outputs são combináveis porque suas entradas são compartilhadas e fixas. Essa é a pré-condição para geração de UI multi-agente que seja realmente confiável.

Fazendo diff em bundles

Como o bundle são arquivos simples, ele faz diff como código. Dois exports do mesmo arquivo em duas versões do Figma fornecem um diff JSON que informa exatamente o que mudou:

Essa é a visibilidade de mudança de design que não existe em nenhuma ferramenta de handoff atual. O Figma tem seu próprio histórico de versões, mas é visual e voltado para designers. Um diff de bundle é estruturado e voltado para desenvolvedores: dados de mudança legíveis por máquina que podem orientar testes automatizados, atualizar changelogs ou acionar fluxos de CI.

CI/CD para design handoff

Uma vez que o handoff é determinístico, CI/CD surge naturalmente. Você pode escrever testes que rodam contra um bundle: "esta tela deve incluir um componente Button/Primary", "este token deve estar vinculado e não ser um valor hardcoded", "esta string deve ter uma chave stringRef". Essas são verificações de análise estática contra dados estruturados. Rodam em milissegundos. Rodam em um pipeline.

Você também pode validar o output do agente de codegen contra o bundle que ele recebeu. O agente usou os tokens ou hardcodou literais? Ele gerou o número correto de instâncias do componente repetido? Ele usou os valores de espaçamento corretos? Essas perguntas são respondíveis quando a fonte de verdade é um arquivo estruturado, não um PNG.

A comparação com MCP

Conexões ao vivo no estilo MCP para o Figma estão ganhando tração. O apelo é óbvio: o agente sempre vê o design mais recente, sem etapa de export, sem gerenciamento manual de bundle. Mas conexões ao vivo trocam determinismo por conveniência — e para agentes de IA, essa troca é ruim.

Conexões ao vivo significam: o contexto do agente depende de quando ele executa. Uma execução às 9h e uma execução às 14h veem dados diferentes se o designer trabalhou durante o dia. Você não pode reproduzir a execução anterior. Não pode testar contra uma entrada fixa. Não pode auditar o que o agente foi instruído a fazer. Se o código gerado estiver errado, você não consegue distinguir "o modelo fez uma inferência ruim" de "o design mudou sob o agente."

O modelo correto é: conexões ao vivo para exploração e iteração de design (onde a recência importa), bundles determinísticos para handoff e geração (onde a reprodutibilidade importa). Eles não competem — operam em pontos diferentes do fluxo de trabalho.

Entregando para um desenvolvedor júnior

As mesmas propriedades que tornam os bundles bons para agentes de IA os tornam bons para desenvolvedores humanos que são novos em uma base de código. Um desenvolvedor júnior recebendo um bundle tem: a spec completa em CONTEXT.md, todos os valores de tokens em tokens.json, cada componente listado com suas propriedades, cada string com sua identidade. Ele não precisa estar no arquivo do Figma. Não precisa de uma conta no Figma. Não precisa saber qual tela é a autoritativa.

O bundle é uma ordem de trabalho completa e autocontida. Igual ao que um agente receberia. A única diferença é que o humano lê e o agente processa programaticamente — mas o artefato é idêntico.

Essa unificação — mesmo artefato, consumidor humano ou agente — é o ponto. O bundle é a unidade de handoff. Todo o resto é detalhe de implementação.

Veja o handoff determinístico na prática com Claude Code, Cursor ou Aider. Todos começam a partir do mesmo export do figmascope.