Här är arbetsflödet som blivit standard i varje design-till-kod-team just nu: exportera en ram från Figma, klistra in PNG:n i Claude eller Cursor, skriv "bygg det här", och iterera från den hallucinerade utdatan. Det fungerar precis tillräckligt bra för att kännas produktivt. Det fungerar inte tillräckligt bra för att leverera ifrån.

Det här är inte ett modellkapacitetsproblem. Det är ett indataproblem. Skärmdumpen är den sämsta möjliga representationen av en Figma-design för ett LLM att resonera kring — och det är nästan alltid det team når för först. figmascope-kontextpaketet är det strukturerade alternativet.

Hierarkin är borta

En Figma-fil är ett träd. Ramar innehåller auto-layout-grupper, som innehåller komponentinstanser, som innehåller text- och fyllnadslager. Det trädet kodar layoutavsikten: den här raden är en flex-behållare, det här kortet är en utfylld ruta, de här tre objekten är syskon med 16px-gap mellan sig.

En skärmdump plattar ut det trädet till ett rutnät av pixlar. LLM:et ser former och färger. Det ser inte layoutstrukturen — det härleder den. Och slutledning är förlustig i båda riktningarna: modellen kan rekonstruera struktur som ser rätt ut visuellt men är fel semantiskt (en div med fast bredd istället för ett flex-barn, absolut positionering istället för auto-layout), eller så kan den se strukturell tvetydighet och välja en godtyckligt.

Du kan inte avgöra från en PNG om en horisontell rad med objekt är implementerad med display: flex, CSS Grid, en anpassad HStack eller tre absolut-positionerade divar. De är visuellt identiska. LLM:et väljer en. Valet ändras mellan körningar.

Semantik överlever inte rastrering

LLM:et kan se att en rektangel med rundade hörn innehåller lite text och en ikon. Vad det inte kan se:

Semantik i Figma lever i lagerträdet: komponentnamn, variantegenskaper, nodslag. En Button/Primary/Large-komponent är explicit typad. I en skärmdump är det en rundad rektangel med en skugga och en etikett. Modellen gissar "det här är förmodligen en knapp" korrekt för det mesta — och gissar sedan "det här är förmodligen primary-varianten" baserat på färg, vilket kanske eller kanske inte matchar ditt designsystems faktiska namngivning.

Små felaktigheter adderas. En ghost-knapp renderad som en knapp med kontur. Ett tooltip renderat som en modal-utlösare. Ett inaktiverat tillstånd renderat som aktivt. Vart och ett av dessa är ett skärmdumpsslutledningssteg bort från sanningskällan.

Mellanrumssystem löser sig inte till siffror

Titta på en skärmdump av ett kort med utfyllnad. Vad är utfyllnaden? Du kan inte säga utan att mäta pixlar, känna till canvas-skalan, känna till exportupplösningen och göra beräkningen. LLM:et gör beräkningen dåligt — det uppskattar, det avrundar, och det har inget sätt att veta om ditt mellanrumssystem använder ett 8px-basgrid eller ett 4px-sådant eller något anpassat.

Så det gissar. Det genererar padding: 12px när designen säger 16. Det genererar gap: 8px när designen säger 12. Dessa siffror ser rimliga ut isolerat men de är fel — och om ditt designsystem använder mellanrumstokens som spacing.md eller Spacing/400 vet LLM:et ingenting om dem. Det hårdkodar literaler som driftar från ditt system i samma ögonblick något ändras.

LLM:et hallucinerar inte. Det gör precis vad du skulle göra med bara en skärmdump: gissar. Du förvånas bara när gissningarna är fel eftersom du kunde se det rätta svaret i Figma-filen hela tiden.

Tokenrelationer försvinner

Din designer ställde in bakgrunden till #7F5CFE. I Figma är det hexvärdet bundet till en variabel: color/brand/primary. Den bindningen är meningsfull — den innebär att färgen deltar i tematisering, den innebär att mörkt läge byter ut den, den innebär att om varumärkesfärgen ändras uppdaterar du en variabel och varje instans uppdateras.

I skärmdumpen: det är lila. LLM:et genererar background-color: #7F5CFE. Tokenrelationen är borta. Din kodbas har nu ett hårdkodat hex som aldrig spårar med ditt designsystem. Multiplicera det med varje komponent på skärmen.

Detsamma gäller typografiskalor, kantradie och skuggedefinitioner. Varje värde i en välunderhållen Figma-fil är potentiellt ett namngivet token. Varje värde i en skärmdump är bara en siffra.

Komponentåteranvändning är osynlig

En välkomponerad skärm återanvänder komponenter. De fyra produktkorten är fyra instanser av samma ProductCard-komponent. Avataren i navbaren och avataren i kommentarstråden är båda instanser av Avatar/Medium. Det spelar roll för kod: du vill ha en React-komponent, inte fyra handgjorda varianter som kommer att divergera.

Från en skärmdump ser LLM:et fyra visuellt liknande rektanglar. Det kan generera en återanvändbar komponent — eller så kan det generera fyra nästan-identiska block av JSX eftersom det inte märkte att de var samma sak. Det finns ingen signal i bilden för att säga vilket som är korrekt.

IR som figmascope exporterar bär componentId på varje instansnod. Agenten vet: de här fyra noderna är alla ProductCard. Generera det en gång, rendera det fyra gånger med olika props. Det är den utdata du vill ha. Det är den utdata du inte kan få från pixlar.

Strängidentitet går förlorad

Du har en "Fortsätt"-knapp på tre olika skärmar. Är de tre instanserna samma sträng, eller skrev en designer dem oberoende av varandra? I en välstrukturerad Figma-fil refererar de till samma strängnyckel. Det innebär en i18n-post, en ändring sprids överallt.

I tre skärmdumpar: tre gånger genererar LLM:et en hårdkodad sträng. Om du bygger en internationaliserad app har du nu tre strängar att hitta och ersätta istället för en att slå upp. Liten sak. Adderas över en riktig kodbas.

Varför LLM:et hallucinerar: det härleder struktur på nytt varje gång

Modellen har inget minne av tidigare körningar. Varje gång du klistrar in samma skärmdump rekonstruerar den strukturen från grunden. Rekonstruktionen är probabilistisk — vilket innebär att samma skärmdump + samma prompt + samma modell kan producera mätbart olika utdata vid olika körningar. Samma design, annan kod. Andra komponentnamn, andra className-mönster, andra layoutval.

Det här är inte ett modellfel. Det är det förväntade beteendet hos en probabilistisk modell givet otillräckliga begränsningar. Skärmdumpen tillhandahåller otillräckliga begränsningar. Modellen fyller i luckorna. Luckorna fylls i på olika sätt varje gång.

Du kan delvis arbeta runt det med längre, mer detaljerade promptar — "använd Tailwind, använd 8px-grid, använd dessa komponentnamn..." — men då har du manuellt specificerat strukturen som borde ha funnits i designfilen hela tiden. Du gör det extraheringsarbete som verktyget borde göra.

Reproducerbarhetsproblemet

Team som använder skärmdumpar för design-till-kod-överlämning stöter på samma problem: utdatan är inte reproducerbar. Två utvecklare, samma Figma-skärmdump, promptar Claude oberoende av varandra — de får olika komponentstrukturer, olika className-mönster, olika nästlingsbeslut. Nu har du två kodbaser som ser likadana ut visuellt men är arkitektoniskt inkonsekventa.

Det gör kodgranskning svårare. Det gör refaktorering svårare. Det gör designsystemsöverensstämmelsegranskning omöjlig. Du kan inte diffa "vad genererade agenten från den här designen" om svaret ändras vid varje körning.

Strukturerad kontext löser reproducerbarhet eftersom den löser indatan. Ett deterministiskt indatapaket — samma JSON med samma nod-ID:n, komponentnamn, tokenvärden och rumsliga relationer — producerar mycket mer konsekvent utdata över körningar, agenter och utvecklare. Inte perfekt deterministisk: modellen är fortfarande probabilistisk. Men variansen sjunker dramatiskt när strukturen specificeras snarare än härleds.

Vad en skärmdump ger dig vs. vad IR ger dig

Ta ett produktkort: bild, titel, undertitel, pris, en "Lägg i kundvagn"-knapp. Här är vad varje indata ger agenten:

Skärmdumpsindata: En rektangel med en bild överst, två rader text, ett tal och en knapp. Färger härledda. Utfyllnad uppskattad. Huruvida det här är en komponent eller engångssak är okänt. Knappvarianten härledd från färg. Mellanrumssystemet okänt.

IR-indata: Nodslag FRAME, namn ProductCard, komponent-ID som länkar till komponentdefinitionen. Auto-layout med vertikal riktning, 16px gap, 16px horisontell utfyllnad, 12px vertikal utfyllnad. Barnnoder: IMAGE (fyller bredd, fast höjd), TEXT med stringRef.key: "product.title" och stil typography/heading.sm, TEXT med stringRef.key: "product.subtitle" och stil typography/body.md, TEXT med fyllning color/price, INSTANCE av Button/Primary/Medium. Bakgrundsfyllning color/surface.card. Hörnradie radius/card.

IR ger agenten en spec. Skärmdumpen ger den ett förslag.

Inramningen: det här är dokumentationsproblemet

Vi löste det exakta problemet för källkod för decennier sedan. Du ger inte en agent en skärmdump av din kodbas och ber den resonera kring arkitektur. Du ger den koden — den strukturerade, tolkningsbara, semantiskt meningsfulla representationen. Det abstrakta syntaxträdet, inte en bild av editorn.

Figma-designs är strukturerad data. De har en väldefinierad trädstruktur med typade noder och namngivna värden. Figma API exponerar den här strukturen fullständigt. Det enda skälet till att skärmdumpsarbetsflödet består är att extrahera strukturen och formatera den som kontext har friktion.

Att minska den friktionen är vad figmascope gör. Du klistrar in Figma-URL:en, exporten körs i din webbläsare, och du får ett ZIP med strukturerad kontext: CONTEXT.md, tokens.json, per-skärm IR, komponentinventering, strängmanifest. Allt agenten behöver, inget av det härleds från pixlar.

Behåll skärmdumparna för visuell bekräftelse — paketet inkluderar 2x PNG:er för precis det ändamålet. Använd strukturen för allt annat. Se det i praktiken: Cursor-arbetsflöde, Claude Code-arbetsflöde eller Aider-arbetsflöde.