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

Część 3: co to zwraca i dokąd idzie

Część 1 postawiła tezę, żeby nigdy nie pozwolić modelowi zgadywać. Część 2 pokazała dwa publiczne narzędzia, które wychodzą z jednego deterministycznego rdzenia: sdet-figma-kit generuje, qa-pack weryfikuje.

Ta część jest o tym, co ci to kupuje i dokąd to podejście idzie dalej. Będę precyzyjny co do tego, co jest zbudowane, a co nie, bo cała wartość tej metody rozsypuje się w momencie, w którym zaczynam opisywać rzeczy nieshipnięte tak, jakby już chodziły.

Więc tu jest ta linia, od razu. Generator jest realny. Weryfikator jest realny. Zamknięty obieg, który spina je razem z automatycznym krokiem naprawy, nie jest. Ten ostatni kawałek to jest to, jak projektuję system dla klienta. To roadmapa, nie repo.

Pozwól, że zasłużę na to rozróżnienie, zaczynając od części, która już się odpłaca.

ROI to nieobecność całej kategorii roboty

Wróć do probabilistycznego 1% z Części 1. Model zgaduje bezbłędnie w 99% przypadków. W pozostałym 1% produkuje wartość, która jest błędna, a wygląda poprawnie. Zielony podgląd, wiarygodny CSS, liczba rozjechana o cztery piksele.

Drogi w tym 1% nie jest bug. Drogie jest to, że bug jest niewidoczny. Nikt nie poprawia ręcznie wartości, która wygląda na poprawną. Idzie na produkcję. Siedzi w kodzie jako ukryty dług dopóki zmiana layoutu trzy tygodnie później jej nie odpali, i teraz ktoś robi bisect na regresji, która prowadzi z powrotem do 16px, które model wymyślił ze zrzutu ekranu.

To jest najgorszy rodzaj roboty, jaki istnieje. Jest powolna. Jest niewdzięczna. I ląduje na tym, kto stoi najbliżej, zwykle długo po tym, jak osoba, która wkleiła zrzut ekranu, poszła dalej. Koszt nigdy nie pojawia się na zadaniu, które go stworzyło. Pojawia się później, na innym zadaniu, podpięty pod inne nazwisko.

Deterministyczna ekstrakcja usuwa tę kategorię w całości. Nie ma przebiegu ręcznej korekty, bo nie ma wymyślonych wartości do poprawiania. Wartość jest albo wczytana dokładnie z designu, albo nieobecna. Nie ma trzeciego stanu, w którym wiarygodne zgadnięcie chowa się wśród prawdziwych liczb. RULE ZERO trzyma linię:

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 jest prawdziwy zwrot. Nie “szybciej”, choć jest szybciej. Zwrot polega na tym, że kasujesz najpowolniejszą, najbardziej demoralizującą robotę w całym flow: gonienie za cichą błędną wartością, która już przeszła review.

Tu jest ilustracja skalowania i chcę być jasny, że to ilustracja generyczna, nie liczba z żadnego kontraktu z klientem.

Weź batch 100 do 200 zadań design-to-code. Zespół robiący to klasycznie, zrzut ekranu do modelu do ręcznego sprzątania, spędza na tym mniej więcej tydzień. Każde zadanie niesie własny mały podatek na sprzątanie, a ułamek z nich niesie minę ukrytego długu, która wychodzi później.

Deterministyczny pipeline robi ten sam batch w 2 do 3 dni. Ten sam node z Figmy plus te same tokeny dają bajt w bajt identyczny output przy każdym przebiegu, więc nie ma czego niańczyć przy zadaniu. Output jest uczciwy z konstrukcji, więc nie ma podatku na weryfikację przy zadaniu poza samym krokiem weryfikacji, który też jest deterministyczny.

Przyspieszenie jest realne, ale liczy się efekt drugiego rzędu. Przestajesz płacić odsetki od długu, którego nie widzisz.

Jest jeszcze cichszy zwrot, i on się kumuluje. Kiedy output jest deterministyczny, regeneracja jest darmowa. Design się zmienił? Odpal jeszcze raz. Dostajesz ten sam skeleton z nowymi wartościami, bajt w bajt, bez ryzyka, że model postanowił być kreatywny na drugim przebiegu. Workflow probabilistyczny nie może tego obiecać. Odpal prompt na zrzucie ekranu jeszcze raz, a możesz dostać inne zgadnięcie, co znaczy, że każda regeneracja to świeża szansa na katastrofę tego 1%. Determinizm zmienia “odpal jeszcze raz” z hazardu w no-op, któremu możesz ufać.

Pełny obieg, tak jak go projektuję

Teraz roadmapa. To jest część, której nie będę udawał, że jest shipnięta.

Jeden deterministyczny rdzeń. Dwa końce dzisiaj: generate i verify, oba publiczne, oba clone-and-run. Trzeci koniec to ten, który buduję dla klienta: zamknięty obieg, w którym porażki weryfikacji karmią automatyczny krok naprawy, implementacja jest regenerowana względem designu, a obieg chodzi dopóki diff nie jest czysty.

Tu jest obieg, tak jak zaprojektowany. Nie jako chodzący kod w prywatnym repo, bo ten obieg nie istnieje jako shipnięty kod nigdzie. To jest architektura, którą spinam pod kontrakt.

flowchart LR
  A[Deterministyczny rdzeń:<br/>dokładne wartości + RULE ZERO] --> B[Generuj skeleton]
  B --> C[Weryfikuj względem designu]
  C -->|diff czysty| D[Inżynier reviewuje + shippuje]
  C -->|diff brudny| E[Krok naprawy:<br/>regeneruj z designu]
  E --> C

Dwa pudełka, które możesz zbudować dzisiaj, to Generate i Verify. sdet-figma-kit to pudełko generate: parsuj get_design_context albo ściągnij przez REST z FIGMA_TOKEN, zmapuj na swoje design tokens, wyemituj skeleton CSS, Vue albo React. qa-pack to pudełko verify: porównaj zbudowaną implementację względem designu, mierzone, nie na oko, przez 13 kategorii, z getComputedStyle czytanym z najgłębszego elementu tekstowego, żeby odziedziczone domyślne wartości nigdy nie stały się false positive.

Pudełko, które nie istnieje jako shipnięty kod, to Fix. Nie ma silnika auto-fix w żadnym moim repo. Zero kodu łatającego. Strzałka z verify z powrotem w krok regeneracji to decyzja projektowa, którą podejmuję per klient, nie feature, który po cichu chodzi.

Dlaczego uczciwe jest w ogóle ją rysować? Bo trudne części są już udowodnione. Oba końce już dzielą jeden deterministyczny rdzeń i jeden RULE ZERO. Krok naprawy nie jest nowym źródłem prawdy. To ta sama ekstrakcja karmiąca ten sam generator, wyzwalana przez ten sam weryfikator, który już wie dokładnie, które właściwości się rozjechały. Obieg jest niezbudowany i nie zamierzam sugerować inaczej. To, co czyni go problemem integracji, a nie badawczym, to fakt, że dwa końce, które miałby spiąć, są już zbudowane i przetestowane. Sam krok naprawy i orkiestracja domykająca obieg to robota net-new, którą wykonuję pod kontrakt, nie kod, który u mnie chodzi.

A trudna część kroku naprawy to nie regeneracja. Generator już to robi. Trudna część to polityka wokół niego. Które rozjazdy naprawiamy automatycznie, a które eskalujemy do człowieka. Co liczy się jako czysty diff dla zespołu, który używa jednego zestawu tokenów, kontra zespół, który dopuszcza wartości literalne w niektórych miejscach. Gdzie siedzi bramka człowieka i co widzi, kiedy ją otwiera. Nic z tego nie jest kodem, który mogę shipnąć na ślepo. Wszystko to jest rozmową z zespołem, który jest właścicielem pipeline.

To jest dokładnie ten powód, dla którego to należy do komercyjnego kontraktu, a nie do darmowego repo. Publiczne połówki uczą metody. Zamknięty obieg, dostrojony do stacku jednego zespołu, ich tokenów, ich frameworka, ich definicji czystego diffa, to jest ta robota.

AI robi czarną robotę, inżynier decyduje

Powtórka z Części 1, bo to jest kręgosłup całego podejścia i nie zmienia się, kiedy obieg robi się dłuższy.

AI nadal robi czarną robotę. Czyta kontekst designu, mapuje wartości na tokeny, szkicuje skeleton, odpala porównanie, to wszystko shipnięte dzisiaj. W obiegu, który projektuję pod klienta, nieshipniętym, proponowałby też regenerację. To jest dużo harówki zdjętej z człowieka.

Ale każdy krok chodzi na deterministycznych danych, a inżynier ma ostatnie słowo. Weryfikator nie zatwierdza automatycznie. Krok naprawy nie przepisuje po cichu produkcji. Czysty diff to sygnał dla człowieka, nie zielone światło na merge. Model nigdy nie dostaje prawa zdecydować, że wartość jest poprawna. Dostaje tylko prawo działać na wartościach, które zostały wczytane, nigdy zgadnięte.

To jest ta część, która sprawia, że obieg w ogóle jest bezpieczny do rozważenia zamknięcia. Pętla sprzężenia zwrotnego zbudowana na probabilistycznym silniku, który zgaduje, to maszyna do wzmacniania tej katastrofy 1%. Każdy przebieg przez pętlę to kolejna szansa, żeby wymyślić wartość, a pętla chodzi dopóki coś nie wygląda czysto, co znaczy, że ochoczo zbiegnie się do wiarygodnej fikcji i nazwie to gotowym. Pętla zbudowana na deterministycznej ekstrakcji z RULE ZERO nie ma czego wzmacniać, bo nie ma zgadnięcia nigdzie na ścieżce danych. Inżynier ocenia uczciwy output, nie wiarygodną fikcję.

Dlatego nie sprzedam pętli na wierzchu pipeline na zrzutach ekranu. To nie jest mniejsza wersja tej samej rzeczy. To jest rzecz przeciwna. Automatyzowanie procesu, który zgaduje, nie oszczędza czasu, skaluje koszt zgadnięć i zakopuje je głębiej. Jedyna pętla warta zamknięcia to taka, w której każda wartość w ruchu została wczytana, nie wyobrażona.

To nie jest ograniczenie, za które przepraszam. To jest powód, dla którego całość działa.

Metoda jest publiczna. System jest ofertą.

Tu jest komercyjne ujęcie, wprost.

Dwie publiczne połówki to metoda i są edukacją. sdet-figma-kit i qa-pack są oba realne, oba przetestowane, oba otwarte. Sklonuj je i odpal dzisiaj. Generuj jednym, weryfikuj drugim. Zobaczysz dyscyplinę przy pracy na swoich własnych designach, w swoim własnym stacku, beze mnie w pokoju. To jest celowe. Metoda powinna stać o własnych nogach.

To, co sprzedaję, to system, który ta metoda umożliwia. Pełny obieg generate-verify-fix, wpięty w realny pipeline, dostrojony do twoich tokenów i twojego frameworka, z krokiem naprawy zbudowanym i bramką review człowieka postawioną tam, gdzie twój zespół faktycznie jej chce. To jest część, która nie przychodzi w repo, bo ma sens tylko zbudowana wokół realiów jednego zespołu.

Jeśli chcesz publiczne połówki, są publiczne, link w pierwszym komentarzu. Bierz je.

Jeśli chcesz zamknięty obieg na produkcji, to jest robota, którą robię. Pogadajmy.

sdet.it/services

Domknięcie serii

Trzy części, jeden pomysł.

Warstwa danych to miejsce, gdzie design-to-code się psuje, więc lekarstwem jest nigdy nie pozwolić modelowi zgadywać. Wczytaj dokładne wartości z designu, egzekwuj RULE ZERO, a właściwość, której design nigdy nie określił, nigdy nie może pojawić się w output. Ten jeden rdzeń robi dwie roboty, generate i verify, i obie są uczciwe z tego samego powodu: nic w pipeline nigdy nie zgadywało.

Wszystko, o czym twierdziłem, że jest zbudowane, siedzi w dwóch publicznych repo, które możesz odpalić sam. Wszystko, co opisałem jako obieg, to roadmapa, którą nazwałem roadmapą. To rozróżnienie to cały sens tej serii. Narzędzie, któremu możesz ufać, to takie, które mówi ci, co wie, i milczy o tym, czego nie wie, a ten sam standard stosuje się do osoby opisującej narzędzie.

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