I team di sviluppo software hanno trascorso decenni a costruire il determinismo nelle loro toolchain. Lockfile per i package manager. Immagini base pinnate per i container. Build riproducibili per gli artefatti compilati. Il principio è ben compreso: gli stessi input devono produrre gli stessi output, sempre, su qualsiasi macchina, in qualsiasi momento.

L'handoff del design non ha mai applicato questo principio. È stato, per impostazione predefinita, un processo fondamentalmente umano e quindi non deterministico. Un designer spiega il design a uno sviluppatore. Lo sviluppatore lo interpreta. L'interpretazione varia in base alla persona, al giorno, alla chiarezza con cui è stato scritto il commento su Zeplin. Non puoi riprodurlo. Non puoi testarlo. Non puoi confrontarlo con un diff.

In un mondo di agenti di codifica AI, l'handoff non deterministico è ora un problema ingegneristico di prima classe. figmascope lo affronta con un bundle di contesto congelato e portabile.

Perché gli strumenti attuali non sono deterministici per gli agenti

Zeplin e Avocode ti forniscono numeri estratti da Figma — dimensioni dei layer, valori di colore, dimensioni dei font. Ma li servono come interfaccia navigabile, non come artefatto leggibile dalle macchine. Un agente puntato su Zeplin deve navigare un'interfaccia per trovare i valori, il che è fragile, soggetto a limiti di velocità e dipendente da come sono state scritte le annotazioni.

Figma Dev Mode va oltre: ti fornisce snippet di codice generati inline dal design. Ma gli snippet sono stateless — rigenerati su richiesta, non versionati. Non c'è un bundle che puoi committare. Non c'è un file che puoi confrontare con un diff. Se il designer aggiorna il design, la vista Dev Mode si aggiorna silenziosamente. Non sai quando il design sottostante è cambiato rispetto all'ultima esportazione.

Gli screenshot sono il caso peggiore: dati pixel puri, completamente non deterministici da analizzare, che producono inferenze strutturali diverse ogni volta.

Le connessioni MCP live — strumenti che forniscono agli agenti accesso API in tempo reale al file Figma — sono non deterministiche per definizione. Il file cambia mentre l'agente lo legge. La run delle 9:00 e quella delle 14:00 vedono input diversi. Non puoi riprodurre la run delle 9:00 perché la sorgente è cambiata.

Gli agenti sono sistemi probabilistici. Fornire loro input non deterministici non produce solo varianza — rende il sistema impossibile da testare. Non puoi stabilire se un output errato è stato causato dal modello, dal prompt, o dal fatto che qualcuno ha spostato un layer tra le run.

Il bundle come unità di compilazione

Il modello mentale corretto per un'esportazione di figmascope è un artefatto di compilazione. Proprio come un compilatore prende il codice sorgente e produce un binario deterministico — stessa sorgente, stessi flag, stesso binario — figmascope prende uno stato del file Figma e produce un bundle deterministico: stesso stato del file, stesso bundle, ogni volta.

Il bundle è uno snapshot congelato. Cattura una versione specifica del design e serializza ogni proprietà rilevante: layout spaziale, identità dei componenti, binding dei token, contenuto delle stringhe, gerarchia. Una volta esportato, il bundle è immutabile. Il file Figma può cambiare; il bundle no. Se vuoi incorporare queste modifiche, riesporti e ottieni un nuovo bundle.

Questo è il modello dell'unità di compilazione. Il file di design è la sorgente. Il bundle è l'artefatto. Gli agenti consumano artefatti, non sorgenti.

Quattro proprietà di un handoff deterministico

Snapshot-able. L'artefatto di handoff deve rappresentare un momento specifico nel tempo. Non "lo stato attuale del file Figma" — un'esportazione denominata e versionata. I bundle di figmascope portano un _meta.json con un timestamp di esportazione e un'impronta digitale di ciò che è stato incluso. Il bundle è uno snapshot, non una vista live.

Portabile. L'artefatto deve essere autocontenuto. Nessuna dipendenza da servizi esterni, API live o sessioni con login. Un bundle di figmascope è un ZIP di file semplici — JSON, Markdown, PNG. Puoi copiarlo, inviarlo via email, committarlo in git, allegarlo a una PR, darlo a uno sviluppatore junior o a un agente di codifica senza alcuna configurazione.

Ispezionabile. Un artefatto deterministico è inutile se non puoi verificare cosa contiene. Ogni file nel bundle è leggibile da un umano. CONTEXT.md è Markdown. tokens.json è una struttura W3C-ish. L'IR per schermata è JSON con nomi di campo chiari. Un ingegnere può aprire il bundle e verificare esattamente cosa è stato detto all'agente. Questo è qualitativamente diverso da "ho incollato lo screenshot e ho ottenuto del codice."

Riproducibile. Dato lo stesso stato del file Figma, due esportazioni separate dovrebbero produrre bundle funzionalmente equivalenti. Non identici byte per byte (i timestamp differiscono), ma semanticamente identici: stesse strutture di nodi, stessi valori di token, stesso inventario dei componenti. Se esporti due volte da un file non modificato e i bundle differiscono semanticamente, qualcosa non va. Questa proprietà ti permette di validare la tua pipeline di esportazione e rilevare regressioni nell'estrattore stesso.

Come si manifesta nella pratica

Un designer completa le schermate di uno sprint. Esporta un bundle. Il bundle viene committato nel repo insieme al ticket — o allegato al problema Jira, o lasciato nel drive condiviso, a seconda del flusso di lavoro. A questo punto, l'artefatto di handoff è fissato. L'agente (o lo sviluppatore) lavora dal bundle, non dal file Figma live.

A metà implementazione, il designer aggiorna tre schermate. Nessun problema: il bundle di lavoro dello sviluppatore è invariato. Le nuove schermate ottengono una nuova esportazione. Ora hai due bundle e puoi confrontarli con un diff: cosa è cambiato tra il design con cui lo sviluppatore ha iniziato e il design attuale. Questo è esattamente il tipo di visibilità dei cambiamenti che è impossibile con i flussi di lavoro basati su screenshot o connessioni live.

In un flusso di lavoro multi-agente — un agente costruisce la libreria di componenti, un altro costruisce i layout delle schermate, un terzo scrive i test — ogni agente riceve lo stesso bundle come fonte di verità. Stanno tutti lavorando dallo stesso stato di design congelato. I loro output sono componibili perché i loro input sono condivisi e fissi. Questa è la precondizione per la generazione di UI multi-agente che sia effettivamente affidabile.

Confronto con diff dei bundle

Poiché il bundle è costituito da file semplici, si confronta come il codice. Due esportazioni dello stesso file su due versioni Figma ti danno un diff JSON che indica esattamente cosa è cambiato:

Questa è una visibilità dei cambiamenti del design che non esiste in nessuno strumento di handoff attuale. Figma ha la propria cronologia delle versioni, ma è visiva e orientata ai designer. Un diff del bundle è strutturato e orientato agli sviluppatori: dati di cambiamento leggibili dalle macchine che possono guidare test automatizzati, aggiornare changelog, o attivare flussi di lavoro CI.

CI/CD per l'handoff del design

Una volta che l'handoff è deterministico, il CI/CD segue naturalmente. Puoi scrivere test che vengono eseguiti contro un bundle: "questa schermata deve includere un componente Button/Primary," "questo token deve essere collegato e non un valore hardcoded," "questa stringa deve avere una chiave stringRef." Questi sono controlli di analisi statica su dati strutturati. Vengono eseguiti in millisecondi. Vengono eseguiti in una pipeline.

Puoi anche validare l'output dell'agente di codegen rispetto al bundle che gli è stato fornito. L'agente ha usato i token o ha hardcodato letterali? Ha generato il numero corretto di istanze del componente ripetuto? Ha usato i valori di spaziatura corretti? Queste domande hanno risposta quando la fonte di verità è un file strutturato, non un PNG.

Il confronto con MCP

Le connessioni live in stile MCP a Figma stanno guadagnando terreno. Il fascino è ovvio: l'agente vede sempre il design più recente, nessun passaggio di esportazione, nessuna gestione manuale del bundle. Ma le connessioni live scambiano il determinismo per la convenienza — e per gli agenti AI questo scambio è negativo.

Le connessioni live significano: il contesto dell'agente dipende da quando viene eseguito. Una run alle 9:00 e una alle 14:00 vedono dati diversi se il designer ha lavorato durante il giorno. Non puoi riprodurre la run precedente. Non puoi testare rispetto a un input fisso. Non puoi verificare cosa è stato detto all'agente. Se il codice generato è sbagliato, non puoi distinguere "il modello ha fatto un'inferenza errata" da "il design è cambiato sotto l'agente."

Il modello corretto è: connessioni live per l'esplorazione e l'iterazione del design (dove la recenza conta), bundle deterministici per l'handoff e la generazione (dove conta la riproducibilità). Non sono in competizione — operano in punti diversi del flusso di lavoro.

Handoff a uno sviluppatore junior

Le stesse proprietà che rendono i bundle buoni per gli agenti AI li rendono buoni per gli sviluppatori umani che sono nuovi a un codebase. Uno sviluppatore junior a cui viene consegnato un bundle ha: la specifica completa in CONTEXT.md, tutti i valori dei token in tokens.json, ogni componente elencato con le sue proprietà, ogni stringa con la sua identità. Non ha bisogno di essere nel file Figma. Non ha bisogno di un account Figma. Non ha bisogno di sapere quale schermata è quella autorevole.

Il bundle è un ordine di lavoro completo e autocontenuto. Come quello che riceverebbe un agente. L'unica differenza è che l'umano lo legge e l'agente lo elabora programmaticamente — ma l'artefatto è identico.

Quella unificazione — stesso artefatto, consumatore umano o agente — è il punto centrale. Il bundle è l'unità di handoff. Tutto il resto è un dettaglio implementativo.

Vedi l'handoff deterministico in pratica con Claude Code, Cursor o Aider. Tutti partono dalla stessa esportazione di figmascope.