Figma MCP to Storybook in Minutes: Webinar Notes with Banks & Petrie #EN348

TL;DR

Figma MCP jest tylko do odczytu i przekazuje kontekst z plików Figmy do narzędzi AI oraz IDE
Włączenie Enable Desktop MCP Server w trybie Dev Mode umożliwia szybką pracę lokalną
Ścieżka Figma → Storybook trwa minuty: link/zaznaczenie → kontekst → TSX/CSS Modules + plik .stories
Spójne nazewnictwo, tokeny i struktura katalogów zwiększają trafność generacji
Zasada „od najmniejszego do złożonego” ogranicza błędy w złożonych komponentach
Pole Description w Figmie niesie intencje i pomaga AI odtworzyć zachowania w kodzie
Na 10 prób z AI, 1 da przełomowy rezultat – to normalne i produktywne

Wprowadzenie

Poniższe notatki powstały na podstawie webinaru prowadzonego przez Joey’a Banksa (niezależny ekspert od Figmy, były pracownik firmy) oraz TJ Petrie (założyciel i CEO agencji South Left specjalizującej się w systemach projektowych). Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą od prowadzących. Spotkanie zgromadził niemal 300 uczestników zainteresowanych praktycznym wykorzystaniem Model Context Protocol w codziennej pracy z design systems.

Banks reprezentował perspektywę designera, który czuje się przytłoczony tempem zmian w AI. Szczerze przyznał na początku: „Jestem dość zastraszony tym wszystkim. Jestem kimś, kto uwielbia tworzyć rzeczy w Figmie i pisać kod. Czasami jestem bardzo niechętny, żeby oddać tę kontrolę”. To uczucie rezonowało z setkami uczestników – wielu designerów czuje podobny opór przed oddaniem kontroli AI, jednocześnie będąc ciekawymi możliwości.

Petrie natomiast pokazał perspektywę inżyniera, który codziennie przez dwie godziny testuje nowe narzędzia. Głównym celem spotkania było praktyczne zademonstrowanie, że przejście od komponentu w Figmie do działającego kodu React zajmuje dosłownie kilka minut, a bariera wejścia jest znacznie niższa niż większość designerów zakłada.

Czym jest Model Context Protocol?

Według Petrie, MCP to w praktyce API dla sztucznej inteligencji. Jak wyjaśnia: „Model Context Protocol to w zasadzie jak API dla AI. MCP to wrapery API lub rozszerzenia istniejących API, napisane specjalnie w celu komunikacji z AI”.

MCP udostępnia modelowi funkcje do odczytu danych projektowych. W Figmie działa jak „API dla AI”: przekazuje warianty, właściwości, typografię, tokeny oraz zrzuty ekranu. Co ważne, konektor Figmy jest tylko do odczytu, dlatego plik projektowy pozostaje stabilnym punktem odniesienia. Dzięki temu łatwiej utrzymać porządek i uniknąć konfliktów edycyjnych.

Ewolucja narzędzi – od Copilot do MCP

Petrie opisał ewolucję, która doprowadziła do powstania MCP. W wczesnych dniach GitHub Copilot oferował podstawową autouzupełnianie i naprawę błędów – programiści widzieli czerwoną kreskę pod kodem i wybierali „napraw z Copilotem”. To był początek, który pokazywał potencjał większych zmian.

Następnie przyszła era ChatGPT, gdzie programiści kopiowali kod, pytali o CSS, szukali referencji. Pojawiło się również rozpoznawanie obrazów, które pozwalało przesyłać zrzuty ekranu do podstawowej analizy. Kolejnym krokiem było wprowadzenie agentów AI – systemów, które mogły wykonywać akcje w odpowiedzi na komendy użytkownika.

Jednak prawdziwy przełom nadszedł z MCP. Petrie podkreśla moment zrozumienia: „Kiedy Claude ogłosił MCP, pomyśleliśmy: to wydaje się duże. Czuliśmy nagle, że mamy moc API z AI.” Model Context Protocol zapewnia bezpośredni dostęp do struktury plików, komponentów i kontekstu projektu.

Istotne jest również ograniczenie – MCP działa tylko w trybie odczytu i nie może modyfikować plików w Figmie. Petrie uznaje to za dobrą praktykę: „Wolałbym, żeby inżynierowie nie mieli żadnej kontroli nad moimi rzeczami w Figmie”. To ważne zabezpieczenie oznacza, że designerzy zachowują pełną kontrolę nad źródłowymi plikami.

Konfiguracja środowiska – setup w trzech krokach

Krok 1: Figma (Dev Mode)

W preferencjach Dev Mode należy włączyć opcję „Enable Desktop MCP server”. W Dev Mode można potwierdzić status – MCP Server powinien pokazywać „Enabled”. Wymaganie: Dev Mode dostępny we wszystkich płatnych pakietach Figmy.

Z kolei wybór trybu ma znaczenie dla tempa pracy:

Tryb Remote: Najszybszy w konfiguracji, działa na linkach kanonicznych do ramek/komponentów. Wymaga kanonicznego linku do każdego komponentu, komunikuje się przez Figma cloud i jest wolniejszy ze względu na „okrężną drogę”, ale łatwiejszy w konfiguracji. W trybie Remote używaj „Copy link to selection”.

Tryb Desktop: Łączy się lokalnie z Figma Desktop, rozpoznaje zaznaczony komponent i zwykle jest szybszy. Petrie wyjaśnia: „Kiedy używam wersji desktopowej, komunikuje się ona bezpośrednio z moim desktopem Figmy. Nie muszę wysyłać linku – mogę po prostu mieć zaznaczoną ramkę lub komponent, a system wie, z którym komponentem się komunikuję”.

Nowe wersje Figmy oferują również Command Setup, który automatycznie konfiguruje połączenie z wybranymi edytorami. Petrie z zaskoczeniem odkrył podczas webinaru: „To jest dla mnie nowe. Wcześniej tego nie widziałem, więc to również połączy się z Cursor, co jest świetne”.

Krok 2: Claude Desktop

Petrie pokazał, że instalacja wymaga zaledwie kilku kliknięć. Proces jest prosty: należy otworzyć sekcję „Manage Connectors” (lub Settings → Tools), kliknąć „Browse Connectors” i znaleźć Figma w liście alfabetycznej, następnie zaznaczyć checkbox – instalacja następuje automatycznie.

Po zainstalowaniu dostępnych jest pięć głównych funkcji:

Get Figma file
Get FigJam
Get Code Connect map
Get design system rules
Get screenshot

Petrie zwrócił uwagę na możliwość optymalizacji: „Jeśli nie pracujesz z FigJam lub Code Connect, możesz wyłączyć te funkcje, co zaoszczędzi kilka tokenów i przyspieszy działanie”.

Wymaganie: Płatna subskrypcja Claude. Uczestnicy w chacie zauważyli: „Używanie Figma wewnątrz Claude to funkcja płatna” – darmowa wersja ma ograniczone limity tokenów.

Krok 3: Cursor lub VS Code

W Cursor instalacja wymaga nieco więcej kroków technicznych, jednak Petrie zaleca skorzystanie z oficjalnej dokumentacji Figma, która zawiera bezpośrednie linki automatycznie konfigurujące MCP w wybranym edytorze. Jak wyjaśnia: „Ten link połączy się bezpośrednio z twoją lokalną instancją Cursor. Więc naprawdę nie musisz przechodzić przez wszystko, co właśnie pokazałem w ustawieniach”.

Banks podkreślił dla uczestników, że Cursor może być lepszą ścieżką dla osób rozpoczynających naukę ze względu na bardziej przystępny punkt wejścia cenowy. Cursor oferuje darmową wersję z limitami tokenów, co jest wystarczające na początek.

Dla projektantów: Pomocny bywa widok Agenta w Cursorze, który upraszcza sterowanie procesem. Petrie pokazał: „Jest ten inny widok zwany widokiem agenta, gdzie możesz trochę przeorganizować rzeczy i robić rzeczy głównie z tego okna, a twoja strona kodu jest po prostu trochę poboczną myślą”. Interfejs przypomina ChatGPT, gdzie kod generuje się w tle.

Od Figmy do kodu – praktyczny workflow Figma → Storybook

Petrie zademonstrował pełny proces na przykładzie komponentu „chip” z biblioteki Context Based Design Systems (CBDS) – systemu, który rozwinął jako część innego warsztatu, opartego na filozofii „kaskady kontekstu”.

Analiza komponentu

Pierwszym krokiem jest skopiowanie linku do komponentu przez „Copy link to selection” i wklejenie go w Claude Desktop z prostym promptem: „Opowiedz mi o tym komponencie”.

Banks zauważył moment techniczny: „Miałem dzisiaj problemy z Claude Desktop” – czasami trzeba zrestartować aplikację lub wyłączyć i włączyć konektor. Petrie dodał z humorem: „Czasami trzeba po prostu dmuchnąć w kartridż Nintendo, potrząsnąć kilka razy, postukać z boku”. To uczciwe pokazanie, że technologia nie zawsze działa perfekcyjnie za pierwszym razem.

Po ponownej próbie MCP automatycznie zwraca imponującą ilość informacji:

Nazwę komponentu („chip”) i lokalizację w bibliotece (CBDS UI Kit)
Liczbę wariantów (w tym przypadku 64)
Właściwości i ich wartości
Zrzut ekranu komponentu
Tokeny i zmienne CSS
Szczegóły typografii

Petrie wyjaśnił proces: „To get design context – jeśli chcesz zobaczyć jak robi się kiełbasę, możesz to otworzyć i zobaczyć dokładnie co robi. Ponieważ kiedy rozbierzesz Figmę, to naprawdę jest tylko kod, więc przegląda wszystkie różne elementy”.

Banks zwrócił uwagę na praktyczną wartość: „Nawet jako osoba, która pisała dokumentację design systemu setki razy, możliwość powiedzenia 'hej, opowiedz mi o tym komponencie’ to doskonały start do każdego wysokopoziomowego przeglądu”.

Przygotowanie środowiska Storybook

Petrie wykorzystuje Storybook jako środowisko deweloperskie. Wyjaśnia: „Storybook to szeroko akceptowane narzędzie oraz przeglądarka komponentów i środowisko testowe. Pozwala nam szybko rozwijać i testować wszystkie nasze komponenty w wielu frameworkach”. South Left pracuje w Angular, React, web components i Vue – Storybook wspiera wszystkie te technologie.

Uruchomienie to jedno polecenie w konsoli: npm run storybook. System automatycznie pokazuje wersję Storybook, framework (React), system budowania (Vite) oraz lokalny port (localhost:6006).

Praktyczny tip: Lokalne uruchomienie Storybooka pozwala testować przez sieć domową – na przykład na telefonie. Banks zauważył: „Gdy uruchamiamy rzeczy lokalnie, możemy uzyskać do nich dostęp na całej naszej sieci. Jeśli jesteś w domu i jesteś na swoim wifi, jeśli uruchomisz coś na swoim komputerze, absolutnie możesz uzyskać do tego dostęp na swoim telefonie”.

Petrie pokazał również ważną cechę: „Ta mała sekcja komponentów odzwierciedla tę sekcję. Więc to są moje komponenty tutaj. To mój badge, to mój button, to moja ikona”. Struktura w IDE przekłada się bezpośrednio na nawigację w Storybooku, co ułatwia orientację w projekcie.

Anatomia skutecznego prompta

Petrie nie rzuca przypadkowych poleceń – jego prompt jest przemyślany i zawiera kluczowe instrukcje:

„Podążaj za metodami kodowania i wzorcami używanymi w tym katalogu: /src/components. To są obecne komponenty, które mam w tym katalogu z komponentami TypeScript, modułami CSS i historiami Storybook. Gdzie umieścić komponent i nazwa komponentu (która pochodziłaby z linku). Użyj tej samej konwencji nazewnictwa dla folderu”.

Ale najbardziej kluczowa jest ta instrukcja: „Jeśli ten komponent zawiera podkomponenty lub zagnieżdżone komponenty, sprawdź czy istnieją jakieś już istniejące i wykorzystaj te komponenty przed tworzeniem niestandardowego elementu lub nowego komponentu”.

Petrie podkreślił filozofię: „Zawsze staramy się pracować od komponentu najmniej zależnego do najbardziej zależnego – zaczynając od najmniejszych, najbardziej atomowych elementów”.

Generacja plików

Po wysłaniu prompta AI wykonuje sekwencję działań widoczną w konsoli: get_design_context, get_design_system_rules, get_screenshot, get_file_data, get_component.

W IDE równolegle powstaje:

Plik TSX z propsami i logiką
Arkusz CSS Modules zgodny z konwencją zespołu
Plik .stories do Storybooka

Petrie z satysfakcją pokazał rezultat: „To wszystko używa naszych zdefiniowanych tokenów, naszego stylu dodawania komentarzy, naszej metody BEM z przestrzenią nazw do pisania CSS. Więc to wszystko jest dokładnie zgodne ze specyfikacją tego, jak South Left tworzy systemy projektowe”.

Rezultat w Storybook – moment Boba Rossa

Komponent pojawił się w Storybooku w pełni funkcjonalny. Odwzorowano warianty i ikony, a style oparte na tokenach utrzymały spójność z systemem. W rezultacie podgląd w Storybooku pozwolił szybko zweryfikować stany i warianty.

Petrie przegląda rezultat: „Mamy całkiem standardowy tutaj, neutralny. Mamy te style. Mamy wersję outline”. AI nawet poszło o krok dalej: „Dostałem zaokrąglone wersje tutaj, co jest całkiem fajne”.

Tu Petrie podzielił się obserwacją o różnicach między modelami AI: „Czasami Sonnet – w zależności od wersji AI, którą używasz, czasami może trochę przesadzić. Używam Sonnet 4.5. Idzie bardzo mocno. Więc da mi dużo rzeczy, których niekoniecznie potrzebuję”.

W tym przypadku przyciski zamykania nie były jeszcze w pełni interaktywne, niektóre warianty wyglądały nieco inaczej niż powinny. I tu wprowadził Zasadę Boba Rossa: „Kiedykolwiek jesteś w tych momentach, po prostu wczuj się w Boba Rossa. Bo czasami te błędy się zdarzają. Ale dla naszego pierwszego strzału, jednego prompta, to jest całkiem dobre. Bądź z tym okej. Rób iteracje i w końcu dostaniesz to tam gdzie być powinno”.

Jako punkt wyjścia, stworzony w jednym prompcie w kilka minut – to imponujący rezultat.

Zasady, które robią różnicę

Petrie i Banks podkreślili kilka fundamentalnych zasad, które znacząco wpływają na jakość generowanego kodu:

1. Jednoznaczne nazewnictwo i przewidywalna struktura

Petrie zdradził: „Mamy arkusz kalkulacyjny, który przechowujemy, który ma hierarchię i nazwy, które powszechnie używamy. Kiedy ludzie dochodzą do nazw rzeczy jak wskaźniki statusu i odznaki, gdy dochodzi do rozwijanych list i jest dużo różnej terminologii, my jako organizacja stworzyliśmy naszą definitywną listę jak je nazywamy”.

Dlaczego to kluczowe? „Cokolwiek nazwiesz po stronie Figmy, skończy będąc nazwane po stronie kodu chyba że chcesz ręcznie to dostosować. Ale nie sugerowałbym tego, ponieważ wtedy kończysz z rozwidleniem, ponieważ parytet kodu nie jest tak ciasno związany”.

2. Od najmniejszego do złożonego

„Zawsze staramy się pracować od komponentu najmniej zależnego do najbardziej zależnego. Oznacza to, że normalnie spróbujemy używać rzeczy i budować od bardzo małego – jeśli używamy metodologii atomic development, powiemy od najmniejszych, najbardziej atomowych elementów”.

Przykład z webinaru: avatar indicator – tylko 39 linii kodu, zero zagnieżdżonych komponentów, idealne do rozpoczęcia. Potem przyciski, ikony, odznaki, wskaźniki ładowania, separatory – wszystko bez zależności.

3. Reużycie ponad duplikację

Kluczowa instrukcja w promptcie: „Jeśli ten komponent zawiera podkomponenty lub zagnieżdżone komponenty, sprawdź czy są jakieś istniejące i wykorzystaj te komponenty przed stworzeniem niestandardowego elementu lub nowego komponentu”.

Ta jedna instrukcja sprawia, że AI najpierw skanuje istniejące komponenty zamiast tworzyć wszystko od nowa.

4. Tokeny i zmienne zamiast wartości stałych

Dzięki temu CSS jest wierniejszy projektowi i łatwiej utrzymać spójność systemu. Petrie pokazał, że wygenerowany kod „używa naszych zdefiniowanych tokenów” zamiast hard-coded values.

✅ Checklisty operacyjne

A) Pre-flight komponentu w Figmie

Przed użyciem MCP sprawdź:

Spójne nazwy wariantów i właściwości
Brak odłączonych instancji (detached components)
Brak wartości ustawionych „na sztywno” (hard-coded values)
Poprawne użycie tokenów i zmiennych
Uzupełnione pole Description z oczekiwanymi zachowaniami
Link kanoniczny przygotowany (gdy pracujesz w trybie Remote)
Uruchom Figmalint – sprawdź „zdrowie” komponentu przed generacją

Figmalint jako pre-flight tool: Petrie wyjaśnił: „Mamy to narzędzie, którego używamy zawsze gdy potwierdzamy, że coś działa jak powinno. Nazywa się Figmalint”. To plugin w Figma Plugin Store, który „pozwala sprawdzić na stałe wpisane wartości i zasadniczo zdrowie twojego komponentu”. Dodał ważną informację: „To wkrótce będzie częścią Figma Core”. Zalecił uruchomienie lintera przed użyciem MCP – „tylko żeby upewnić się, że to co dostajesz będzie komponentem najwyższej jakości”.

B) Generacja i kontrola jakości

Podczas i po generacji:

Polecenie wymusza ponowne użycie subkomponentów oraz konwencji katalogów
Wygenerowane pliki: TSX, CSS Modules, .stories
Storybook uruchomiony na localhost:6006
Sprawdzone warianty i stany komponentu
Zweryfikowane odstępy, typografia, ikony
Sprawdzony fokus i obsługa klawiatury
Przetestowane zachowania interakcji
Drobne różnice poprawione ręcznie lub poprzez doprecyzowanie polecenia
Accessibility: kontrast, etykiety ARIA, nawigacja klawiaturą

Kontrola jakości: trzy kroki bez skrótów

Gdy Pedro zapytał „Gdzie idziesz to naprawić? Wracasz do Figmy?”, Petrie odpowiedział: „To naprawdę świetne pytanie”. I rozwinął pełen, trójstopniowy system weryfikacji.

Krok 1: Pre-flight w Figmie

„Jeśli jest zepsute, jeśli coś jest całkowicie źle, to jest wskazówka, że coś prawdopodobnie jest źle po stronie Figmy”. Pierwsza kontrola koncentruje się na pliku projektowym.

Oceń „zdrowie” komponentu:

Czy są odłączone komponenty (detached components)?
Czy występują na stałe wpisane wartości (hard-coded values)?
Dlaczego te elementy się tak pokazują?

Użyj Figmalint przed generacją: Wkrótce narzędzie będzie wbudowane bezpośrednio w Figmę jako część Figma Core.

Krok 2: Ocena wyniku AI

„Jeśli nadal znajdujesz jakieś problemy, to może być wskaźnikiem, że AI po prostu trochę halucynowało na niektórych częściach”. Trzeba ocenić skalę problemu i wybrać odpowiednią strategię.

Sprawdź warianty, typografię, odstępy oraz ikony. Jeśli rozbieżności są większe, doprecyzuj polecenie i wygeneruj pliki ponownie.

Drobne błędy (padding, spacing, kolory): Petrie pokazał podejście – „Możesz zrobić zrzut ekranu. Czasami doda dodatkowy padding i nie jesteś całkiem pewien dlaczego. Możesz zrobić zrzut ekranu tego i powiedzieć 'dlaczego ten padding jest źle?’ I wtedy pójdzie to rozgryźć i powie 'hej, token był źle wyrównany. Użyłem wartości XL a powinienem był użyć wartości L'”.

Średnie odstępstwa: „Jeśli AI naprawdę zboczył, wtedy możesz po prostu chcieć to uruchomić ponownie lub poprosić żeby naprawił rzecz, którą zrobił, którą zepsuł”.

Poważne halucynacje (całkowicie zły stack): „Czasami zacznie działać chaotycznie i zrobi coś zupełnie innego. Skąd SCSS się wzięło? Jak nie używaliśmy tego w tej bazie kodu a nagle pomyślał, że używamy. To bardzo rzadkie gdy się zdarza”.

Krok 3: Ręczne poprawki i dostępność

Skoryguj drobiazgi w CSS/props. Petrie wyjaśnił: „Jeśli jesteś bardziej zaznajomiony z kodem i to nie jest takie duże – to jest jak jeden lub dwa, może kontrast, może tekst powinien tutaj zmienić się na biały albo coś, wtedy ręcznie wszedłbym do kodu i wtedy to jest miejsce gdzie ludzka część inżynierii kontekstu się dzieje”.

Zweryfikuj fokus, obsługę klawiatury i zachowania interakcji. Dzięki temu utrzymasz produkcyjną jakość.

Petrie dodał ważne przypomnienie: „Jest dostępność. Jest cały inny krok dla testowania i dostępności, który też się dzieje”. Sprawdzenie kontrastu, etykiet ARIA, nawigacji klawiaturą, responsywnego zachowania, przypadków brzegowych – to wszystko wymaga ludzkiej uwagi.

Petrie podsumował całościowo: „Nie trzeba mówić, że zaangażowanie człowieka musi się dziać na każdym kroku, szczególnie gdy dochodzi do tych bardziej złożonych komponentów”.

Lista poleceń do AI i kiedy ich używać

1. „Tell me about this component: <link>”

Kiedy użyć: Na starcie, aby pobrać pełny kontekst (warianty, właściwości, typografię, tokeny, zrzut ekranu). W trybie Remote wklej link kanoniczny; w trybie Desktop wystarczy zaznaczenie w Figmie.

Efekt: MCP zwraca nazwę, lokalizację, liczbę wariantów, properties, screenshot, tokeny CSS, szczegóły typografii.

2. „Can you use the Figma MCP to tell me about this component?”

Kiedy użyć: Gdy konektor sprawia problemy po restarcie; wyraźnie wskazuje użycie MCP.

Efekt: Kontekst projektu i zrzut ekranu. Czasami pomaga „dmuchnięcie w kartridż Nintendo” – restart aplikacji.

3. „Follow the coding methods and patterns used in this directory: /src/components (TypeScript components, CSS Modules, Storybook story)”

Kiedy użyć: Podczas generowania kodu; wymusza trzymanie konwencji istniejącej bazy.

Efekt: AI respektuje istniejące wzorce, styl komentarzy, metodę BEM, strukturę plików.

4. „Use the same naming convention for the folder and files as sibling components”

Kiedy użyć: Przy każdym nowym komponencie; zapewnia spójne nazewnictwo.

Efekt: Unika rozwidlenia (bifurcation) między Figmą a kodem.

5. „If this component contains subcomponents or nested components, check for existing ones and reuse them before creating anything new”

Kiedy użyć: Gdy komponent ma części składowe; wymusza reużycie.

Efekt: AI skanuje istniejące komponenty i importuje je zamiast tworzyć duplikaty.

6. „Place the generated files in the same components directory”

Kiedy użyć: W każdym przebiegu; ułatwia importy i wykrycie przez Storybook.

Efekt: Struktura katalogów w IDE odzwierciedla się w nawigacji Storybooka.

7. „Why is this padding off?”

Kiedy użyć: Przy drobnych rozbieżnościach; dołącz zrzut problemu, aby AI wskazało np. błędny token.

Efekt: AI analizuje i wskazuje konkretny problem (np. „użyłem XL zamiast L”).

8. „Wygeneruj dokumentację komponentu na podstawie kontekstu MCP (markdown)”

Kiedy użyć: Po generacji; szybki szkic dokumentacji trzymanej blisko kodu.

Efekt: Plik markdown z properties, wariantami, tokenami, visual design – baseline documentation.

Role i współpraca

Banks zadał pytanie, które nurtuje wielu: „Jestem designerem patrzącym na to – to super fajne, ale nie umiem kodować. Nie mam stopnia z informatyki. Ledwo wiem, może dopiero uczę się czym jest Storybook. Które części muszę znać?”

Co projektant musi wiedzieć?

Petrie uspokoił: „Nie musisz być deweloperem React żeby to robić, ale posiadanie świadomości i bycie komfortowym w takim środowisku bardzo pomaga”.

Projektant może rozpocząć pracę bez głębokiej znajomości Reacta. Co ważne, widok agenta w Cursorze obniża próg wejścia, bo pozwala sterować procesem rozmową. Podstawowa świadomość frameworka pomaga. Znajomość metod stylowania komponentów jest przydatna. Doświadczenie w inżynierii designu – połączenie obu światów – daje największą przewagę, choć nie jest wymagane.

Projektant jako inicjator procesu

Banks zadał kluczowe pytanie: „Jeśli jestem designerem, a ty jesteś inżynierem i robię to dobrze, dzielę się z tobą tym katalogiem, czy to pomocne?”

Petrie nie tylko potwierdził, ale zachęcił: „Absolutnie. I myślę, że to dobry moment dzielenia się wiedzą również. Bardzo zachęcam designerów, którzy nie mają pełnej świadomości Reacta, żeby wejść w to przynajmniej żeby zanurzyć palce w wodach. Teraz zaczniesz zapoznawać się z tym, jak wygląda struktura tych komponentów z punktu widzenia dewelopera”.

Nawet jeśli kod nie jest w 100% gotowy do produkcji, powstaje wspólny grunt do rozmowy. „Nawet jeśli to nie jest w 100% gotowe do produkcji, przynajmniej masz o czym rozmawiać. Masz punkt wyjścia do komunikacji z deweloperem i powiedzenia 'dlaczego to nie jest tam gdzie być powinno?'”

Deweloper finalizuje interakcje i dostępność

Deweloper może wskazać najlepsze praktyki, designer dodaje je do kontekstu dla AI następnym razem. „Więc następnym razem gdy to się zdarzy, powiesz AI żeby po prostu odniosło się do tych innych komponentów, żeby wiedziało styl. Więc będzie wykładniczo lepsze za każdym razem gdy generujesz te rzeczy”.

Deweloper finalizuje interakcje i dostępność oraz pilnuje standardów kodu. W efekcie przekazanie 2.0 (handoff) przyspiesza wdrożenie i ogranicza nieporozumienia.

Petrie opisał progresję: „Może pierwszym razem, może jesteś 30% drogi. Może 60% drogi następnym razem, może 90% drogi następnym razem. I wtedy naprawdę zasypujesz tę lukę między designem a deweloperką”.

Inżynieria kontekstu vs kodowanie intuicyjne

Petrie wprowadził rozróżnienie kluczowe dla zrozumienia profesjonalnego wykorzystania AI.

Kodowanie intuicyjne to szybkie prototypowanie w narzędziach typu Lovable czy Bolt. Świetne do narzędzi osobistych – Petrie pokazał przykłady: wyszukiwarka najbliższych toalet z Google Maps API, tracker odżywiania „Eaton” gdzie dyktowanie posiłków automatycznie pobiera kalorie i makroskładniki, parsery faktur, sprawdzarki kontrastu kolorów.

To wszystko były „proste małe aplikacje”, ale „pomagały nam w naszych osobistych życiach”. Minimalna kontrola nad finalnym kodem, jednak świetne do eksploracji i życiowych sztuczek.

Petrie opisał fascynujące zjawisko: „Nie jest rzadkością dla mnie budowanie rzeczy, ale wtedy budowanie narzędzia, które pomaga mi budować tę rzecz lepiej. Więc wchodzi się w taką inception narzędzi AI, gdzie budujesz narzędzia, które budują narzędzia”. To meta-poziom pracy z AI, który otwiera nowe możliwości.

Inżynieria kontekstu to świadome zarządzanie kontekstem dla AI. Wykorzystanie istniejących komponentów jako wzorców. Przestrzeganie konwencji zespołu. „Człowiek w pętli” na każdym etapie. Jak mówi Petrie: „Inżynierujemy kontekst tego wszystkiego przez całą drogę. Nie bierzemy tego po prostu jak jest. Zawsze bierzemy to co przychodzi i wtedy robimy pełne sprawdzenie, żeby upewnić się, że koduje w sposób jaki South Left lubi kod”.

Wprowadził koncepcję inżyniera kontekstu: „Ukuliśmy de facto coined term to inżynier kontekstu. Ale inżynierujemy kontekst tego wszystkiego przez całą drogę, ponieważ nie bierzemy tego po prostu jak jest”.

Istotny element to arkusz kalkulacyjny konwencji nazewnictwa, który South Left utrzymuje z definitywną listą nazw komponentów i uzasadnieniami tych wyborów.

Pole Description w Figmie – sekretna broń

Jednym z najbardziej praktycznych odkryć Petrie’ego jest wykorzystanie pola Description w Figmie jako źródła kontekstu dla AI.

AI świetnie odczytuje wartości wizualne: kolory, zaokrąglenia, odstępy, rozmiary fontów, hierarchię elementów. Jednak nie rozumie intencji behawioralnych. Petrie dał konkretny przykład: „Czy zestaw paneli accordion powinien zwijać wszystkie czy pozwolić wszystkim być otwartym gdy jeden jest wybrany. To jest intencjonalne zachowanie”.

To nie wynika z wyglądu komponentu – to decyzja projektowa, która musi być gdzieś zapisana.

Petrie wyjaśnił rozwiązanie: „Więc tam wykorzystujemy to pole. Mamy własny MCP, który jest podobny do Figma MCP, którego używamy, który pomaga zbierać dane stąd i wtedy zapewniać dodatkowy kontekst do AI żeby upewnić się, że nie tylko przybija wygląd i wrażenia, ale też dostaje interakcje i zachowania, które są zamierzone dla tego komponentu”.

Pole Description w Figmie niesie intencje i pomaga AI odtworzyć zachowania w kodzie (np. logikę zwijania akordeonu czy priorytety fokusów). Dlatego AI łączy te informacje z danymi wizualnymi.

Ten kontekst przenosi się przez cały workflow, tworząc „kaskadę kontekstu” – koncepcję z Context Based Design Systems, innego warsztatu Petrie’ego. Kontekst przepływa: z Figmy (pola opisów, tokeny, właściwości) → przez MCP → do wygenerowanego kodu → do dokumentacji → do narzędzi typu Zeroheight czy Storybook.

Petrie podkreślił fundamentalną prawdę: „Kontekst jest tym, co AI kocha. Kontekst jest jak ja kocham pizzę. Kontekst jest tym, co AI naprawdę lubi. Więc im więcej kontekstu możesz podać, tym lepszy będzie output i tym lepsza będzie wiedza, którą będzie posiadać”.

Dokumentacja i intencje, które czyta AI

Tradycyjnie dokumentacja systemów projektowych to setki godzin pracy. Chris z uczestników wyraził frustrację: „Oczywiście wielu z nas designerów spędziło absurdalną ilość czasu na dokumentacji i użyciu tych komponentów”.

Petrie pokazał, jak odwrócić ten proces i wykorzystać tę wcześniejszą pracę.

Trzy poziomy automatyzacji

Poziom 1: Podstawa (zero wysiłku) – „Zamiast zaczynać od zera, komponent sam jest prawie samoobsługujący dla dokumentacji. Więc na bardzo podstawowym poziomie, możesz użyć Figma MCP żeby napisać dokumentację dla komponentu bazując na tym co MCP wie o tym komponencie”.

Zawiera: właściwości, warianty, tokeny, projekt wizualny. Wystarczy do szybkiego odniesienia.

Poziom 2: Wzbogacony kontekstem (minimalny wysiłek) – Description fields z Figmy, notatki behawioralne, wymagania dostępności, przypadki użycia i przykłady.

Poziom 3: Pełny system dokumentacji (skonfiguruj raz, używaj zawsze) – Dokumentację można następnie wygenerować z MCP do plików markdown i trzymać blisko kodu, co ułatwia wyszukiwanie oraz utrzymanie spójności.

Company Docs – własne narzędzie

Petrie opisał swoje rozwiązanie: „Stworzyliśmy narzędzie do tego zwane Company Docs. I Company Docs jest MCP gdzie możesz – możesz użyć twojego Figma MCP żeby generować twoje dokumenty jako pliki markdown i umieścić je w folderze docs. Możesz zainstalować przez NPM to Company Docs i zamieni twoje dokumenty w serwer MCP i wtedy możesz połączyć ten serwer MCP do Claude desktop do Slacka. Możesz użyć slash docs i wtedy zbierać informacje z twoich dokumentów”.

Rezultat: „To jest po prostu sposób żeby udostępnić twoją dokumentację do jakiejkolwiek usługi lub jakiejkolwiek platformy, którą chcesz zamiast mieć ją w jednym miejscu połączonej z jedną bazą kodu”.

AI zawsze wykorzysta Twoją pracę

Chris z uczestników martwił się o lata włożone w dokumentację. Petrie odpowiedział z przekonaniem, które Jenny z chatu podsumowała doskonale: „AI zawsze użyje i przeczyta dokumentację. To nie jest zmarnowane. To jest absolutnie kopalnia złota kontekstu”.

To zmienia perspektywę – cała ta praca staje się paliwem dla AI, które może teraz wykorzystać te lata wiedzy do generowania lepszego kodu, lepszej dokumentacji, lepszych wskazówek dla zespołu.

Atomic Design + AI = wykładniczy wzrost jakości

Petrie wyjaśnił kluczową strategię maksymalizującą efektywność AI w budowaniu systemów.

Zasada: zaczynaj od najmniejszego

Graydon z uczestników zapytał o bardziej złożone komponenty: „Chcę lepiej zrozumieć z atomowej perspektywy jak byś obsłużył bardziej złożone komponenty? Więc może jest kilka zagnieżdżonych komponentów w większym komponencie. Czy zaczynasz od mniejszych zagnieżdżonych komponentów i wtedy w końcu budujesz do bardziej złożonych komponentów?”

Petrie potwierdził: „Tak. Trafiłeś w sedno. Tak. I nie skaczesz naprzód. Jesteś właściwie w prawym momencie”.

Kluczowa instrukcja w prompcie

Ta jedna instrukcja sprawia, że AI najpierw skanuje istniejące komponenty zamiast tworzyć wszystko od nowa. „Tworzysz po prostu komponent, który nie ma żadnych innych zagnieżdżonych komponentów w sobie. Zaczynasz na tym malutkim, malutkim, malutkim poziomie. I wtedy zaczynasz budować”.

Petrie używa metafory odwróconego trójkąta: „To jest jak wiesz, odwrócony trójkąt i wtedy gdy rzeczy stają się bardziej skomplikowane gdzie masz warstwy zagnieżdżonych komponentów, wtedy pomysł jest taki, że jeśli zachowam ten punkt tutaj, to będzie kontynuować skanowanie innych komponentów, które są dostępne i wtedy je uszereguje i zaimportuje te komponenty”.

Progresja jakości

Petrie opisał zjawisko wykładniczego wzrostu, które obserwuje w swojej agencji:

Iteracja 1: 30% gotowości do produkcji – „AI generuje bazę, dużo ręcznych poprawek, uczysz AI o swoich wzorcach. Więc następnym razem gdy to się dzieje, powiesz AI żeby po prostu odniosło się do tych innych komponentów, żeby znało styl”.

Iteracja 2: 60% gotowości do produkcji – „AI używa poprzednich komponentów, mniej błędów stylistycznych, lepsze dopasowanie do konwencji. Więc będzie wykładniczo lepsze za każdym razem gdy generujesz te rzeczy i za każdym razem gdy masz kolejną konwersację z zespołem deweloperskim”.

Iteracja 3: 90% gotowości do produkcji – „AI w pełni rozumie system, minimalne poprawki, prawie gotowy do zatwierdzenia kod. I wtedy z czasem zaczniesz wnosić aktualny kod, który możesz zatwierdzać i przesyłać do środowiska przed-produkcyjnego”.

„Zamiast zaczynać od zera, zaczynasz mając 30% drogi za sobą, może 60% drogi następnym razem, może 90% drogi następnym razem. I wtedy naprawdę zasypujesz tę lukę między designem a deweloperką”.

Kiedy potrzebujesz człowieka – zawsze, ale szczególnie przy złożoności

Petrie był szczery co do ograniczeń: „Gdy dostajesz się bardziej złożony na tym poziomie organizmu, to jest gdy interakcja człowieka musi być częścią tego od kroku pierwszego. Więc to naprawdę ważne żeby po prostu powtórzyć przez cały ten proces”.

Czasami AI „zaczyna działać chaotycznie” – „To jest identyczne do sposobu jakiego inni deweloperzy i wszystkie inne komendy AI, ponieważ czasami pójdzie na żywioł i zrobi coś zupełnie innego. Skąd SCSS się wzięło? Jak nie używaliśmy tego w tej bazie kodu a nagle pomyślał, że używamy. To bardzo rzadkie gdy się zdarza”.

Dlatego „zaangażowanie człowieka musi się dziać na każdym kroku, szczególnie gdy dochodzi do tych bardziej złożonych komponentów”.

Ograniczenia i oczekiwania

Petrie był transparentny co do granic technologii i rzeczywistych ograniczeń pracy z MCP:

Czego MCP nie może zrobić

Brak zapisu z powrotem do Figmy – Konektor jest tylko do odczytu, co oznacza jednokierunkowy przepływ danych. Petrie uznaje to za zaletę dla stabilności projektu.

Przy złożonych organizmach mogą wystąpić błędy wnioskowania – Dlatego warto rozbijać pracę na mniejsze elementy i stosować podejście atomic design.

Zużycie tokenów zależy od użytych narzędzi – W konsekwencji warto wyłączać niepotrzebne funkcje konektora (np. FigJam czy Code Connect jeśli ich nie używasz).

Holistyczne operacje są niemożliwe – Nie można dostarczyć raportu całego projektu naraz, nie zwróci całej tabeli zmiennych ze wszystkimi trybami, nie przetworzy wszystkich komponentów w bibliotece jednocześnie.

Zakres działania jest ograniczony – MCP może pracować tylko z konkretnym frame’em lub komponentem, zwraca zmienne związane z wybranym elementem.

Praktyczne uwagi techniczne

Lista funkcji konektora obejmuje także FigJam i Code Connect – Ale jeśli ich nie używasz, można je wyłączyć dla oszczędności tokenów.

Tryb Dev Mode w Figmie jest dostępny na planach płatnych – W Claude Desktop mogą obowiązywać dodatkowe limity tokenów w zależności od planu.

Model Claude Sonnet 4.5 bywa „nadgorliwy” – Petrie zauważył: „Czasami może trochę przesadzić. Używam Sonnet 4.5. Idzie bardzo mocno”. Pomaga precyzyjne polecenie i wskazanie katalogów wzorców.

Praktyczne zastosowania poza systemami

Banks i Petrie podzielili się obserwacją: nie wszystko musi być gotowe do produkcji, aby było wartościowe.

Narzędzia osobiste – uczenie przez budowanie

Petrie opisał swoje podejście do nauki: „Trzymam listę kontrolną w Apple Notes – co chcę zrobić, co próbuję z tym zrobić. Mam przeszły dziennik aplikacji i rzeczy nad którymi pracuję”.

Nazywa to „inception narzędzi AI” – budowanie narzędzi, które budują narzędzia. Jego przykłady z codziennej praktyki pokazują ewolucję myślenia od prostych aplikacji życiowych (wyszukiwarka toalet, tracker odżywiania) do narzędzi zawodowych (generatory dokumentacji, konwertery tokenów, narzędzia QA).

Petrie podsumował tę drogę: „Zaczęło się od tych typów małych małych sposobów żeby wymyślić życiowe sztuczki. I wtedy w końcu przemieściło się to do naszego świata pracy”.

Dostępność w sieci – niespodziewany bonus

Banks zauważył praktyczną zaletę lokalnego developmentu: „Gdy uruchamiamy rzeczy lokalnie, możemy uzyskać do nich dostęp na całej naszej sieci. Jeśli jesteś w domu i jesteś na swoim wifi, jeśli uruchomisz coś na swoim komputerze, absolutnie możesz uzyskać do tego dostęp na swoim telefonie”.

Praktyczny przypadek użycia: Storybook na localhost:6006, dostęp z telefonu przez wifi, testowanie komponentów na urządzeniach mobilnych w realnym środowisku, pokazywanie prototypów klientom bez wdrażania.

Dyscyplina i przytłoczenie – szczerze o kosztach

Codzienna rutyna – dwie godziny przed świtem

Petrie podzielił się swoją praktyką, która wymaga realnej dyscypliny: „Odkładam około dwie godziny każdego ranka zanim moje dzieci się obudzą gdzie jest bardzo cicho, jest ciemno na zewnątrz i nie ma przychodzących emaili. Mam wystarczająco czasu żeby skupić się i skoncentrować na tym co próbuję zrobić”.

System organizacji jest prosty, ale konsekwentny: lista kontrolna w Apple Notes, lista „co chcę zrobić” + „co próbuję osiągnąć”, dziennik przeszłych projektów i narzędzi, bieżące eksperymenty.

Dawki dopaminy vs porażki – realistyczne oczekiwania

Petrie był brutalnie szczery co do wskaźnika sukcesu: „Na 10 prób, które wypróbujesz, dostaniesz wielką wygraną. I to wystarczy dopaminy żeby cię utrzymać. Ponieważ te wygrane, które dostajesz z tych narzędzi, które używasz, szczególnie w branży w której jesteś i zestawie umiejętności, które posiadasz, gdy trafisz tę rzecz, to jest jackpot. Czujesz się jakbyś właśnie – czujesz się jakbyś odblokował kod do gry”.

Ale przed tym jackpotem jest dziewięć prób, które mogą nie działać. „Będzie dużo rzeczy, na które spędzisz dużo czasu i dużo tych rzeczy, na które spędzisz dużo czasu, poniesiesz porażkę. Będziesz sfrustrowany, ponieważ nie będzie robić rzeczy, którą chciałeś żeby robiła”.

Przyjęcie przytłoczenia jako stałego stanu

Petrie nie udawał, że ma wszystko pod kontrolą: „Jestem poza przytłoczony. Jak powiem ci to – bycie przytłoczonym nigdy się nie skończy. Nigdy nie jestem głęboko w tym. Ale to po prostu bycie okej z byciem przytłoczonym myślę i posiadanie możliwości bycia jak 'okej, to nie wyszło, przejdę dalej i wtedy zobaczę co jeszcze tam jest'”.

Jego rada brzmi paradoksalnie: „Trudno powiedzieć, ale rada to po prostu to zrobić i wskoczyć i nie bać się. I to jest trochę jak syndrom przedsiębiorczy. To jest jak podejmuj duże ryzyko, wiesz. Bez ryzyka, bez nagrody – typ sytuacji”.

Banks dodał perspektywę, która rezonowała z setkami uczestników: „Po prostu czuję się przytłoczony i trochę zestresowany. Myślę, że wszyscy to czujemy. To jest bardzo powszechne i uogólnione uczucie dzisiaj w branży”.

Tydzień przerwy = bycie w tyle

Banks i Petrie zgodnie przyznali realność sytuacji: „Bierzesz tydzień przerwy od tego i jesteś w tyle. Przegapisz narzędzie i jesteś w tyle”. Nowe narzędzia, modele i możliwości pojawiają się w tym tempie, że przerwa naprawdę oznacza konieczność nadrabiania.

Jednak Petrie pokazał, że to nie musi być przygnębiające – to może być ekscytujące, jeśli zaakceptujesz przytłoczenie jako część podróży.

Koszt i dostępność

Zestawienie kosztów według narzędzi

Claude Desktop + Figma MCP: Wymaga płatnej subskrypcji Claude dla pełnego dostępu. Uczestnicy zauważyli: „Używanie Figma wewnątrz Claude to funkcja płatna”. Jednak instalacja konektorów sama w sobie jest darmowa.

Cursor + Figma MCP: Darmowa wersja dostępna z limitami tokenów, płatna wersja znosi większość limitów, instalacja MCP darmowa. Banks podkreślił: „To może być lepsza ścieżka dla wielu ludzi dopiero zaczynających”.

Figma Dev Mode: Wymagany dla działania MCP. Uczestnik potwierdził w chacie: „Musisz mieć dev mode, ale wszystkie płatne pakiety”. Dostępny we wszystkich płatnych pakietach Figmy, nie działa na darmowym planie.

Storybook: Całkowicie darmowe i open-source, bez limitów użytkowania, bez kosztów.

Minimalna konfiguracja (najtańsza ścieżka): Płatny plan Figmy (Dev Mode) który większość już posiada + Cursor z darmowym kontem (limity tokenów wystarczające na start) + Storybook lokalnie (całkowicie za darmo). Koszt dodatkowy: zero, jeśli już masz płatną Figmę.

Figma Make i przyszłość round-tripping

Banks wprowadził temat, który nurtuje wielu designerów: „Jedna rzecz, która zawsze była moim punktem niepokoju to no wiesz, buduję to wszystko w Figmie i jeśli wyjdę poza Figmę, w pewnym momencie muszę dostać to z powrotem do narzędzia, ponieważ to jest nasz wspólny grunt”.

Figma Make jako częściowe rozwiązanie

Banks był entuzjastyczny o nową funkcję: „Z Figma Make, jedna fajna funkcja, która jest tam teraz to jeśli przesuniesz design naprzód, jest teraz przycisk kopiuj design, który pozwala skopiować cokolwiek zrobiłeś w Figma Make i przynieść to z powrotem”.

Figma Make pozwala skopiować efekt powstały „na zewnątrz” z powrotem do Figmy („Copy design”). Generujesz prototyp w Figma Make, kopiujesz design z powrotem do głównego pliku Figmy, możesz kontynuować iteracje w głównym pliku, nie tracisz pracy zrobionej poza Figmą.

Banks dodał z wyraźną nadzieją: „I myślę, że jak widzimy więcej i więcej wsparcia komponentów wewnątrz Figma Make tutaj w następnych kilku tygodniach lub miesiącach, to będzie niesamowite mieć to”.

Moment przełomowy – od ciekawostki do rewolucji

Petrie podzielił się osobistą historią, która pokazuje jak stopniowo docierało do niego, że to nie jest tylko zabawka.

Nieoficjalny Figma MCP – pierwszy prawdziwy test

Impuls do pracy z MCP dało ogłoszenie tej koncepcji; przed oficjalnym konektorem Figmy testowano nieoficjalny „Framelink”.

Przed oficjalnym Figma MCP istniał projekt stworzony przez społeczność, który teraz nazywa się Framelink: „I wtedy był pierwszy nieoficjalny Figma MCP, który wyszedł i to był pierwszy, który zacząłem testować myśląc okej to jest świetne. Jak mogę przenieść design, który był – lub komponent, który jest w Figmie do mojej bazy kodu i wtedy po prostu sprawić żeby działał”.

Petrie z wyraźnym entuzjazmem wspomniał przełomowy moment: „I to był moment eureka – i to jeden z momentów, który faktycznie zacząłem, ponieważ zawsze nagrywałem dużo tylko testowania z rzeczami kodowania intuicyjnego”.

Demo, które zmieniło wszystko

„Myślę, że jedno z pierwszych demo, które rezonowało z dużą liczbą ludzi i które sprawiło, że poczułem okej to jest ważne było jednym z nich, które opublikowałem na tym oryginalnym pre-Figma MCP. Teraz nazywa się Framelink i ukłony dla dewelopera tego”.

Co było tak przełomowe? „Bardzo mało informacji dostarczonych do AI i wygenerowało baner oparty na web component z naszego Altitude, naszego wewnętrznego systemu projektowego. I wtedy było po prostu jak po tym było po prostu jak wkopywanie się w każdą możliwą rzecz, którą mogliśmy”.

Minimalna konfiguracja, maksymalny output, realne komponenty nie makiety, praktyczna użyteczność od razu. To pokazało, że technologia jest gotowa do czasu produkcyjnego.

Refleksje na koniec – nowa rzeczywistość dla systemów projektowych

Banks – perspektywa designera na rewolucję

„Pamiętam gdy zaczynałem w designie i inżynierowie byli w Storybook i nie miałem pojęcia jak to ustawić, nie miałem pojęcia jak dostać coś z Figmy, nie miałem pojęcia jak to przetłumaczyć. I teraz, gdy łapiesz to, zajęłoby to maksymalnie 10 minut żeby ruszyć. To jest absolutnie niewiarygodne.„

Co się zmieniło w ciągu zaledwie kilku miesięcy:

Setup z dni do minut
Bariera wejścia dramatycznie niższa
Designer może wchodzić w terytorium kodu
Luka we współpracy się zwęża
Wspólny język przez kod i narzędzia

Petrie – perspektywa inżyniera na zmianę

„Ten nieoficjalny Figma MCP był prawdopodobnie katalizatorem, który był 'okej powinniśmy zacząć skupiać te proste małe aplikacje na znaczących rzeczach, które mogą pomóc naszej organizacji tak samo jak innym organizacjom, z którymi pracujemy'”.

Co się zmieniło w sposobie pracy South Left:

Narzędzia AI przestały być zabawkami
Inżynieria kontekstu jako dyscyplina
Możliwe są outputy gotowe do produkcji
Wykładniczy wzrost z każdą iteracją
Nadzór człowieka jako zaleta, nie wada

Wspólne wnioski – siedem kluczowych lekcji

1. Bariera jest niższa niż myślisz

Instalacja: 2-3 kliknięcia
Pierwszy komponent: około 10 minut
Nie potrzebujesz stopnia z informatyki
Tryb agenta dla mniej technicznych

2. Nadzór człowieka jest niezbędny

AI to narzędzie, nie zamiennik
Inżynieria kontekstu lepsza od kodowania intuicyjnego
Kontrola jakości na każdym etapie
„Nie bierzemy tego po prostu jak jest”

3. Zacznij małe, rośnij wykładniczo

Podejście atomic design działa
Każda iteracja jest lepsza (30% → 60% → 90%)
Bloki konstrukcyjne prowadzą do złożoności
Cierpliwość się opłaca

4. Kontekst jest królem

Pola opisów w Figmie = tajna broń
Istniejące komponenty jako wzorce
Dokumentacja jako kopalnia złota
„Kontekst jest tym co AI kocha”

5. Przytłoczenie jest normalne

Wszyscy to czują, Banks i Petrie też
Tydzień przerwy = bycie w tyle
Akceptacja przytłoczenia jako stanu
Dawki dopaminy z małych zwycięstw (1 na 10 prób)

6. Luka między designerem a deweloperem się zmniejsza

Wspólny język przez kod
Wspólne zrozumienie przez narzędzia
Przekazanie staje się iteracją
„Naprawdę zasypywanie tej luki”

7. Nie wszystko musi być gotowe do produkcji

Narzędzia osobiste uczą
Proste aplikacje prowadzą do znaczącej pracy
Inception narzędzi AI = budowanie narzędzi, które budują narzędzia
Eksperymentowanie ma wartość samo w sobie

Ostatnie słowa – odblokowywanie kodów do gry

Banks podsumował uczucie wielu: „Po prostu czuję się przytłoczony i trochę zestresowany. Myślę, że wszyscy to czujemy. To jest bardzo powszechne i uogólnione uczucie dzisiaj w branży”.

Jednak Petrie pokazał, że przytłoczenie można przekuć w postęp: „Te wygrane, które dostajesz z tych narzędzi, szczególnie w branży w której jesteś i zestawie umiejętności, które posiadasz – gdy trafisz tę rzecz, to jest jackpot. Czujesz się jakbyś odblokował kod do gry.„

To nie jest zamiana ludzi na maszyny. To nie jest eliminacja pracy designera czy dewelopera. To jest odblokowywanie kodów do gry – nadal grasz w tę samą grę, nadal robisz tę samą pracę, ale nagle masz narzędzia, które pozwalają ci iść dalej, szybciej, głębiej niż kiedykolwiek wcześniej.

Banks na zakończenie przypomniał o wspólnym celu: „Naszym celem dla tej sesji dzisiaj jest bardzo byśmy chcieli mieć pytania od was wszystkich, bardzo byśmy chcieli mieć was z włączonym mikrofonem, powiedzieć hej”. I dostał to – niemal 300 osób przyszło nie po to, żeby siedzieć cicho i słuchać o teorii. Przyszli zobaczyć prawdziwe demo, zadawać pytania, zacząć swoją własną podróż.

Jak powiedział Petrie na początku: „Rada to po prostu to zrobić i wskoczyć i nie bać się”.

Kluczowy insight

Tylko do odczytu przyspiesza dostarczenie

Standardowo myślimy: Dwukierunkowa synchronizacja Figma ↔ kod jest konieczna, aby działać szybciej. Potrzebujemy narzędzi, które pozwolą nam edytować zarówno po stronie designu jak i kodu, a zmiany będą się synchronizować w obie strony.

W praktyce okazuje się, że: Konektor tylko do odczytu z jednym punktem prawdy w Figmie skraca pętlę i ogranicza wycofania zmian. Generacja i poprawki odbywają się po stronie kodu i Storybooka, plik projektowy pozostaje nienaruszony. To jednokierunkowe podejście eliminuje konflikty edycyjne, które powstają przy dwukierunkowej synchronizacji.

Dlaczego to jest istotne: Stabilne źródło zmniejsza konflikty edycyjne i rozbieżności. Gdy Figma jest punktem odniesienia tylko do odczytu, zespoły nie muszą zarządzać konfliktami scalania między designem a kodem. W rezultacie zespoły szybciej osiągają zgodność wizualną oraz interakcyjną. Petrie podkreślił: „Wolałbym, żeby inżynierowie nie mieli żadnej kontroli nad moimi rzeczami w Figmie” – ta separacja odpowiedzialności faktycznie przyspiesza proces.

Test na jutro: Przy następnym komponencie przyjmij zasadę „tylko do odczytu”:

Użyj trybu Desktop MCP dla szybszego działania
Opisz intencje w polu Description w Figmie
Przepuść komponent przez Figmalint przed generacją
Wygeneruj TSX/CSS Modules/.stories
Popraw wyłącznie w kodzie (nie wracaj do Figmy, chyba że to błąd projektowy)
Gdy to konieczne, na końcu użyj w Figma Make funkcji „Copy design”

Zmierz czas do pierwszego renderu w Storybooku na localhost:6006, liczbę poprawek i wycofań względem dotychczasowego trybu pracy z dwukierunkową synchronizacją. Większość zespołów odkrywa, że osiągają pierwszy działający komponent o 40-60% szybciej przy jednokierunkowym przepływie.

Uzupełnienia z rozmowy – dodatkowe perełki

LinkedIn jako platforma uczenia się

Banks w swoim wstępie podkreślił wartość podejścia Petrie’ego: „Co najbardziej kocham w TJ to że on trochę po prostu udostępnia prawdziwą rzecz, nieedytowaną, co działa dla niego w świecie MCP i AI”. To nie są wypolerowane prezentacje czy teoretyczne pogadanki – to prawdziwe próby, pokazywanie zarówno sukcesów jak i porażek.

Banks wyraził frustrację, którą czuje cała branża: „Tam gdy mówimy o AI w branży myślę, że jest dużo wysokopoziomowych rozmów i jest dużo założeń, że już znasz to wszystko i jesteś w tym”. To podejście – zaczynanie od zera – jest tym, czego brakuje w większości treści o narzędziach AI.

Lovable i niestandardowe biblioteki komponentów

Keaton zadał pytanie o Lovable. Petrie wyjaśnił workflow: „Możesz użyć MCP żeby stworzyć twoją bibliotekę komponentów, ale wtedy użyć tej biblioteki komponentów w Lovable żeby być w stanie faktycznie generować logikę biznesową dla tej aplikacji”.

Jednak dodał: „Twoje kanoniczne źródło skończyłoby jako twoja baza kodu i wtedy musiałbyś przepakować to jako nową wersję i wtedy ponownie przesłać to do Lovable. Ta część Lovable jest trochę szara strefa dla mnie. Nie miałem dużo sukcesu z tą częścią tego. Ale wiem, że bardzo ciężko nad tym pracowali”.

Co Lovable potrafi out-of-the-box: ShadCN, Mantine, Chakra, Material UI. To pokazuje, że nie wszystko jest jeszcze rozwiązane – niestandardowe systemy projektowe w narzędziach do kodowania intuicyjnego to dalej rozwijający się obszar.

Tailwind i AI

W kontekście frameworków Petrie rzucił ciekawą obserwację: „AI seems to really love Tailwind because it’s very popular”. To prosty fakt – większa popularność oznacza więcej danych treningowych, co przekłada się na lepsze wyniki z AI. Teams myślące o adoption nowych narzędzi mogą chcieć wziąć to pod uwagę.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. To zapis webinaru Joey’a Banksa i TJ Petrie Doing More With Your Design System in Figma