Mjukvaruteam har tillbringat decennier med att bygga in determinism i sina verktygskedjor. Låsfiler för pakethanterare. Fastlåsta basbilder för containers. Reproducerbara byggen för kompilerade artefakter. Principen är välförstedd: samma indata ska producera samma utdata, alltid, på vilken maskin som helst, vid vilken tidpunkt som helst.
Designöverlämning har aldrig tillämpat den här principen. Den har som standard varit en fundamentalt mänsklig och därmed icke-deterministisk process. En designer förklarar designen för en utvecklare. Utvecklaren tolkar den. Tolkningen varierar beroende på person, dag och hur tydligt Zeplin-kommentaren skrevs. Du kan inte spela upp det. Du kan inte testa det. Du kan inte diffa det.
I en värld av AI-kodningsagenter är icke-deterministisk överlämning nu ett förstklassigt teknikproblem. figmascope hanterar det med ett fryst, portabelt kontextpaket.
Varför nuvarande verktyg är icke-deterministiska för agenter
Zeplin och Avocode ger dig siffror extraherade från Figma — lagerdimensioner, färgvärden, teckenstorlekar. Men de serverar dem som ett bläddringsbart gränssnitt, inte som en maskinläsbar artefakt. En agent riktad mot Zeplin måste navigera ett gränssnitt för att hitta värdena, vilket är ömtåligt, hastighetsbegränsat och beroende av hur kommentarerna skrevs.
Figma Dev Mode går längre: det ger dig kodutdrag genererade direkt från designen. Men utdragen är tillståndslösa — regenererade på begäran, inte versionerade. Det finns inget paket du kan checka in. Det finns ingen fil du kan diffa. Om designern uppdaterar designen uppdateras Dev Mode-vyn tyst. Du vet inte när den underliggande designen ändrades relativt det du senast exporterade.
Skärmbilder är det värsta fallet: ren pixeldata, helt icke-deterministisk att tolka, vilket ger olika strukturinferens varje gång.
Live MCP-anslutningar — verktyg som ger agenter realtids-API-åtkomst till Figma-filen — är icke-deterministiska per definition. Filen ändras medan agenten läser den. Agentens körning kl. 9 och dess körning kl. 14 ser olika indata. Du kan inte reproducera körningen kl. 9 för att källan har ändrats.
Agenter är probabilistiska system. Att ge dem icke-deterministiska indata producerar inte bara varians — det gör systemet otestbart. Du kan inte avgöra om en dålig utdata orsakades av modellen, prompten, eller det faktum att någon flyttade ett lager mellan körningarna.
Paketet som en kompileringsenhet
Den rätta mentala modellen för en figmascope-export är en kompileringsartefakt. Precis som en kompilator tar källkod och producerar ett deterministiskt binärformat — samma källa, samma flaggor, samma binärformat — tar figmascope ett Figma-filtillstånd och producerar ett deterministiskt paket: samma filtillstånd, samma paket, varje gång.
Paketet är en fryst ögonblicksbild. Det fångar en specifik version av designen och serialiserar varje relevant egenskap: spatial layout, komponentidentitet, tokenbindningar, stränginnehåll, hierarki. När det väl exporterats är paketet oföränderligt. Figma-filen kan ändras; paketet gör det inte. Om du vill inkorporera dessa ändringar exporterar du om och får ett nytt paket.
Det här är kompileringsenhetmodellen. Designfilen är källkod. Paketet är artefakten. Agenter konsumerar artefakter, inte källkod.
Fyra egenskaper hos en deterministisk överlämning
Möjlig att ta ögonblicksbilder av. Överlämningsartefakten måste representera en specifik tidpunkt. Inte "nuläget i Figma-filen" — en namngiven, versionerad export. figmascope-paket bär en _meta.json med en exporttidsstämpel och ett fingeravtryck av vad som inkluderades. Paketet är en ögonblicksbild, inte en livevy.
Portabel. Artefakten måste vara självständig. Inga beroenden av externa tjänster, live-API:er eller inloggade sessioner. Ett figmascope-paket är en ZIP av vanliga filer — JSON, Markdown, PNG. Du kan kopiera den, e-posta den, checka in den i git, bifoga den till en PR, överlämna den till en juniorutvecklare eller en kodningsagent utan inställning.
Inspekterbar. En deterministisk artefakt är värdelös om du inte kan verifiera vad som finns i den. Varje fil i paketet är läsbar för människor. CONTEXT.md är Markdown. tokens.json har W3C-liknande struktur. Per-skärm IR är JSON med tydliga fältnamn. En ingenjör kan öppna paketet och granska exakt vad agenten fick veta. Det är kvalitativt annorlunda än "jag klistrade in skärmbilden och fick lite kod."
Reproducerbar. Givet samma Figma-filtillstånd bör två separata exporter producera funktionellt likvärdiga paket. Inte byte-identiska (tidsstämplar skiljer sig), men semantiskt identiska: samma nodstrukturer, samma tokenvärden, samma komponentinventering. Om du exporterar två gånger från en oförändrad fil och paketen skiljer sig semantiskt är något fel. Den här egenskapen låter dig validera din exportpipeline och fånga regressioner i extraheraren.
Hur det spelar ut i praktiken
En designer avslutar en sprints skärmar. De exporterar ett paket. Paketet checkas in i repot bredvid biljetten — eller bifogas Jira-ärendet, eller läggs i den delade katalogen, beroende på ditt arbetsflöde. Vid det här laget är överlämningsartefakten fastställd. Agenten (eller utvecklaren) arbetar från paketet, inte från den levande Figma-filen.
Halvvägs genom implementationen uppdaterar designern tre skärmar. Inga problem: utvecklarens arbetande paket är oförändrat. De nya skärmarna får en ny export. Nu har du två paket och kan diffa dem: vad som ändrades mellan designen som utvecklaren startade med och den nuvarande designen. Det här är precis den typen av ändringssynlighet som är omöjlig med skärmbildsbaserade eller live-anslutningsbaserade arbetsflöden.
I ett multi-agent-arbetsflöde — en agent bygger komponentbiblioteket, en annan bygger skärmlayouterna, en tredje skriver testerna — får varje agent samma paket som sin sanningskälla. De arbetar alla från samma frysta designtillstånd. Deras utdata är komponerbara för att deras indata är delade och fasta. Det här är förutsättningen för multi-agent UI-generering som faktiskt är tillförlitlig.
Diffa paket
Eftersom paketet är vanliga filer diffar det som kod. Två exporter av samma fil över två Figma-versioner ger dig en JSON-diff som berättar exakt vad som ändrades:
- Vilka noder som lades till eller togs bort
- Vilka tokenbindningar som ändrades
- Vilka strängar som uppdaterades
- Vilka komponentvarianter som byttes ut
- Vilka layoutegenskaper som ändrades (utfyllnad, gap, riktning)
Det här är designändringssynlighet som inte finns i något nuvarande överlämningsverktyg. Figma har sin egen versionshistorik, men den är visuell och designerorienterad. En paketdiff är strukturerad och utvecklarorienterad: maskinläsbar ändringsdata som kan driva automatiserade tester, uppdatera ändringsloggar eller utlösa CI-arbetsflöden.
CI/CD för designöverlämning
När överlämning är deterministisk följer CI/CD naturligt. Du kan skriva tester som körs mot ett paket: "den här skärmen måste inkludera en Button/Primary-komponent," "den här token måste vara bunden och inte ett hårdkodat värde," "den här strängen måste ha en stringRef-nyckel." Det här är statiska analyscheck mot strukturerad data. De körs på millisekunder. De körs i en pipeline.
Du kan också validera utdatan från kodgenereringsagenten mot paketet det fick. Använde agenten tokens eller hårdkodade det literaler? Genererade det rätt antal instanser av den upprepade komponenten? Använde det korrekta avståndsvärden? De här frågorna är besvaringsbara när sanningskällan är en strukturerad fil, inte en PNG.
MCP-jämförelsen
MCP-liknande live-anslutningar till Figma vinner mark. Lockelsen är uppenbar: agenten ser alltid den senaste designen, inget exportsteg, ingen manuell pakethantering. Men live-anslutningar byter determinism mot bekvämlighet — och för AI-agenter är det bytet dåligt.
Live-anslutningar innebär: agentens kontext beror på när den körs. En körning kl. 9 och en körning kl. 14 ser olika data om designern arbetat under dagen. Du kan inte reproducera den tidigare körningen. Du kan inte testa mot en fast indata. Du kan inte granska vad agenten fick veta. Om den genererade koden är fel kan du inte skilja på "modellen gjorde en dålig slutledning" från "designen ändrades under agenten."
Den rätta modellen är: live-anslutningar för designutforskning och iteration (där aktualitet spelar roll), deterministiska paket för överlämning och generering (där reproducerbarhet spelar roll). De konkurrerar inte — de opererar vid olika punkter i arbetsflödet.
Överlämna till en juniorutvecklare
Samma egenskaper som gör paket bra för AI-agenter gör dem bra för mänskliga utvecklare som är nya i en kodbas. En juniorutvecklare som fått ett paket har: den kompletta specifikationen i CONTEXT.md, alla tokenvärden i tokens.json, varje komponent listad med sina egenskaper, varje sträng med sin identitet. De behöver inte vara i Figma-filen. De behöver inget Figma-konto. De behöver inte veta vilken skärm som är den auktoritativa.
Paketet är en komplett, självständig arbetsorder. Precis som en agent skulle ta emot. Den enda skillnaden är att människan läser det och agenten bearbetar det programmatiskt — men artefakten är identisk.
Den föreningen — samma artefakt, mänsklig eller agent-konsument — är poängen. Paketet är överlämningsenheten. Allt annat är implementationsdetaljer.
Se deterministisk överlämning i praktiken med Claude Code, Cursor, eller Aider. Alla börjar från samma figmascope-export.