Tento postup se stal standardem v každém týmu pracujícím na převodu designu do kódu: exportujte frame z Figmy, vložte PNG do Claude nebo Cursor, napište „build this" a iterujte od halucinovaného výstupu. Funguje to dostatečně dobře, aby to vypadalo produktivně. Nefunguje to dostatečně dobře na to, aby se z toho dalo přímo nasadit do produkce.

Nejde o problém schopností modelu. Jde o problém vstupu. Screenshot je nejhorší možná reprezentace Figma designu, nad kterou může LLM uvažovat — a přesto je to téměř universálně to první, po čem týmy sáhnou. Kontextový bundle figmascope je strukturovaná alternativa.

Hierarchie je pryč

Figma soubor je strom. Framy obsahují skupiny s auto-layoutem, které obsahují instance komponent, které obsahují textové a výplňové vrstvy. Tento strom kóduje záměr rozvržení: tento řádek je flex kontejner, tato karta je odsazený box, tyto tři položky jsou sourozenci s mezerami 16px mezi nimi.

Screenshot zploští tento strom na mřížku pixelů. LLM vidí tvary a barvy. Nevidí strukturu rozvržení — tu odvozuje. A odvozování je ztrátové v obou směrech: model může rekonstruovat strukturu, která vypadá vizuálně správně, ale je sémanticky chybná (div s pevnou šířkou místo flex potomka, absolutní pozicování místo auto-layoutu), nebo může vidět strukturní nejednoznačnost a vybrat jednu možnost libovolně.

Z PNG nelze poznat, zda je horizontální řada položek implementována pomocí display: flex, CSS Grid, vlastního HStack nebo třemi absolutně pozicovanými divy. Vizuálně jsou identické. LLM vybere jednu možnost. Výběr se mění mezi jednotlivými spuštěními.

Sémantika nepřežije rasterizaci

LLM vidí, že obdélník se zaoblenými rohy obsahuje nějaký text a ikonu. Co nevidí:

Sémantika ve Figmě žije ve stromě vrstev: názvy komponent, vlastnosti variant, typy uzlů. Komponenta Button/Primary/Large je explicitně typována. Na screenshotu je to zaoblený obdélník se stínem a popiskem. Model správně odhadne „tohle je pravděpodobně tlačítko" většinu času — a pak odhadne „tohle je pravděpodobně primární varianta" na základě barvy, což může, ale nemusí odpovídat skutečnému pojmenování ve vašem design systému.

Malé nesrovnalosti se kumulují. Ghost tlačítko zobrazené jako ohraničené tlačítko. Tooltip zobrazený jako spouštěč modálního okna. Zakázaný stav zobrazený jako aktivní. Každý z těchto problémů je jeden krok inference screenshotu od zdroje pravdy.

Systémy mezer se nerozloží na čísla

Podívejte se na screenshot karty s odsazením. Jaké je odsazení? Bez měření pixelů, znalosti měřítka plátna, znalosti rozlišení exportu a výpočtu to nelze zjistit. LLM tento výpočet provádí špatně — odhaduje, zaokrouhluje a nemá žádný způsob, jak poznat, zda váš systém mezer používá základní mřížku 8px, 4px nebo něco vlastního.

Takže hádá. Vygeneruje padding: 12px, když design říká 16. Vygeneruje gap: 8px, když design říká 12. Tato čísla vypadají izolovaně věrohodně, ale jsou špatná — a pokud váš design systém používá spacing tokeny jako spacing.md nebo Spacing/400, LLM o nich vůbec neví. Pevně zakóduje literály, které se od vašeho systému odchýlí v okamžiku, kdy se cokoliv změní.

LLM nehalucinuje. Dělá přesně to, co byste dělali jen se screenshotem: hádá. Jen vás překvapí, když jsou odhady špatné, protože jste správnou odpověď viděli ve Figma souboru celou dobu.

Vztahy tokenů mizí

Váš designér nastavil pozadí na #7F5CFE. Ve Figmě je tento hex svázán s proměnnou: color/brand/primary. Tato vazba je smysluplná — znamená, že barva se účastní témování, znamená, že tmavý režim ji vymění, znamená, že pokud se změní brandová barva, aktualizujete jednu proměnnou a každá instance se aktualizuje.

Na screenshotu: je to fialová. LLM vygeneruje background-color: #7F5CFE. Vztah tokenu je pryč. Váš kód nyní obsahuje pevně zakódovaný hex, který nikdy nebude sledovat váš design systém. Vynásobte to každou komponentou na obrazovce.

Totéž platí pro typografické škály, poloměry ohraničení a definice stínů. Každá hodnota v dobře udržovaném Figma souboru je potenciálně pojmenovaný token. Každá hodnota na screenshotu je jen číslo.

Znovupoužití komponent je neviditelné

Dobře sestavená obrazovka znovupoužívá komponenty. Čtyři produktové karty jsou čtyři instance stejné komponenty ProductCard. Avatar v navigaci a avatar v vlákně komentářů jsou obě instance Avatar/Medium. To je důležité pro kód: chcete jednu React komponentu, ne čtyři ručně vytvořené variace, které se budou rozcházet.

Ze screenshotu LLM vidí čtyři vizuálně podobné obdélníky. Může vygenerovat jednu znovupoužitelnou komponentu — nebo může vygenerovat čtyři téměř identické bloky JSX, protože si nevšimlo, že jsou stejné. V obrázku není žádný signál, který by mu říkal, co je správné.

IR, které exportuje figmascope, nese componentId na každém uzlu instance. Agent ví: tyto čtyři uzly jsou všechny ProductCard. Vygenerujte ji jednou, vykreslete čtyřikrát s různými props. To je výstup, který chcete. To je výstup, který z pixelů nemůžete získat.

Identita řetězců se ztrácí

Máte tlačítko „Pokračovat" na třech různých obrazovkách. Jsou tyto tři instance stejný řetězec, nebo je designér napsal nezávisle? V dobře strukturovaném Figma souboru odkazují na stejný string klíč. To znamená jeden i18n záznam, jedna změna se propaguje všude.

Na třech screenshotech: LLM třikrát vygeneruje pevně zakódovaný řetězec. Pokud vytváříte internacionalizovanou aplikaci, máte nyní tři řetězce, které je třeba najít a nahradit, místo jednoho, který stačí vyhledat. Malá věc. Kumuluje se v reálném kódu.

Proč LLM halucinuje: pokaždé znovu odvozuje strukturu

Model nemá žádnou paměť z předchozích spuštění. Pokaždé, když vložíte stejný screenshot, rekonstruuje strukturu od nuly. Rekonstrukce je pravděpodobnostní — což znamená, že stejný screenshot + stejný prompt + stejný model může při různých spuštěních produkovat měřitelně různé výstupy. Stejný design, různý kód. Různé názvy komponent, různé vzory className, různé volby rozvržení.

To není chyba modelu. Je to očekávané chování pravděpodobnostního modelu s nedostatečnými omezeními. Screenshot poskytuje nedostatečná omezení. Model vyplňuje mezery. Mezery jsou pokaždé vyplněny jinak.

Toto lze částečně obejít delšími, podrobnějšími prompty — „používej Tailwind, používej mřížku 8px, používej tyto názvy komponent..." — ale pak jste ručně specifikovali strukturu, která měla být ve Figma souboru celou dobu. Děláte extrakční práci, kterou by měl dělat nástroj.

Problém reprodukovatelnosti

Týmy, které používají screenshoty pro předávání designu do kódu, narážejí na stejný problém: výstup není reprodukovatelný. Dva vývojáři, stejný Figma screenshot, nezávisle promtují Claude — dostanou různé struktury komponent, různé vzory className, různá rozhodnutí o vnořování. Nyní máte dva kódové základny, které vypadají vizuálně stejně, ale jsou architektonicky nekonzistentní.

To ztěžuje code review. Ztěžuje refaktoring. Znemožňuje audit souladu s design systémem. Nelze porovnat „co agent vygeneroval z tohoto designu", pokud se odpověď mění při každém spuštění.

Strukturovaný kontext opravuje reprodukovatelnost, protože opravuje vstupy. Deterministický vstupní bundle — stejný JSON se stejnými ID uzlů, názvy komponent, hodnotami tokenů a prostorovými vztahy — produkuje mnohem konzistentnější výstup napříč spuštěními, agenty a vývojáři. Ne dokonale deterministický: model je stále pravděpodobnostní. Ale rozptyl dramaticky klesá, když je struktura specifikována, nikoli odvozována.

Co vám dá screenshot vs. co vám dá IR

Vezměte si produktovou kartu: obrázek, název, podtitul, cena, tlačítko „Přidat do košíku". Zde je to, co každý vstup dává agentovi:

Vstup screenshot: Obdélník s obrázkem nahoře, dvě řádky textu, číslo a tlačítko. Barvy jsou odvozeny. Odsazení je odhadováno. Zda jde o komponentu nebo jednorázový prvek je neznámé. Varianta tlačítka je odvozena z barvy. Systém mezer je neznámý.

Vstup IR: Typ uzlu FRAME, název ProductCard, ID komponenty odkazující na definici komponenty. Auto-layout s vertikálním směrem, mezera 16px, horizontální odsazení 16px, vertikální odsazení 12px. Podřízené uzly: IMAGE (vyplňuje šířku, pevná výška), TEXT s stringRef.key: "product.title" a stylem typography/heading.sm, TEXT s stringRef.key: "product.subtitle" a stylem typography/body.md, TEXT s výplní color/price, INSTANCE z Button/Primary/Medium. Výplň pozadí color/surface.card. Poloměr ohraničení radius/card.

IR dává agentovi specifikaci. Screenshot mu dává návrh.

Rámec: toto je problém dokumentace

Tento přesný problém jsme vyřešili pro zdrojový kód před desítkami let. Agentovi nedáváte screenshot vaší kódové základny a nežádáte ho, aby uvažoval o architektuře. Dáváte mu kód — strukturovanou, parsovatelnou, sémanticky smysluplnou reprezentaci. Abstraktní syntaktický strom, ne obrázek editoru.

Figma designy jsou strukturovaná data. Mají dobře definovanou stromovou strukturu s typovanými uzly a pojmenovanými hodnotami. Figma API tuto strukturu zcela vystavuje. Jediný důvod, proč screenshot workflow přetrvává, je to, že extrakce struktury a její formátování jako kontext má tření.

Snížení tohoto tření je to, co dělá figmascope. Vložíte Figma URL, export proběhne ve vašem prohlížeči a dostanete ZIP se strukturovaným kontextem: CONTEXT.md, tokens.json, IR pro každou obrazovku, inventář komponent, manifest řetězců. Vše, co agent potřebuje, nic z toho není odvozeno z pixelů.

Screenshoty si nechte pro vizuální potvrzení — bundle obsahuje 2x PNG přesně pro tento účel. Strukturu používejte pro všechno ostatní. Podívejte se na to v praxi: workflow pro Cursor, workflow pro Claude Code, nebo workflow pro Aider.