Kontext håller på att bli flaskhalsen i AI-assisterad utveckling. Inte modellkapaciteten. Modellerna förbättras tillräckligt snabbt för att de regelbundet inte är begränsningen. Vad som begränsar kvaliteten på AI-genererad kod är kvaliteten på den kontext de modellerna får.

För Figma-till-kod-arbetsflöden kommer kontext i två fundamentalt olika former: pixelkontext (skärmdumpar, renderade bilder) och strukturerad kontext (typade IR, tokens, semantiska relationer). Det här är inte bara olika format för samma information. De är olika kategorier av indata, med olika egenskaper, olika förlustegenskaper och olika tak för vad en agent kan producera utifrån dem.

Branschen använder fortfarande till stor del pixelkontext. Det är ett misstag. figmascope exporterar strukturerad kontext — rätt indata från start.

Vad pixelkontext är

Pixelkontext är en rastrad representation av en design: en skärmdump exporterad från Figma, en PNG från "Export frame", en render från ett designverktyg. Det är vad du får när du trycker Cmd+Shift+4 över din Figma-canvas.

Visionsdugliga LLM:er kan bearbeta pixelkontext imponerande väl. De känner igen UI-mönster, identifierar layoutregioner, härledar komponenttyper från visuellt utseende och genererar plausibel kod från bilder ensamt. Om du har använt Claude eller GPT-4V för skärmdump-till-kod har du sett det här. Utdata ser rätt ut oftare än du förväntar dig.

Men "ser rätt ut" och "är rätt" är inte samma sak, och gapet mellan dem är där designsystemsöverensstämmelse, tokentrogenhet, komponentidentitet och reproducerbarhet alla lever.

Vad strukturerad kontext är

Strukturerad kontext är en typad, maskinläsbar representation som bevarar designens semantik: vad varje element är, inte bara hur det ser ut. Den inkluderar:

figmascopes IR är detta. Varje nod i en per-skärm JSON har kind, name, absoluteBoundingBox, children, fyllningar lösta till tokenreferenser där tillgängliga, auto-layout-egenskaper om tillämpliga, och componentId på instanser. Det är designträdet gjort explicit.

Pixelkontext berättar för en agent hur en design ser ut. Strukturerad kontext berättar vad en design betyder. En kodagent behöver mening för att skriva kod, inte utseende. Utseende är vad visuella tester är till för.

Vad som går förlorat i pixel-till-strukturerad-riktningen

Det centrala felsättet med pixelkontext är irreversibel informationsförlust. När Figma renderar en ram till PNG kasserar det exakt den information som spelar störst roll för kodgenerering:

Lagerträdet kollapsar. Det finns inte längre "en grupp med tre objekt med 8px-gap". Det finns en region av pixlar som antyder en grupp. Agenten måste rekonstruera trädstrukturen från visuella ledtrådar, och rekonstruktion är ungefärlig. Det blir fel en viss procentandel av gångerna. Den procentandelen växer när designs blir mer komplexa.

Tokenbindningar försvinner. Den orangea bakgrunden som mappar till color/action/primary blir #FF6B00. Agenten genererar ett hårdkodat hex. Om din färg någonsin ändras, eller om du stödjer mörkt läge, eller om du behöver granska tokenanvändning, är det hårdkodade värdet en skuld.

Komponentidentitet är borta. Fyra instanser av samma kortkomponent är fyra liknande rektanglar. Agenten kan generera en återanvändbar komponent eller fyra liknande-men-inte-identiska block, beroende på hur mycket strukturell likhet den härleder. Du vill ha förutsägbar utdata; du får probabilistisk utdata.

Layoutavsikt är tvetydig. Är det här en flex-rad eller ett grid? Är mellanrummet mellan objekt ett gap eller en marginal eller utfyllnad på varje objekt? Pixlarna säger inte. Agenten väljer. Valen skiljer sig mellan körningar.

Figma → React-pipelinen, med och utan struktur

Betrakta vägen från Figma till produktions-React.

Med pixelkontext: Exportera PNG. Klistra in i Claude. Få JSX. Granska JSX för korrekthet. Märk hårdkodade värden. Märk felaktig komponentstruktur. Begär korrigeringar. Iterera. Få så småningom något plausibelt. Redigera manuellt för att matcha designsystemet. Leverera. Nästa skärm: börja om från början eftersom föregående körnings utdata inte komponerar.

Med strukturerad kontext: Exportera paket (ett klick, körs i webbläsaren). Skicka CONTEXT.md + skärm-IR till Claude med ditt systemprompt som specificerar ramverk och designsystemskonventioner. Få JSX som använder dina tokennamn, dina komponentnamn, korrekt layoutstruktur. Granska för korrekthet. Leverera. Nästa skärm: samma paket, samma agent, komponierbara utdata eftersom indatan är konsekvent.

Arbetsbesparingarna är verkliga men sekundära. Den primära vinsten är komponibarhet. Strukturerad kontext möjliggör utdata som komponerar över skärmar och agenter. Pixelkontext gör det inte — varje skärms utdata är en ö genererad från ett nytt slutledningspass.

Struktur betyder: typad

Varje nod i IR har ett kind. Det spelar omedelbar roll. En TEXT-nod genererar ett textelement. En FRAME med auto-layout genererar en behållare. En INSTANCE av Button/Primary/Large genererar ett knappt komponentanrop med rätt props. En VECTOR genererar en ikonreferens.

Agenten gissar inte. Den mappar slag till kodprimitiver. Mappningen specificeras i CONTEXT.md för målramverket. "För INSTANCE-noder, använd komponentnamnet för att bestämma React-komponenten. För FRAME med layoutMode HORIZONTAL, använd en flex-rad. För TEXT med stil typography/heading.lg, använd Heading-komponenten." Det här är kompilatorliknande regler, inte slutledningsuppgifter.

Struktur betyder: rumslig

absoluteBoundingBox på varje nod ger position och storlek i Figmas koordinatutrymme. Kombinerat med auto-layout-egenskaper — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — har agenten allt den behöver för att generera korrekt layoutkod utan pixelräkning.

De absoluta begränsningsrutorna låter agenten verifiera sin utdata: om en genererad komponent har andra mått än IR specificerade gick något fel. Det här är en testbar egenskap hos strukturerad kontext som inte har någon motsvarighet i pixelkontext.

Struktur betyder: identitetsmedveten

När fyra noder i IR delar ett componentId vet agenten att de är instanser av samma komponent. Den genererar komponentdefinitionen en gång, härleder props från varianterna i instanserna och renderar fyra anrop. Det här är den korrekta utdatan. Det är inte möjligt att uppnå från pixelkontext utan betydande prompt engineering som i princip ber agenten att härleda struktur på nytt som designfilen redan hade.

Strängkorsreferenser fungerar på samma sätt. När flera textnoder refererar stringRef.key: "action.continue" vet agenten att använda en enda i18n-sökning, inte tre hårdkodade strängar. Identitetsinformationen finns i IR; agenten läser den bara.

Struktur betyder: versionskontrollerbar

Vanliga JSON-filer diffar rent. Ett ändrat utfyllnadsvärde visas som en enradsändring i per-skärm-IR. Ett omdöpt token visas som en sök-ersätt-diff i tokenfilen. En ny komponentinstans visas som ett tillagt objekt i children-arrayen.

Det här är designversionshistorik som faktiskt är användbar för ingenjörer. Inte "designen uppdaterades på tisdag" utan "här är de tre egenskaperna som ändrades mellan v2- och v3-exporterna av den här skärmen." Du kan sätta det i din PR-beskrivning. Du kan köra automatiserade kontroller på det. Du kan använda det för att granska om kodändringen matchar designändringen.

Vart detta leder: designkontext-infrastruktur

Verktygskategorin som formas här är inte "Figma-export, fast bättre." Det är ett nytt lager i stacken: designkontext-infrastruktur. Det här lagrets uppgift är att omvandla designkälla (Figma-filer, komponentbibliotek, tokensystem) till strukturerade, agentläsbara, versionskontrollerade artefakter som matar kodgenereringsskiktet.

Det här lagret sitter mellan designverktyget och kodagenten. Det har ansvar som varken sidan för tillfället äger: ögonblicksbildshantering, semantisk extraktion, tokenupplösning, komponentinventering, korsgranskad strängindexering, paketversionshantering. Det här är infrastrukturbekymmer, inte designverktygsskymmer och inte LLM-bekymmer.

Att behandla det som infrastruktur innebär: det är automatiserat, det är versionerat, det körs i CI, det har ett definierat format, det är inspekterbart. På samma sätt som ett byggsystem är infrastruktur för kod — inte koden själv, inte den binära målfilen, utan den pålitliga, reproducerbara pipeline som konverterar det ena till det andra.

Ärligt: pixlar spelar fortfarande roll

figmascope-paket inkluderar 2x PNG:er av varje exporterad skärm. Inte för att PNG:n driver kodgenerering, utan för att visuell bekräftelse spelar roll. En agent ska kunna korskontrollera sin genererade utdata mot PNG:n. En utvecklare ska kunna titta på skärmen utan att öppna Figma. PNG:n är en sanitetskontroll, inte en specifikation.

Denna distinktion — pixlar för bekräftelse, struktur för specifikation — är rätt mental modell. Du eliminerar inte pixelkontext; du degraderar den till sin korrekta roll. Det är QA-artefakten, inte byggindata.

På samma sätt som du inte skulle ge en kompilator en skärmdump av din källkod: du ger den källan och använder skärmdumpar för dokumentation. Designfilen är källan. Paketet är kompileringsartefakten. PNG:n är dokumentationsbilden.

Vart detta leder för multi-target-kodgenerering

Strukturerad kontext möjliggör ett arbetsflöde som pixelkontext inte kan: en design, flera mål. Samma IR kan mata en React/Tailwind-generator, en Jetpack Compose-generator och en SwiftUI-generator. Den underliggande designen är densamma; den målspecifika kontexten (ramverksprimitiver, namngivningskonventioner, layout-API:er) lever i CONTEXT.md, som genereras per mål.

Det här är multi-target-kodgenerering som faktiskt skalas. Du exporterar ett paket från designen. Du kör tre agenter med tre olika CONTEXT.md-filer. Du får tre implementationer som är strukturellt ekvivalenta eftersom de genererades från samma IR, inte från tre separata slutledningspass över tre skärmdumpar.

Flaskhalsen för det här arbetsflödet är inte modellkapacitet. Det är kontextkvalitet. Strukturerad kontext är vad som gör det möjligt.

Exportera ditt strukturerade kontextpaket från huvud-figmascope-appen, använd det sedan med Cursor, Claude Code eller Aider för multi-target, komponerbar UI-generering.