Softwareteams hebben tientallen jaren besteed aan het inbouwen van determinisme in hun toolchains. Lockfiles voor pakketbeheerders. Vastgepinde basisimages voor containers. Reproduceerbare builds voor gecompileerde artefacten. Het principe is welbekend: dezelfde invoer moet altijd dezelfde uitvoer produceren, op elke machine, op elk moment.

Ontwerpoverdracht heeft dit principe nooit toegepast. Het is standaard een fundamenteel menselijk en daardoor niet-deterministisch proces geweest. Een ontwerper legt het ontwerp uit aan een ontwikkelaar. De ontwikkelaar interpreteert het. De interpretatie varieert per persoon, per dag, afhankelijk van hoe duidelijk de Zeplin-opmerking was geschreven. Je kunt dat niet herspelen. Je kunt het niet testen. Je kunt het niet diffen.

In een wereld van AI-coderingsagents is niet-deterministische overdracht nu een eersteklas engineeringprobleem. figmascope pakt dit aan met een bevroren, draagbare contextbundel.

Waarom huidige tooling niet-deterministisch is voor agents

Zeplin en Avocode geven je getallen uit Figma — laagafmetingen, kleurwaarden, lettertypegrootten. Maar ze serveren deze als een bladerende UI, niet als een machine-leesbaar artefact. Een agent die naar Zeplin wordt gewezen, moet door een UI navigeren om de waarden te vinden, wat fragiel, rate-beperkt en afhankelijk is van hoe de annotaties zijn geschreven.

Figma Dev Mode gaat verder: het geeft je codefragmenten die inline worden gegenereerd vanuit het ontwerp. Maar de fragmenten zijn stateloos — on-demand gegenereerd, niet geversioneerd. Er is geen bundel die je kunt inchecken. Er is geen bestand dat je kunt diffen. Als de ontwerper het ontwerp bijwerkt, wordt de Dev Mode-weergave stilzwijgend bijgewerkt. Je weet niet wanneer het onderliggende ontwerp is veranderd ten opzichte van wat je het laatste hebt geëxporteerd.

Schermafbeeldingen zijn het slechtste geval: pure pixeldata, volledig niet-deterministisch te parsen, elke keer met een andere structuurinferentie.

Live MCP-verbindingen — tools die agents realtime API-toegang tot het Figma-bestand geven — zijn per definitie niet-deterministisch. Het bestand verandert terwijl de agent het leest. De run van de agent om 9 uur 's ochtends en zijn run om 14:00 uur zien verschillende invoer. Je kunt de run van 9 uur 's ochtends niet reproduceren omdat de bron is veranderd.

Agents zijn probabilistische systemen. Ze niet-deterministische invoer geven produceert niet alleen variantie — het maakt het systeem ontestbaar. Je kunt niet bepalen of een slechte uitvoer werd veroorzaakt door het model, de prompt, of het feit dat iemand een laag verplaatste tussen runs.

De bundel als compilatie-eenheid

Het juiste mentale model voor een figmascope-export is een compilatieartefact. Net zoals een compiler broncode neemt en een deterministisch binair bestand produceert — dezelfde bron, dezelfde vlaggen, hetzelfde binaire bestand — neemt figmascope een Figma-bestandsstatus en produceert een deterministische bundel: dezelfde bestandsstatus, dezelfde bundel, altijd.

De bundel is een bevroren momentopname. Het legt een specifieke versie van het ontwerp vast en serialiseert elke relevante eigenschap: ruimtelijke layout, component-identiteit, tokenbindingen, stringinhoud, hiërarchie. Eenmaal geëxporteerd is de bundel onveranderlijk. Het Figma-bestand kan veranderen; de bundel niet. Als je die wijzigingen wilt opnemen, exporteer je opnieuw en krijg je een nieuwe bundel.

Dit is het compilatie-eenheidsmodel. Het ontwerpbestand is de bron. De bundel is het artefact. Agents consumeren artefacten, geen bronnen.

Vier eigenschappen van een deterministische overdracht

Momentopnamen. Het overdrachtsartefact moet een specifiek moment in de tijd vertegenwoordigen. Niet "de huidige status van het Figma-bestand" — een benoemde, geversioneerde export. figmascope-bundels bevatten een _meta.json met een exporttijdstempel en een vingerafdruk van wat er is opgenomen. De bundel is een momentopname, geen live weergave.

Draagbaar. Het artefact moet op zichzelf staand zijn. Geen afhankelijkheden van externe diensten, live API's of ingelogde sessies. Een figmascope-bundel is een ZIP van gewone bestanden — JSON, Markdown, PNG. Je kunt hem kopiëren, e-mailen, inchecken in git, bijvoegen bij een PR, overhandigen aan een junior ontwikkelaar of een coding agent zonder installatie.

Inspecteerbaar. Een deterministisch artefact is nutteloos als je niet kunt controleren wat er in zit. Elk bestand in de bundel is leesbaar voor mensen. CONTEXT.md is Markdown. tokens.json is een W3C-achtige structuur. De per-scherm IR is JSON met duidelijke veldnamen. Een ingenieur kan de bundel openen en precies controleren wat de agent is verteld. Dit is kwalitatief anders dan "ik plakte de schermafbeelding en kreeg wat code."

Reproduceerbaar. Gegeven dezelfde Figma-bestandsstatus, moeten twee afzonderlijke exports functioneel equivalente bundels produceren. Niet byte-identiek (tijdstempels verschillen), maar semantisch identiek: dezelfde nodestructuren, dezelfde tokenwaarden, dezelfde componentinventaris. Als je tweemaal exporteert vanuit een ongewijzigd bestand en de bundels semantisch verschillen, is er iets mis. Deze eigenschap laat je de exportpijplijn valideren en regressies in de extractor zelf opsporen.

Hoe dit in de praktijk werkt

Een ontwerper rondt een sprint af met schermen. Ze exporteren een bundel. De bundel wordt gecominit naar de repo naast het ticket — of bijgevoegd aan het Jira-issue, of geplaatst in de gedeelde schijf, afhankelijk van je workflow. Op dit moment is het overdrachtsartefact vastgelegd. De agent (of de ontwikkelaar) werkt vanuit de bundel, niet vanuit het live Figma-bestand.

Halverwege de implementatie werkt de ontwerper drie schermen bij. Geen probleem: de werkbundel van de ontwikkelaar is ongewijzigd. De nieuwe schermen krijgen een nieuwe export. Nu heb je twee bundels en kun je ze diffen: wat veranderde er tussen het ontwerp waarmee de ontwikkelaar begon en het huidige ontwerp. Dit is precies de soort zichtbaarheid van wijzigingen die onmogelijk is met werkstromen op basis van schermafbeeldingen of live verbindingen.

In een multi-agent-workflow — één agent bouwt de componentenbibliotheek, een andere bouwt de schermlay-outs, een derde schrijft de tests — krijgt elke agent dezelfde bundel als bron van waarheid. Ze werken allemaal vanuit dezelfde bevroren ontwerpstatus. Hun uitvoer is componeerbaar omdat hun invoer gedeeld en vastgelegd is. Dit is de randvoorwaarde voor multi-agent UI-generatie die werkelijk betrouwbaar is.

Bundels diffen

Omdat de bundel gewone bestanden zijn, wordt hij gedifft zoals code. Twee exports van hetzelfde bestand over twee Figma-versies geven je een JSON-diff die precies vertelt wat er veranderde:

Dit is zichtbaarheid van ontwerpwijzigingen die niet bestaat in enige huidige overdrachtstool. Figma heeft zijn eigen versiegeschiedenis, maar die is visueel en gericht op ontwerpers. Een bundeldiff is gestructureerd en gericht op ontwikkelaars: machine-leesbare wijzigingsdata die geautomatiseerde tests kan aansturen, changelogs bijwerken of CI-workflows activeren.

CI/CD voor ontwerpoverdracht

Zodra overdracht deterministisch is, volgt CI/CD vanzelf. Je kunt tests schrijven die worden uitgevoerd op een bundel: "dit scherm moet een Button/Primary-component bevatten," "dit token moet gebonden zijn en geen hardgecodeerde waarde," "deze string moet een stringRef-sleutel hebben." Dit zijn statische analysecontroles op gestructureerde data. Ze draaien in milliseconden. Ze draaien in een pijplijn.

Je kunt ook de uitvoer van de codegen-agent valideren op basis van de bundel die hij heeft ontvangen. Gebruikte de agent de tokens of hardcodeerde het letterwaarden? Genereerde het het juiste aantal instanties van het herhaalde component? Gebruikte het de juiste tussenruimtewaarden? Deze vragen zijn beantwoordbaar wanneer de bron van waarheid een gestructureerd bestand is, niet een PNG.

De MCP-vergelijking

MCP-achtige live verbindingen met Figma winnen aan populariteit. De aantrekkingskracht is duidelijk: de agent ziet altijd het laatste ontwerp, geen exportstap, geen handmatig bundelbeheer. Maar live verbindingen ruilen determinisme voor gemak — en voor AI-agents is die ruil slecht.

Live verbindingen betekenen: de context van de agent hangt af van wanneer hij draait. Een run om 9 uur 's ochtends en een run om 14:00 uur zien andere gegevens als de ontwerper overdag heeft gewerkt. Je kunt de eerdere run niet reproduceren. Je kunt niet testen op een vaste invoer. Je kunt niet controleren wat de agent is verteld. Als de gegenereerde code onjuist is, kun je "het model maakte een slechte inferentie" niet onderscheiden van "het ontwerp veranderde onder de agent."

Het juiste model is: live verbindingen voor ontwerpverkenning en iteratie (waar recentheid telt), deterministische bundels voor overdracht en generatie (waar reproduceerbaarheid telt). Ze concurreren niet — ze werken op verschillende punten in de workflow.

Overdragen aan een junior ontwikkelaar

Dezelfde eigenschappen die bundels goed maken voor AI-agents maken ze goed voor menselijke ontwikkelaars die nieuw zijn in een codebase. Een junior ontwikkelaar met een bundel heeft: de volledige specificatie in CONTEXT.md, alle tokenwaarden in tokens.json, elk component vermeld met zijn eigenschappen, elke string met zijn identiteit. Ze hoeven niet in het Figma-bestand te zijn. Ze hebben geen Figma-account nodig. Ze hoeven niet te weten welk scherm het gezaghebbende is.

De bundel is een complete, op zichzelf staande werkopdracht. Hetzelfde als een agent zou ontvangen. Het enige verschil is dat de mens het leest en de agent het programmatisch verwerkt — maar het artefact is identiek.

Die eenwording — hetzelfde artefact, menselijke of agentconsument — is het punt. De bundel is de eenheid van overdracht. Al het andere is implementatiedetail.

Zie deterministische overdracht in de praktijk met Claude Code, Cursor, of Aider. Alle starten vanuit dezelfde figmascope-export.