From the field #07 - Figma do kodu, który nie halucynuje

Część 1: warstwa danych to miejsce, w którym to pęka

Większość treści o “design to code z AI” sprowadza się do tych samych trzech kroków. Zrób zrzut ekranu klatki w Figmie. Wklej do modelu. Módl się.

Działa. Dokładnie do momentu, w którym przestaje.

Dostajesz komponent z powrotem. Wygląda dobrze. Odstępy się prawie zgadzają, kolory się prawie zgadzają, layout czyta się poprawnie w podglądzie. Wdrażasz to. Dwa tygodnie później ktoś zmienia header i całość przesuwa się o cztery piksele, bo padding nigdy nie był 16px. Model zgadł 16px. Przeczytał obrazek i zwrócił najlepsze przypuszczenie co do tego, co ten obrazek znaczył.

Oto rzecz, której nikt nie mówi na głos przy tym workflow.

LLM to silnik probabilistyczny. Zgaduje najbardziej prawdopodobny ciąg znaków. W 99% przypadków zgaduje bezbłędnie. W pozostałym 1% produkuje cichy, kosztowny błąd, i najgorsze jest to, że wygląda dokładnie jak sukces. Zielony podgląd. Wiarygodny CSS. Liczba, która myli się o cztery piksele i wybuchnie przy następnej zmianie layoutu.

Kiedy podajesz modelowi zrzut ekranu, nie dajesz mu danych. Dajesz mu piksele i prosisz, żeby je zinterpretował. Interpretacja to zgadywanie. A w momencie, w którym zgadywanie wchodzi do twojej warstwy danych, zapisujesz się na tę 1-procentową katastrofę przy każdej pojedynczej właściwości, której model nie zdołał przeczytać precyzyjnie.

Lekarstwem nie jest lepszy prompt. Nie jest mądrzejszy model. Nie jest czekanie na następny release.

Lekarstwem jest nie pozwolić modelowi zgadywać w ogóle.

Kontekst przed modelem

To jest dokładnie ta sama zasada, którą stosuję wszędzie w QA i automatyzacji napędzanej AI. Model jest drugim krokiem. Pierwszym krokiem jest deterministyczny pipeline, który podaje modelowi czyste, dokładne dane, więc nie zostaje nic do zgadywania.

Dla design to code oznacza to jedną regułę: zrzut ekranu nigdy nie jest źródłem prawdy.

Figma już zna dokładne wartości. Każdy token odstępu, każdy kolor, każdy radius, każdy rozmiar fontu żyje w pliku jako dane strukturalne, nie jako wyrenderowany obrazek. Zadanie polega na tym, żeby przeczytać te dane strukturalne wprost, zamiast prosić model o odtworzenie ich z obrazka metodą inżynierii wstecznej.

Serwer Figma MCP robi właśnie to. get_design_context zwraca prawdziwy CSS dla node’a, faktyczne wartości, deterministycznie, takie same przy każdym uruchomieniu. get_variable_defs zwraca design tokeny. Endpoint do zrzutu ekranu też istnieje i ma dokładnie jedno uprawnione zastosowanie: wizualną referencję dla człowieka, który patrzy na wynik. Nigdy źródło wartości. W momencie, w którym wartość pochodzi ze zrzutu ekranu, wracasz do tego 1%.

Gdy ścieżka MCP nie jest dostępna, REST API z FIGMA_TOKEN zwraca to samo drzewo node’ów jako JSON. Inny transport, ta sama dyscyplina: czytaj wartości strukturalne, nie interpretuj renderu.

RULE ZERO

Deterministyczna ekstrakcja prowadzi cię przez większość drogi. Jeszcze jedna reguła domyka lukę, i to jest reguła, na której stoi całe podejście:

Jeśli właściwość jest nieobecna w wyciągniętym designie, jej wartość to zero albo none. Nigdy nie szacuj jej ze zrzutu ekranu. Nieobecne znaczy zero.

To brzmi niemal zbyt prosto, żeby miało znaczenie. To jedna, najważniejsza linia w całym systemie.

Bo trybem awarii nie jest wartość, którą design określa. Ta część jest łatwa. Czytasz ją, mapujesz, gotowe. Trybem awarii jest wartość, której design nie określa. To tutaj model chce być pomocny. Widzi lukę, wypełnia ją najbardziej prawdopodobną liczbą, i masz teraz zgadnięty margin, o który nikt nie prosił i którego nikt nie zauważy, dopóki czegoś nie zepsuje.

RULE ZERO zakazuje tej pomocności. Nieobecne w designie znaczy nieobecne w wyniku. Zero. Nie “pewnie 8px”. Nie “wygląda na to, że jest tam trochę odstępu”. Zero, dopóki wyciągnięte dane nie mówią inaczej. Wymuszasz to jako niezmiennik, nie jako nadzieję: deklaracja, która nie ma wartości, po prostu nie zostaje wyemitowana. Generator jest fizycznie niezdolny napisać właściwości, której design nie zdefiniował.

To jest różnica między narzędziem, któremu ufasz na co dzień, a narzędziem, które musisz sprawdzać za każdym razem. Fałszywe 16px, które wygląda dobrze, eroduje zaufanie szybciej niż uczciwa luka, która jest ewidentnie pusta. Ciche zło jest gorsze niż głośna niekompletność.

Jeszcze jedna straż

Jest druga, mała dyscyplina warta nazwania, bo gryzie każdego, kto to buduje. Kiedy czytasz implementację z powrotem, żeby porównać ją z designem, czyli getComputedStyle w przeglądarce, czytasz ją z najgłębszego tekstowego dziecka, nie z kontenera.

Przeczytaj kontener, a dostaniesz wartości dziedziczone i domyślne, których nigdy naprawdę nie ustawiono, i każda z nich staje się fałszywym alarmem. Przeczytaj liść, a dostaniesz to, co element faktycznie renderuje. Mały szczegół. To jest różnica między raportem pełnym szumu a raportem, na którym możesz działać.

Jeden rdzeń, dwa końce

Tu się to wszystko składa, i to jest cały powód, dla którego podejście jest warte więcej niż pojedyncza sztuczka.

Kiedy masz już deterministyczny rdzeń ekstrakcji, dokładne wartości z Figmy, wymuszony RULE ZERO, zero zgadywania gdziekolwiek, ten rdzeń robi dwa zadania, nie jedno.

Możesz nim generować: wyciągnięte wartości stają się prawdziwym skeletonem komponentu, plikiem CSS albo plikiem frameworka, każdą właściwość da się prześledzić z powrotem do designu, nic wymyślonego.

Możesz nim weryfikować: te same wyciągnięte wartości stają się prawdą bazową, względem której sprawdzasz zbudowaną implementację. Czy wdrożony padding zgadza się z tokenem designu, czy ktoś go zmierzył na oko? Zmierzone, nie na oko.

Ta sama ekstrakcja. Ten sam RULE ZERO. Dwa wyjścia. Budujesz tym i sprawdzasz tym, i oba są uczciwe dokładnie z tego samego powodu: nic w pipeline nigdy nie zgadywało.

AI nadal robi tu brudną robotę. Czyta, mapuje, szkicuje. Ale robi brudną robotę na deterministycznych danych, a ostatnie słowo ma inżynier. To nie jest ograniczenie podejścia. To jest podejście.

Następnie: dwa narzędzia, które wychodzą z tego jednego rdzenia, generator i weryfikator, oba publiczne, oba do sklonowania i uruchomienia już dziś.

From the Field to jest to, co realnie buduję, co się psuje i czego się uczę. Realne projekty, realne liczby, realne bugi. Bez tutoriali.