Context wordt de bottleneck bij AI-ondersteunde ontwikkeling. Niet de capaciteit van het model. Modellen verbeteren snel genoeg dat ze regelmatig niet de beperking zijn. Wat de kwaliteit van AI-gegenereerde code beperkt, is de kwaliteit van de context die die modellen ontvangen.
Voor Figma-naar-code-workflows komt context in twee fundamenteel verschillende vormen: pixelcontext (schermafbeeldingen, gerenderde afbeeldingen) en gestructureerde context (getypte IR, tokens, semantische relaties). Dit zijn niet alleen verschillende formaten voor dezelfde informatie. Het zijn verschillende categorieën invoer, met verschillende eigenschappen, verschillende verlieskenmerken en verschillende plafonds voor wat een agent ermee kan produceren.
De industrie gebruikt nog grotendeels pixelcontext. Dit is een vergissing. figmascope exporteert gestructureerde context — de juiste invoer vanaf het begin.
Wat pixelcontext is
Pixelcontext is elke gerasteriseerde weergave van een ontwerp: een schermafbeelding geëxporteerd uit Figma, een PNG via "Frame exporteren", een render van een ontwerptool. Het is wat je krijgt als je Cmd+Shift+4 gebruikt over je Figma-canvas.
Visie-capabele LLM's kunnen pixelcontext indrukwekkend goed verwerken. Ze herkennen UI-patronen, identificeren lay-outregio's, leiden componenttypen af uit visuele verschijning en genereren plausibele code uitsluitend op basis van afbeeldingen. Als je Claude of GPT-4V hebt gebruikt voor schermafbeelding-naar-code, heb je dit gezien. De uitvoer ziet er vaker juist uit dan je zou verwachten.
Maar "ziet er juist uit" en "is juist" zijn niet hetzelfde, en het gat daartussen is waar naleving van het ontwerpsysteem, tokenfideliteit, componentidentiteit en reproduceerbaarheid allemaal leven.
Wat gestructureerde context is
Gestructureerde context is een getypte, machineleesbare weergave die de semantiek van het ontwerp bewaart: wat elk element is, niet alleen hoe het eruitziet. Het omvat:
- Getypte knooppunten: elk element heeft een soort (
FRAME,TEXT,INSTANCE,VECTOR) die semantische betekenis draagt over zijn rol in de lay-out - Benoemde waarden: kleuren zijn tokenreferenties, geen hexstrings; spatiëringen zijn tokensleutels, geen pixelwaarden
- Ruimtelijke relaties: lay-outrichting, gap, opvulling, uitlijning — bewaard als eigenschappen, niet afgeleid uit positie
- Identiteitskoppelingen: componentinstanties dragen hun broncomponent-ID; strings dragen kruisreferentiesleutels
- Hiërarchie: de volledige knooppuntenboom, met ouder-kindrelaties intact
De figmascope-IR is dit. Elk knooppunt in een per-scherm JSON heeft kind, name, absoluteBoundingBox, children, vult opgelost naar tokenreferenties waar beschikbaar, auto-lay-outeigenschappen indien van toepassing, en componentId op instanties. Het is de ontwerpontenboom expliciet gemaakt.
Pixelcontext vertelt een agent hoe een ontwerp eruitziet. Gestructureerde context vertelt het wat een ontwerp betekent. Een coderingsagent heeft betekenis nodig om code te schrijven, geen uiterlijk. Uiterlijk is waar visuele tests voor zijn.
Wat verloren gaat in de pixel-naar-gestructureerde richting
De kernfout van pixelcontext is onomkeerbaar informatieverlies. Wanneer Figma een frame rendert naar PNG, gooit het precies de informatie weg die het meest belangrijk is voor codegeneratie:
De lagenboom vouwt samen. Er is niet langer een "groep van drie items met 8px-gaps." Er is een regio pixels die een groep suggereert. De agent moet de boomstructuur reconstrueren uit visueel bewijs, en reconstructie is approximatief. Het zal een bepaald percentage van de tijd fout zijn. Dat percentage groeit naarmate ontwerpen complexer worden.
Tokenbindingen verdwijnen. De oranje achtergrond die wordt gekoppeld aan color/action/primary wordt #FF6B00. De agent genereert een hardgecodeerde hex. Als je kleur ooit verandert, of als je dark mode ondersteunt, of als je tokengebruik moet controleren, is die hardgecodeerde waarde een aansprakelijkheid.
Componentidentiteit is weg. Vier instanties van hetzelfde kaartcomponent zijn vier gelijkuitziende rechthoeken. De agent kan één herbruikbaar component genereren of vier vergelijkbare-maar-niet-identieke blokken, afhankelijk van hoeveel structurele overeenkomst het afleidt. Je wilt voorspelbare uitvoer; je krijgt probabilistische uitvoer.
Lay-outintentie is dubbelzinnig. Is dit een flex-rij of een raster? Is de spatiëring tussen items een gap, een marge of opvulling op elk item? De pixels zeggen het niet. De agent kiest. De keuzes verschillen tussen runs.
De Figma → React pipeline, met en zonder structuur
Beschouw het pad van Figma naar productie React.
Met pixelcontext: Exporteer PNG. Plak in Claude. Ontvang JSX. Bekijk JSX op juistheid. Merk hardgecodeerde waarden op. Merk verkeerde componentstructuur op. Prompt voor correcties. Itereer. Uiteindelijk iets plausibels krijgen. Handmatig bewerken om overeen te komen met het ontwerpsysteem. Verzenden. Volgend scherm: herhaal van nul omdat de uitvoer van de vorige run niet componeert.
Met gestructureerde context: Exporteer bundel (één klik, werkt in browser). Geef CONTEXT.md + scherm-IR door aan Claude met je systemprompt die framework en ontwerpssysteemconventies specificeert. Ontvang JSX die jouw tokennamen, jouw componentnamen, correcte lay-outstructuur gebruikt. Bekijk op juistheid. Verzenden. Volgend scherm: dezelfde bundel, dezelfde agent, samentelbare uitvoer omdat de invoer consistent is.
De werkbesparingen zijn reëel maar secundair. De primaire winst is componeerbaarheid. Gestructureerde context maakt uitvoer mogelijk die componeert over schermen en agents heen. Pixelcontext doet dat niet — de uitvoer van elk scherm is een eiland dat is gegenereerd vanuit een nieuwe inferentieronde.
Structuur betekent: getypt
Elk knooppunt in de IR heeft een kind. Dit is onmiddellijk van belang. Een TEXT-knooppunt genereert een tekstelement. Een FRAME met auto-lay-out genereert een container. Een INSTANCE van Button/Primary/Large genereert een knopcomponent-aanroep met de juiste props. Een VECTOR genereert een pictogramreferentie.
De agent raadt niet. Het mapt soorten naar codeprimitieven. De mapping is gespecificeerd in CONTEXT.md voor het doelframework. "Voor INSTANCE-knooppunten gebruik je de componentnaam om het React-component te bepalen. Voor FRAME met layoutMode HORIZONTAL gebruik je een flex-rij. Voor TEXT met stijl typography/heading.lg gebruik je het Heading-component." Dit zijn compilerachtige regels, geen inferentietaken.
Structuur betekent: ruimtelijk
De absoluteBoundingBox op elk knooppunt geeft positie en grootte in de Figma-coördinatenruimte. Gecombineerd met auto-lay-outeigenschappen — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — heeft de agent alles wat het nodig heeft om correcte lay-outcode te genereren zonder pixeltelling.
De absolute begrenzingsvakken stellen de agent ook in staat om zijn uitvoer te verifiëren: als een gegenereerd component andere afmetingen heeft dan de IR specificeerde, ging er iets mis. Dit is een testbare eigenschap van gestructureerde context die geen equivalent heeft in pixelcontext.
Structuur betekent: identiteitsbewust
Wanneer vier knooppunten in de IR een componentId delen, weet de agent dat ze instanties zijn van hetzelfde component. Het genereert de componentdefinitie eenmalig, leidt props af uit de varianten in de instanties, en rendert vier aanroepen. Dit is de correcte uitvoer. Het is niet haalbaar vanuit pixelcontext zonder significante prompttechniek die de agent in feite vraagt om structuur te herleiden die het ontwerpbestand al had.
Stringkruisreferenties werken op dezelfde manier. Wanneer meerdere tekstknooppunten verwijzen naar stringRef.key: "action.continue", weet de agent dat het een enkele i18n-opzoeking moet gebruiken, niet drie hardgecodeerde strings. De identiteitsinformatie is in de IR; de agent leest die gewoon.
Structuur betekent: versiebeheersbaar
Gewone JSON-bestanden verwerken diffs netjes. Een gewijzigde opvulwaarde verschijnt als een één-regel-wijziging in de per-scherm-IR. Een hernoemde token verschijnt als een zoek-en-vervang-diff in het tokenbestand. Een nieuwe componentinstantie verschijnt als een toegevoegd object in de children-array.
Dit is ontwerpversiegeschiedenis die daadwerkelijk nuttig is voor engineers. Niet "het ontwerp is dinsdag bijgewerkt" maar "hier zijn de drie eigenschappen die veranderden tussen de v2- en v3-exports van dit scherm." Je kunt dit in je PR-beschrijving zetten. Je kunt er geautomatiseerde controles op uitvoeren. Je kunt het gebruiken om te controleren of de codewijziging overeenkomt met de ontwerpwijziging.
Waar dit toe leidt: ontwerpcontext-infrastructuur
De toolingcategorie die hier ontstaat, is niet "Figma-export, maar beter." Het is een nieuwe laag in de stack: ontwerpcontext-infrastructuur. De taak van deze laag is het omzetten van ontwerpbron (Figma-bestanden, componentbibliotheken, tokensystemen) in gestructureerde, agent-leesbare, versiegecontroleerde artefacten die de codegeneratielaag voeden.
Deze laag bevindt zich tussen de ontwerptool en de coderingsagent. Het heeft verantwoordelijkheden die geen van beide kanten momenteel bezit: snapshotbeheer, semantische extractie, tokenresolutie, componentinventaris, schermoverstijgende stringindexering, bundelversioning. Dit zijn infrastructuurkwesties, geen ontwerptoolkwesties en geen LLM-kwesties.
Het als infrastructuur behandelen betekent: het is geautomatiseerd, het is geversioneerd, het draait in CI, het heeft een gedefinieerd formaat, het is inspecteerbaar. Net zoals een bouwsysteem infrastructuur is voor code — niet de code zelf, niet het doelbinaire, maar de betrouwbare, reproduceerbare pijplijn die het ene naar het andere converteert.
Eerlijk: pixels zijn nog steeds belangrijk
figmascope-bundels bevatten 2x PNG's van elk geëxporteerd scherm. Niet omdat de PNG codegeneratie aanstuurt, maar omdat visuele bevestiging belangrijk is. Een agent moet zijn gegenereerde uitvoer kunnen kruisverwijzen met de PNG. Een ontwikkelaar moet het scherm kunnen bekijken zonder Figma te openen. De PNG is een gezondheidscontrole, geen specificatie.
Dit onderscheid — pixels voor bevestiging, structuur voor specificatie — is het juiste mentale model. Je elimineert pixelcontext niet; je degradeert het naar zijn juiste rol. Het is het QA-artefact, niet de bouwinvoer.
Net zoals je een compiler geen schermafbeelding van je broncode zou geven: je geeft het de bron, en je gebruikt schermafbeeldingen voor documentatie. Het ontwerpbestand is de bron. De bundel is het compilatieartefact. De PNG is de documentatieafbeelding.
Waar dit toe leidt voor multi-target codegen
Gestructureerde context maakt een workflow mogelijk die pixelcontext niet kan: één ontwerp, meerdere doelen. Dezelfde IR kan een React/Tailwind-generator, een Jetpack Compose-generator en een SwiftUI-generator voeden. Het onderliggende ontwerp is hetzelfde; de doelspecifieke context (framework-primitieven, naamconventies, lay-out-API's) leeft in CONTEXT.md, die per doel wordt gegenereerd.
Dit is multi-target codegen die daadwerkelijk schaalt. Je exporteert één bundel uit het ontwerp. Je voert drie agents uit met drie verschillende CONTEXT.md-bestanden. Je krijgt drie implementaties die structureel equivalent zijn omdat ze zijn gegenereerd uit dezelfde IR, niet uit drie afzonderlijke inferentieronden over drie schermafbeeldingen.
De bottleneck voor deze workflow is niet de capaciteit van het model. Het is de contextkwaliteit. Gestructureerde context is wat het mogelijk maakt.
Exporteer je gestructureerde contextbundel uit de figmascope-hoofdapp en gebruik het dan met Cursor, Claude Code of Aider voor multi-target, samentelbare UI-generatie.