Zespoły programistyczne spędziły dziesięciolecia, budując determinizm w swoich łańcuchach narzędzi. Pliki lock dla menadżerów pakietów. Przypięte obrazy bazowe dla kontenerów. Odtwarzalne buildy dla skompilowanych artefaktów. Zasada jest dobrze znana: te same dane wejściowe powinny zawsze dawać te same wyniki — na każdej maszynie, w każdym czasie.

Przekazywanie projektu nigdy nie stosowało tej zasady. Był to z definicji proces ludzki, a więc niedeterministyczny. Projektant tłumaczy projekt deweloperowi. Deweloper interpretuje go. Interpretacja różni się w zależności od osoby, dnia, jasności komentarza w Zeplinie. Nie można tego odtworzyć. Nie można przetestować. Nie można porównać wersji.

W świecie agentów kodowania AI niedeterministyczne przekazywanie projektu stało się problemem inżynierskim pierwszej klasy. figmascope rozwiązuje go zamrożonym, przenośnym pakietem kontekstowym.

Dlaczego obecne narzędzia są niedeterministyczne dla agentów

Zeplin i Avocode dają liczby wyekstrahowane z Figmy — wymiary warstw, wartości kolorów, rozmiary czcionek. Ale serwują je jako przeglądalne UI, a nie maszynowo czytelny artefakt. Agent wskazany na Zeplina musi nawigować po UI, by znaleźć wartości — co jest kruche, ograniczone rate limitami i zależne od tego, jak napisano adnotacje.

Figma Dev Mode idzie dalej: daje fragmenty kodu generowane inline z projektu. Ale te fragmenty są bezstanowe — generowane na żądanie, nie wersjonowane. Nie ma pakietu, który można zacommitować. Nie ma pliku do diffowania. Jeśli projektant zaktualizuje projekt, widok Dev Mode zmienia się po cichu. Nie wiadomo, kiedy projekt zmienił się względem ostatniego eksportu.

Zrzuty ekranu to najgorszy przypadek: czyste dane pikselowe, w pełni niedeterministyczne do parsowania, za każdym razem dające inną inferencję struktury.

Połączenia MCP na żywo — narzędzia dające agentom dostęp do API Figmy w czasie rzeczywistym — są z definicji niedeterministyczne. Plik zmienia się, gdy agent go czyta. Przebieg agenta o 9:00 i o 14:00 widzą różne dane wejściowe. Nie możesz odtworzyć przebiegu z 9:00, bo źródło się zmieniło.

Agenty to systemy probabilistyczne. Dawanie im niedeterministycznych danych wejściowych nie tylko wytwarza wariancję — sprawia, że system jest niemożliwy do przetestowania. Nie wiadomo, czy zły wynik był spowodowany modelem, promptem, czy tym, że ktoś przesunął warstwę między przebiegami.

Pakiet jako jednostka kompilacji

Właściwym modelem mentalnym eksportu figmascope jest artefakt kompilacji. Podobnie jak kompilator bierze kod źródłowy i produkuje deterministyczny plik binarny — to samo źródło, te same flagi, ten sam plik binarny — figmascope bierze stan pliku Figma i produkuje deterministyczny pakiet: ten sam stan pliku, ten sam pakiet, za każdym razem.

Pakiet to zamrożona migawka. Przechwytuje konkretną wersję projektu i serializuje każdą istotną właściwość: układ przestrzenny, tożsamość komponentu, powiązania tokenów, zawartość ciągów, hierarchię. Po wyeksportowaniu pakiet jest niezmienny. Plik Figma może się zmieniać; pakiet nie. Aby uwzględnić te zmiany, eksportujesz ponownie i otrzymujesz nowy pakiet.

To model jednostki kompilacji. Plik projektu to źródło. Pakiet to artefakt. Agenty konsumują artefakty, nie źródła.

Cztery właściwości deterministycznego przekazywania

Możliwy do migawkowania. Artefakt przekazania musi reprezentować konkretny punkt w czasie. Nie "bieżący stan pliku Figma" — nazwany, wersjonowany eksport. Pakiety figmascope zawierają _meta.json ze znacznikiem czasu eksportu i odciskiem palca tego, co zostało uwzględnione. Pakiet to migawka, nie widok na żywo.

Przenośny. Artefakt musi być samowystarczalny. Bez zależności od zewnętrznych serwisów, live API czy zalogowanych sesji. Pakiet figmascope to ZIP zwykłych plików — JSON, Markdown, PNG. Można go kopiować, wysyłać mailem, commitować do gita, dołączać do PR, przekazywać juniornemu deweloperowi lub agentowi kodowania bez konfiguracji.

Inspektowalny. Deterministyczny artefakt jest bezużyteczny, jeśli nie można zweryfikować jego zawartości. Każdy plik w pakiecie jest czytelny dla człowieka. CONTEXT.md to Markdown. tokens.json to struktura zbliżona do W3C. Per-screenowe IR to JSON z czytelnymi nazwami pól. Inżynier może otworzyć pakiet i dokładnie sprawdzić, co powiedziano agentowi. To jakościowo różne od "wkleiłem zrzut ekranu i dostałem jakiś kod".

Odtwarzalny. Dla tego samego stanu pliku Figma dwa oddzielne eksporty powinny dawać funkcjonalnie równoważne pakiety. Nie identyczne bajt po bajcie (znaczniki czasu się różnią), ale semantycznie identyczne: te same struktury węzłów, te same wartości tokenów, ten sam inwentarz komponentów. Jeśli eksportujesz dwa razy z niezmienionego pliku i pakiety różnią się semantycznie, coś jest nie tak. Ta właściwość pozwala walidować pipeline eksportu i łapać regresje w samym ekstraktorze.

Jak to wygląda w praktyce

Projektant kończy ekrany sprintu. Eksportuje pakiet. Pakiet jest commitowany do repozytorium przy tickecie — lub dołączany do problemu Jira, lub wrzucany na wspólny dysk, zależnie od workflow. W tym momencie artefakt przekazania jest ustalony. Agent (lub deweloper) pracuje na pakiecie, nie na żywym pliku Figma.

W połowie implementacji projektant aktualizuje trzy ekrany. Żaden problem: roboczy pakiet dewelopera pozostaje niezmieniony. Nowe ekrany dostają nowy eksport. Teraz masz dwa pakiety i możesz je diffować: co zmieniło się między projektem, od którego deweloper zaczął, a aktualnym projektem. To właśnie taki wgląd w zmiany, który jest niemożliwy przy workflow opartych na zrzutach ekranu lub połączeniach na żywo.

W workflow z wieloma agentami — jeden agent buduje bibliotekę komponentów, drugi buduje układy ekranów, trzeci pisze testy — każdy agent dostaje ten sam pakiet jako źródło prawdy. Wszyscy pracują z tego samego zamrożonego stanu projektu. Ich wyniki są kompozytowalne, bo ich dane wejściowe są wspólne i ustalone. To warunek wstępny dla wieloagentowego generowania UI, które jest naprawdę niezawodne.

Diffowanie pakietów

Ponieważ pakiet to zwykłe pliki, diffuje się jak kod. Dwa eksporty tego samego pliku dla dwóch wersji Figmy dają JSON diff, który mówi dokładnie, co się zmieniło:

To wgląd w zmiany projektowe, który nie istnieje w żadnym obecnym narzędziu do przekazywania. Figma ma własną historię wersji, ale jest ona wizualna i skierowana do projektantów. Diff pakietu jest ustrukturyzowany i skierowany do deweloperów: maszynowo czytelne dane o zmianach, które mogą napędzać automatyczne testy, aktualizować changelogi lub wyzwalać workflow CI.

CI/CD dla przekazywania projektu

Gdy przekazywanie jest deterministyczne, CI/CD następuje naturalnie. Możesz pisać testy uruchamiane na pakiecie: "ten ekran musi zawierać komponent Button/Primary", "ten token musi być powiązany, a nie zahardkodowaną wartością", "ten ciąg musi mieć klucz stringRef". To statyczne sprawdzenia analizy na danych strukturalnych. Uruchamiają się w milisekundy. Uruchamiają się w pipeline'ie.

Możesz też walidować wynik agenta codegen w stosunku do pakietu, który dostał. Czy agent użył tokenów czy zahardkodował literały? Czy wygenerował właściwą liczbę instancji powtarzanego komponentu? Czy użył poprawnych wartości odstępów? Na te pytania można odpowiedzieć, gdy źródłem prawdy jest plik strukturalny, a nie PNG.

Porównanie z MCP

Połączenia na żywo w stylu MCP z Figmą zyskują na popularności. Urok jest oczywisty: agent zawsze widzi najnowszy projekt, bez kroku eksportu, bez ręcznego zarządzania pakietami. Ale połączenia na żywo handlują determinizmem za wygodę — a dla agentów AI ta transakcja jest zła.

Połączenia na żywo oznaczają: kontekst agenta zależy od tego, kiedy uruchamia. Przebieg o 9:00 i o 14:00 widzą różne dane, jeśli projektant pracował w ciągu dnia. Nie możesz odtworzyć wcześniejszego przebiegu. Nie możesz testować na stałym wejściu. Nie możesz sprawdzić, co powiedziano agentowi. Jeśli wygenerowany kod jest błędny, nie możesz odróżnić "model zrobił złą inferencję" od "projekt zmienił się pod agentem".

Właściwy model to: połączenia na żywo do eksploracji i iteracji projektu (gdzie liczy się aktualność), deterministyczne pakiety do przekazywania i generowania (gdzie liczy się odtwarzalność). Nie konkurują ze sobą — działają w różnych punktach workflow.

Przekazywanie juniornemu deweloperowi

Te same właściwości, które czynią pakiety dobrymi dla agentów AI, czynią je dobrymi dla ludzkich deweloperów, którzy dopiero poznają codebase. Junior deweloper z pakietem ma: kompletną specyfikację w CONTEXT.md, wszystkie wartości tokenów w tokens.json, każdy komponent wymieniony z właściwościami, każdy ciąg z tożsamością. Nie musi być w pliku Figma. Nie potrzebuje konta Figma. Nie musi wiedzieć, który ekran jest autorytatywny.

Pakiet to kompletne, samowystarczalne zlecenie pracy. Takie samo, jakie dostaje agent. Jedyna różnica polega na tym, że człowiek je czyta, a agent przetwarza programowo — ale artefakt jest identyczny.

Ta unifikacja — ten sam artefakt, konsument ludzki lub agentowy — to sedno. Pakiet jest jednostką przekazywania. Wszystko inne to szczegół implementacji.

Zobacz deterministyczne przekazywanie w praktyce z Claude Code, Cursor lub Aider. Wszystkie startują z tego samego eksportu figmascope.