Kontekst staje się wąskim gardłem w programowaniu wspomaganym przez AI. Nie możliwości modeli. Modele poprawiają się na tyle szybko, że rzadko kiedy to one stanowią ograniczenie. To, co limituje jakość kodu generowanego przez AI, to jakość kontekstu, jaki te modele otrzymują.

W przepływach Figma-to-code kontekst przybiera dwie zasadniczo różne formy: kontekst pikselowy (zrzuty ekranu, renderowane obrazy) i kontekst strukturalny (typowany IR, tokens, relacje semantyczne). To nie są tylko różne formaty tych samych informacji. To różne kategorie danych wejściowych, o różnych właściwościach, różnej utracie informacji i różnych pułapach tego, co agent może z nich wyprodukować.

Branża wciąż w dużej mierze używa kontekstu pikselowego. To błąd. figmascope eksportuje kontekst strukturalny — właściwe dane wejściowe od samego początku.

Czym jest kontekst pikselowy

Kontekst pikselowy to każda rasteryzowana reprezentacja projektu: zrzut ekranu wyeksportowany z Figmy, PNG z „Eksportuj ramkę", render z narzędzia projektowego. To to, co dostajesz, gdy naciskasz Cmd+Shift+4 nad płótnem Figmy.

LLM-y z możliwościami wizji przetwarzają kontekst pikselowy imponująco dobrze. Rozpoznają wzorce UI, identyfikują obszary układu, wnioskują typy komponentów z wyglądu i generują sensowny kod z samych obrazów. Jeśli używałeś Claude lub GPT-4V do konwersji zrzutów ekranu na kod, widziałeś to. Wyniki wyglądają poprawnie częściej, niż można by się spodziewać.

Ale „wygląda poprawnie" i „jest poprawny" to nie to samo, a różnica między nimi kryje się właśnie tam, gdzie żyją zgodność z systemem projektowym, wierność tokenów, tożsamość komponentów i reprodukowalność.

Czym jest kontekst strukturalny

Kontekst strukturalny to typowana, czytelna maszynowo reprezentacja zachowująca semantykę projektu: czym każdy element jest, a nie tylko jak wygląda. Zawiera:

IR figmascope właśnie tym jest. Każdy węzeł w JSON per-screen ma kind, name, absoluteBoundingBox, children, wypełnienia rozwiązane do odwołań tokenów tam gdzie dostępne, właściwości auto-layoutu jeśli dotyczy, oraz componentId na instancjach. To drzewo projektu uczynione jawnym.

Kontekst pikselowy mówi agentowi, jak projekt wygląda. Kontekst strukturalny mówi mu, co projekt oznacza. Agent kodowania potrzebuje znaczenia, żeby pisać kod, nie wyglądu. Wygląd jest dla testów wizualnych.

Co ginie w kierunku piksel→struktura

Podstawową wadą kontekstu pikselowego jest nieodwracalna utrata informacji. Gdy Figma renderuje ramkę do PNG, odrzuca dokładnie te informacje, które są najważniejsze dla generowania kodu:

Drzewo warstw się zwija. Nie ma już „grupy trzech elementów z odstępami 8px". Jest obszar pikseli sugerujący grupę. Agent musi odtworzyć strukturę drzewa z dowodów wizualnych, a rekonstrukcja jest przybliżona. Będzie błędna w pewnym odsetku przypadków. Ten odsetek rośnie wraz ze złożonością projektu.

Powiązania tokenów znikają. Pomarańczowe tło mapujące się na color/action/primary staje się #FF6B00. Agent generuje zakodowaną na stałe wartość hex. Jeśli twój kolor kiedykolwiek się zmieni, jeśli obsługujesz tryb ciemny, lub jeśli musisz zaudytować użycie tokenów — ta zakodowana wartość jest obciążeniem.

Tożsamość komponentów znika. Cztery instancje tego samego komponentu karty to cztery podobnie wyglądające prostokąty. Agent może wygenerować jeden komponent wielokrotnego użytku lub cztery podobne, ale nie identyczne bloki, zależnie od tego, ile strukturalnego podobieństwa wnioskuje. Chcesz przewidywalnego wyniku; dostajesz probabilistyczny.

Intencja układu jest niejednoznaczna. Czy to flex row czy grid? Czy odstęp między elementami to gap czy margin czy padding na każdym elemencie? Piksele tego nie mówią. Agent wybiera. Wybory różnią się między uruchomieniami.

Pipeline Figma → React, z i bez struktury

Rozważ ścieżkę od Figmy do produkcyjnego React.

Z kontekstem pikselowym: Eksportuj PNG. Wklej do Claude. Otrzymaj JSX. Sprawdź poprawność JSX. Zauważ zakodowane wartości. Zauważ błędną strukturę komponentów. Wyślij prośby o poprawki. Iteruj. W końcu dostań coś sensownego. Ręcznie edytuj, żeby pasowało do systemu projektowego. Wyślij. Następny ekran: powtarzaj od początku, bo wyniki poprzedniego uruchomienia nie komponują się.

Z kontekstem strukturalnym: Eksportuj pakiet (jedno kliknięcie, działa w przeglądarce). Przekaż CONTEXT.md + IR ekranu do Claude z promptem systemowym określającym framework i konwencje systemu projektowego. Otrzymaj JSX używający twoich nazw tokenów, nazw komponentów, poprawnej struktury układu. Sprawdź poprawność. Wyślij. Następny ekran: ten sam pakiet, ten sam agent, komponowalne wyniki, bo dane wejściowe są spójne.

Oszczędności pracy są realne, ale drugorzędne. Główna korzyść to komponowalność. Kontekst strukturalny umożliwia wyniki, które komponują się między ekranami i agentami. Kontekst pikselowy nie — wynik każdego ekranu to wyspa wygenerowana z nowego przebiegu wnioskowania.

Struktura oznacza: typowany

Każdy węzeł w IR ma kind. To ma natychmiastowe znaczenie. Węzeł TEXT generuje element tekstowy. FRAME z auto-layoutem generuje kontener. INSTANCE z Button/Primary/Large generuje wywołanie komponentu przycisku z odpowiednimi propsami. VECTOR generuje odwołanie do ikony.

Agent nie zgaduje. Mapuje rodzaje na prymitywy kodu. Mapowanie jest określone w CONTEXT.md dla docelowego frameworka. „Dla węzłów INSTANCE użyj nazwy komponentu do określenia komponentu React. Dla FRAME z layoutMode HORIZONTAL użyj flex row. Dla TEXT ze stylem typography/heading.lg użyj komponentu Heading." To są reguły w stylu kompilatora, nie zadania wnioskowania.

Struktura oznacza: przestrzenny

absoluteBoundingBox na każdym węźle daje pozycję i rozmiar w przestrzeni współrzędnych Figmy. W połączeniu z właściwościami auto-layoutu — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — agent ma wszystko, czego potrzebuje do generowania poprawnego kodu układu bez liczenia pikseli.

Bezwzględne bounding boksy pozwalają też agentowi weryfikować wynik: jeśli wygenerowany komponent ma inne wymiary niż określone w IR, coś poszło nie tak. To jest sprawdzalna właściwość kontekstu strukturalnego, która nie ma odpowiednika w kontekście pikselowym.

Struktura oznacza: świadomy tożsamości

Gdy cztery węzły w IR współdzielą componentId, agent wie, że są instancjami tego samego komponentu. Generuje definicję komponentu raz, wyciąga propsy z wariantów w instancjach i renderuje cztery wywołania. To jest poprawny wynik. Nie jest osiągalny z kontekstu pikselowego bez znaczącej inżynierii promptów, która zasadniczo prosi agenta o ponowne wyprowadzenie struktury, którą plik projektu już miał.

Odniesienia krzyżowe ciągów działają tak samo. Gdy wiele węzłów tekstowych odwołuje się do stringRef.key: "action.continue", agent wie, że ma użyć jednego wyszukiwania i18n, a nie trzech zakodowanych ciągów. Informacje o tożsamości są w IR; agent po prostu je odczytuje.

Struktura oznacza: podlegający kontroli wersji

Czyste pliki JSON diffują się sprawnie. Zmieniona wartość paddingu pojawia się jako jednoliniowa zmiana w IR per-screen. Zmieniony token pojawia się jako diff find-replace w pliku tokenów. Nowa instancja komponentu pojawia się jako dodany obiekt w tablicy children.

To historia wersji projektu, która jest faktycznie przydatna dla inżynierów. Nie „projekt był aktualizowany we wtorek", ale „oto trzy właściwości, które zmieniły się między eksportami v2 i v3 tego ekranu". Możesz to wstawić do opisu PR. Możesz uruchomić automatyczne sprawdzenia. Możesz użyć tego do audytu, czy zmiana kodu odpowiada zmianie projektu.

Dokąd to prowadzi: infrastruktura kontekstu projektu

Kategoria narzędzi, która się tu formuje, to nie „eksport Figmy, ale lepszy". To nowa warstwa w stosie: infrastruktura kontekstu projektu. Zadaniem tej warstwy jest transformacja źródła projektu (pliki Figmy, biblioteki komponentów, systemy tokenów) w strukturalne, czytelne dla agentów, kontrolowane wersjonowo artefakty, które zasilają warstwę generowania kodu.

Ta warstwa leży między narzędziem projektowym a agentem kodowania. Ma obowiązki, których żadna ze stron obecnie nie obsługuje: zarządzanie snapshotami, ekstrakcja semantyczna, rozwiązywanie tokenów, inwentarz komponentów, indeksowanie ciągów między ekranami, wersjonowanie pakietów. To są zagadnienia infrastrukturalne, nie zagadnienia narzędzia projektowego ani LLM.

Traktowanie tego jako infrastruktury oznacza: jest zautomatyzowane, wersjonowane, działa w CI, ma zdefiniowany format, jest inspekowalne. Tak jak system budowania jest infrastrukturą dla kodu — nie samym kodem, nie docelowym binarium, ale niezawodnym, reprodukowalnym potokiem, który konwertuje jedno w drugie.

Uczciwie: piksele wciąż mają znaczenie

Pakiety figmascope zawierają 2x PNG każdego eksportowanego ekranu. Nie dlatego, że PNG napędza generowanie kodu, ale dlatego, że wizualne potwierdzenie ma znaczenie. Agent powinien móc porównać wygenerowany wynik z PNG. Deweloper powinien móc spojrzeć na ekran bez otwierania Figmy. PNG to sprawdzenie zdroworozsądkowe, nie specyfikacja.

To rozróżnienie — piksele do potwierdzenia, struktura do specyfikacji — to właściwy model mentalny. Nie eliminujesz kontekstu pikselowego; demownujesz go do jego właściwej roli. To artefakt QA, nie dane wejściowe budowania.

Tak samo jak nie dałbyś kompilatorowi zrzutu ekranu swojego kodu źródłowego: dajesz mu źródło i używasz zrzutów ekranu do dokumentacji. Plik projektu to źródło. Pakiet to artefakt kompilacji. PNG to obraz dokumentacji.

Dokąd to prowadzi dla multi-target codegen

Kontekst strukturalny umożliwia przepływ pracy, który kontekst pikselowy nie może: jeden projekt, wiele celów. Ten sam IR może zasilić generator React/Tailwind, generator Jetpack Compose i generator SwiftUI. Podstawowy projekt jest ten sam; kontekst specyficzny dla celu (prymitywy frameworka, konwencje nazewnictwa, API układu) żyje w CONTEXT.md, który jest generowany per-cel.

To multi-target codegen, który naprawdę skaluje się. Eksportujesz jeden pakiet z projektu. Uruchamiasz trzech agentów z trzema różnymi plikami CONTEXT.md. Dostajesz trzy implementacje, które są strukturalnie równoważne, bo zostały wygenerowane z tego samego IR, a nie z trzech oddzielnych przebiegów wnioskowania nad trzema zrzutami ekranu.

Wąskim gardłem dla tego przepływu pracy nie jest zdolność modelu. To jakość kontekstu. Kontekst strukturalny jest tym, co to umożliwia.

Eksportuj swój pakiet kontekstu strukturalnego z głównej aplikacji figmascope, a następnie użyj go z Cursor, Claude Code lub Aider do wielocelowego, komponowalnego generowania UI.