Jak Atlassian skaluje AI prototypowanie z design systemem: szablony, recipes i strategie adopcji #EN363

Poniższy artykuł stanowi notatki z odcinka podcastu Dive Club, w którym Lewis Healy i Kyler Hall z zespołu Atlassian Design System dzielą się doświadczeniami z wdrażania AI prototypowania w organizacji liczącej 11 000 pracowników. Wszystkie opisane obserwacje, wnioski i strategie pochodzą bezpośrednio od rozmówców.

TL;DR

Wrzucenie dokumentacji design systemu do AI jako pliku tekstowego nie przynosi oczekiwanych rezultatów. Model obcina informacje i generuje halucynacje komponentów.
Hybrydowe szablony z wstępnie zakodowaną nawigacją zredukowały błędy z około 50% do niemal zera. AI znacznie lepiej modyfikuje istniejący kod niż tworzy wszystko od podstaw.
Sekcja „Translating from Tailwind” wykorzystuje wiedzę modelu wyniesioną z treningu jako pomost do własnych komponentów. Zespół rozważa przy tym zmianę nazewnictwa na bliższe standardom branżowym.
Recipes to gotowe bloki kodu dla powtarzalnych elementów. Świadomie nie są idealnie dopracowane, ponieważ mają być wystarczająco dobre.
Technika „printer sheet” pozwala odkryć ograniczenia widzenia komputerowego i dostosować instrukcje dla użytkowników.
Wiadomości prywatne działają lepiej niż kanały grupowe, ponieważ odbiorcy czują większą presję odpowiedzi. Slack bot skaluje ten efekt na setki osób.
Obecny stan to posklejane agenty, z których każdy robi jedną rzecz dobrze. Cel pięcioletni zakłada, że designer będzie mógł otworzyć pull request i eksperymentować w produkcji.

Kontekst

Atlassian zatrudnia około 11 000 osób. Setki designerów, product managerów i inżynierów chce korzystać z narzędzi AI do prototypowania. Lewis Healy (Lead Design Technologist) wraz z Kylerem Hallem z zespołu Design System stanęli przed konkretnym wyzwaniem: jak umożliwić tysiącom nietechnicznych użytkowników tworzenie prototypów wyglądających jak produkty Atlassian?

Co ciekawe, Healy przyznaje, że nie był wczesnym entuzjastą AI. Był, jak sam określa, „dość w tyle jeśli chodzi o wiele rzeczy”. Jego droga do prowadzenia filaru AI zaczęła się od zupełnie innej perspektywy: adopcji design systemu i obaw, że AI generuje doświadczenia niezgodne z Atlassian Design System.

Artykuł dokumentuje podróż zespołu od niedziałających promptów do dojrzałego systemu szablonów, recipes i strategii adopcji.

Problem: dlaczego wrzucenie dokumentacji do AI nie działa

Pierwsza próba integracji design systemu wydawała się oczywista. Zespół wziął dokumentację Atlassian, umieścił ją w pliku tekstowym i polecił AI budować na tej podstawie.

Wyniki okazały się słabe. Plik był zbyt duży, więc model obcinał informacje i generował tylko część komponentów. Co gorsza, nie rozumiał jak używać tych komponentów w kontekście prototypowania. Skuteczność generowania kodu w jednym podejściu (tzw. one-shot prompting) wynosiła jedynie 50-60%.

Zespół popełnił klasyczny błąd. Próbowali zastosować do maszyny mentalny model człowieka czytającego dokumentację. To założenie okazało się fundamentalnie nietrafione.

Prompty liczące sto linii jako kolejna próba

Przed szablonami zespół testował inne podejście. Dawali ludziom zestaw promptów liczący około stu linii do skopiowania i wklejenia do Figma. Zawierały konfigurację themingu, feature flags i inne ustawienia.

Problem polegał na tym, że wiele z tych rzeczy nie jest dobrze udokumentowanych nawet wewnętrznie. Jak ujmuje to Hall: jedyny sposób to w zasadzie poprosić inżyniera, żeby pokazał jak to zrobić. Tymczasem celem było umożliwienie prototypowania osobom bez wiedzy inżynierskiej.

Rozwiązanie: hybrydowe szablony z wstępnie zakodowanymi elementami

Przełom nastąpił po zmianie podejścia. Zamiast instruować AI jak budować nawigację od zera, zespół zakodował ją z góry.

Trzy warstwy podejścia hybrydowego

Eksperci z Atlassian podzielili proces tworzenia prototypu na trzy wyraźne warstwy:

Sztywna rama (Shell): Elementy nawigacji dostarczane jako gotowy, zakodowany szablon. Zaszyta jest w nich „wiedza inżynierska”, o której designerzy często nie mają pojęcia: flagi funkcjonalne, routing czy specyficzne ustawienia motywów.
Elastyczna treść: Wnętrze strony generowane przez AI na podstawie promptów, co pozwala na szybką iterację pomysłów.
Przepisy (Recipes): Gotowe bloki kodu dla skomplikowanych funkcji takich jak tryb ciemny czy okno czatu. Użytkownik wkleja je zamiast generować, co gwarantuje poprawność techniczną.

Dlaczego nawigacja jest krytyczna

Healy wyjaśnia hierarchię ważności elementów. Gdy górna i boczna nawigacja są niepoprawne, użytkownicy zaczynają się gubić, a orientacja przestrzenna szwankuje. Osoby testujące prototypy rozpraszają się błędami w nawigacji.

Z kolei treść w głównym obszarze? Tutaj można sobie pozwolić na więcej niedoskonałości. To ważne rozróżnienie: nawigacja musi być precyzyjna, natomiast content ma większą tolerancję błędów.

Anatomia szablonu

Każdy szablon Atlassian zawiera:

Wstępnie zakodowany top nav i side nav, czyli elementy, które AI konsekwentnie psuło przy generowaniu od zera
Konfigurację themingu i feature flags, czyli rzeczy, o których designer nie powinien wiedzieć, że istnieją
Instrukcje dla użytkownika wbudowane w interfejs, w tym kopiowalne komendy redukujące typowe halucynacje
Obiekt konfiguracyjny ze stałymi, czyli zakodowane na twardo wartości dla ikon i logo

Hall podkreśla jakość bazy: szablon to dobry kod, zatwierdzony przez zespół front-endowy. Dodaje też, że może być nawet lepszy niż zupełnie nowy proof of concept aplikacji, którą ktoś mógłby uruchomić. Użytkownicy startują zatem z kodem produkcyjnej jakości.

Dlaczego to działa

Healy zauważa, że AI jest znacznie lepsze w modyfikowaniu istniejącego kodu niż tworzeniu wszystkiego od podstaw. Wcześniej model próbował brać pustkę i budować wszystko. Teraz ma solidny fundament.

Przed wprowadzeniem szablonów około połowa prototypów miała problemy z nawigacją. Po wdrożeniu hybrydowego podejścia błędy spadły do sporadycznych halucynacji ikon. Użytkownicy spędzali wcześniej dwie do trzech godzin na dopracowywaniu nawigacji. Obecnie mogą od razu skupić się na właściwej treści prototypu.

Sekcja „Translating from Tailwind”: komunikacja językiem AI

Hall zwraca uwagę na kluczową obserwację. Większość modeli trenowano na ogromnej ilości kodu open source. Tailwind i shadcn są wszędzie. Zamiast z tym walczyć, zespół postanowił to wykorzystać.

Token system jako szczególne wyzwanie

Hall mówi wprost: musiał stworzyć instrukcje wyjaśniające jak używać systemu tokenów, ponieważ model w ogóle nie zna go ze swojego treningu. Zespół przygotował tabelę z każdym pojedynczym tokenem. Bez tego AI nie miało szans poprawnie używać design tokens Atlassian.

Jak działa mapowanie

W każdej instrukcji komponentu znajduje się sekcja mapująca klasy Tailwind na komponenty Atlassian. Struktura priorytetów wygląda następująco: najpierw Atlassian Design System, potem design tokens, a Tailwind tylko dla brakujących elementów. Jeśli AI widzi span z określonymi klasami Tailwind, ma użyć odpowiedniego importu z biblioteki Atlassian.

Problem z „lozenge” i pytanie o zgodność ze standardami

Atlassian ma komponent o nazwie „lozenge”. Healy przyznaje, że nawet nowi pracownicy pytają co to jest. AI tym bardziej nie wie, dlatego model myśli, że to coś zupełnie innego. W branży ten komponent jest powszechnie znany jako „Badge”, co dodatkowo pogłębia zamieszanie.

Rozwiązanie krótkoterminowe polega na tym, żeby pozwolić AI myśleć w kategoriach Tailwind, ale generować kod Atlassian.

Hall idzie jednak dalej i zadaje fundamentalne pytanie: dlaczego nazywamy to lozenge, skoro branża nie ma takiego komponentu? Albo dlaczego nazywamy nasz prop „appearance” zamiast „variant”? Zespół rozważa zmianę nazewnictwa komponentów na bliższe standardom branżowym. To ułatwiłoby AI pracę bez potrzeby ciągłego tłumaczenia.

Recipes: gotowe bloki kodu dla powtarzalnych elementów

Nie zawsze potrzeba całego szablonu. Czasem użytkownik chce tylko dodać chatbox Rovo do istniejącego prototypu.

Healy opisuje recipes jako fragment kodu z instrukcjami. Użytkownik kopiuje przepis, wkleja do promptu, a AI dodaje element do prototypu. Nie musi rozumieć kodu ani wgrywać screenshotów.

Świadomy wybór: wystarczająco dobre zamiast idealnie dopracowane

Healy mówi wprost o recipes: nie będą idealnie dopasowane do produkcji piksel do piksela, ale będą wystarczająco dobre, żeby oddać wygląd i odczucie. To nie jest kompromis wynikający z ograniczeń, lecz świadoma decyzja projektowa.

Przykłady zastosowań obejmują dark mode (zmiana domyślnego trybu wymaga skomplikowanego kodowania themingu, a recipe załatwia to jednym wklejeniem) oraz chatbox Rovo (interfejs AI Atlassian, gdzie zamiast duplikować cały szablon, użytkownik wkleja recipe i ma działający chatbox).

Kalibracja widzenia komputerowego: technika „printer sheet”

Healy szukał sposobu na poprawienie wyników z 60-70% do jeszcze wyższych. Inspiracja przyszła z nieoczekiwanego miejsca: arkuszy kalibracyjnych drukarek.

Zamiast zgadywać co AI widzi na screenshocie, Healy poprosił model o dodanie ramek ograniczających wokół elementów UI, nazwanie każdego wykrytego elementu i opisanie jak by go promptował. Dodatkowo pytał o szczegóły typograficzne: jaki to rozmiar czcionki, jaka to grubość czcionki. Te pytania pomagały zdiagnozować, dlaczego model ignoruje elementy o słabym kontraście lub źle dobiera typografię.

Odkryte ograniczenia

Obcinanie przy złożonych screenshotach: Elementy w dolnej części bocznej nawigacji były pomijane. Model osiągał limit kontekstu dla przetwarzanych obrazów.
Problem z subtelnymi elementami: Komponent IconTile zawiera małe kafelki z kolorowym tłem i ikoną. AI nie wyłapywało koloru tła, widząc tylko ikonę.
Błędna interpretacja typografii: Model halucynował rozmiar i grubość czcionki patrząc na screenshoty.

Te odkrycia wpłynęły na szkolenia. Healy instruuje teraz użytkowników: przy złożonych screenshotach dziel na mniejsze sekcje, przy IconTile wgrywaj powiększony fragment, alternatywnie użyj Figma MCP dla problematycznych elementów.

Utrzymanie systemu: automatyczne generowanie dokumentacji

Hall opisuje problem, który znają wszystkie duże organizacje. Dokumentacja design systemu istnieje w pięciu miejscach: atlassian.design, atlaskit.atlassian.com, LLMs.txt, MCP, a teraz również prototyping. Każde miejsce miało inną wersję, przy czym co najmniej dwie lub trzy wersje powstały metodą vibe coding.

Kompromis między szczegółowością a tokenami

Pełny plik Elements.txt ma około 5000 linii. Wersja dla Figma Make i Replit to jednak 2000-3000 linii. Hall wyjaśnia powód: wiele z tych opisów jest dość rozwlekłych, co ma swoje zalety, ale wymaga dużo tokenów i kontekstu do wygenerowania.

Świadomie skrócili dokumentację. Pokazują 20-30 komponentów zamiast ponad stu dostępnych w design systemie.

Ustrukturyzowana treść w monorepo

Zespół wprowadził ustrukturyzowane pliki JSON (offerings.json) dla każdego komponentu zawierające:

Opis komponentu w języku zrozumiałym dla LLM, na przykład „zdjęcie profilowe lub reprezentacja użytkownika” zamiast technicznego żargonu
Typy i propsy automatycznie pobierane z kodu
Przykłady specjalnie dla AI: proste, czyste, bez przypadków brzegowych
Wytyczne użycia pokrywające 80% najczęstszych przypadków

Jedno polecenie generuje szablony dla Figma Make i Replit z tego samego źródła. Jeśli zmieni się theming w monorepo, szablon się zepsuje. Ktoś to naprawi, a poprawka automatycznie trafi do wszystkich narzędzi.

Hall podkreśla: dawanie AI wszystkich przypadków użycia prowadzi do halucynacji. Model myśli, że może łączyć dowolne warianty. Dlatego dokumentują tylko 80% przypadków.

MCP w planach

Healy wspomina o przyszłości dokumentacji: docelowo będzie to MCP, gdy tylko będą mogli go podłączyć. Na razie pozostają przy plikach instrukcji. To kolejny krok w ewolucji systemu.

Adopcja na dużą skalę: jak dotrzeć do 11 000 osób

Healy ma doświadczenie w adopcji design systemów. Prezentował na Config 2024 o tym, jak Atlassian wdraża zmiany wizualne, nawigację i dark mode. Zna brutalną prawdę: jeśli to zbudujesz, nie znaczy że przyjdą.

Fundamentalna zmiana myślenia

Hall opisuje przesunięcie w podejściu do adopcji. Stary model opierał się na programach, ludziach, wzmacnianiu kulturowym i przeglądach projektowych. Nowy model? Czy możemy po prostu powiedzieć AI dokładnie czego oczekujemy? Odciąć cały balast i dać absolutne minimum.

Zamiast ludzi i programów postawili na dokumentację i instrukcje. To fundamentalna zmiana.

Wieloformatowa edukacja

Zespół przygotował materiały w różnych formatach: nagrania Loom z przewodnikami wideo, pisemną dokumentację, trzyminutowy przewodnik po interfejsie („ten przycisk robi to, tamten robi tamto”) oraz kurs mistrzowski dla 500 osób w Replit prowadzony krok po kroku.

Healy wyjaśnia logikę takiego przewodnika: wiele osób nie eksploruje na własną rękę. Być może dostali odgórny nakaz używania AI prototypowania, a może nie mają czasu klikać każdy przycisk. Prosty przewodnik w stylu „to robi to, tamto jest ważne, o tamto się nie martw” buduje podstawę.

AI Builders Week

Prezes Atlassian ogłosił tydzień, w którym wszyscy odkładają normalne zadania. Tysiące pracowników uczyło się AI prototypowania. Efekt? Momenty olśnienia. Ludzie odkrywali, że doświadczenie filtrowania niemożliwe do zbudowania w Figma zajmuje pięć minut w Replit.

Slack bot i psychologia prywatnych wiadomości

Healy zauważył wzorzec. Wiadomości na kanałach są ignorowane, natomiast prywatne wiadomości dostają odpowiedzi. Wyjaśnia dlaczego: ludzie niemal czują, że muszą odpowiedzieć. Przy kanałach tego efektu nie ma.

Zbudował bota (najpierw w Cursor w piętnaście minut, potem w Replit z wizualnym dashboardem). Bot wysyła grupowe prywatne wiadomości do nieaktywnych użytkowników z personalizowanym komunikatem. Liderzy design ops mogą dodać czterysta osób i wysłać kampanię. Odpowiedzi były zaskakujące: „nie wiedziałem, że to istnieje”, „przepraszam, byłem zajęty tym i tym”. To informacja zwrotna niemożliwa do zebrania inną drogą.

Rola liderów i zmiana kulturowa

Hall obserwuje efekt wirusowy. Liderzy designu dzielą się prototypami w przeglądach projektowych. Podwładni widzą, że ich szef to robi i zaczynają robić to samo.

Przełom nastąpił, gdy przełożeni wyższego szczebla zaczęli pokazywać na spotkaniach działające, klikalne prototypy zamiast statycznych obrazków. W konsekwencji statyczny design przestał być postrzegany jako wystarczający. Prezentacje z działającymi prototypami generują więcej zaangażowania, a jak zauważa Hall: jeśli przyjdziesz z prototypem, ludzie naprawdę się podekscytują.

Przyszłość: design system natywny dla AI

Healy i Hall patrzą w przyszłość z mieszanką ekscytacji i realizmu.

Obecny stan: posklejane agenty

Healy opisuje rzeczywistość: jeden agent robi jedną rzecz naprawdę dobrze, potem trzeba przełączyć się na innego agenta, który robi inną rzecz naprawdę dobrze. Taki jest dzisiejszy model. Agenci są posklejani, każdy wykonuje jedną funkcję.

Przyszłość to rozwiązanie kompleksowe, ale Healy przyznaje: nie wie jaki to będzie tool. Nie wie czy będzie to rozwiązanie zewnętrzne czy wewnętrzne.

Proaktywne podejście

Zamiast czekać, Healy pyta: co możemy zrobić dzisiaj, żeby przyspieszyć nadejście przyszłości? Jakich agentów możemy stworzyć? Jakie narzędzia możemy uruchomić? Jaki kontekst możemy przygotować? I dodaje: jak możemy sprawić, żeby nasz własny zespół stał się natywny dla AI?

Wyzwanie: warstwy systemów poza design systemem

Hall przedstawia skalę problemu poprzez konkretne liczby. Design system to około 75 pakietów kodu. Natomiast pełne środowisko front-endowe niezbędne do wdrożenia kodu na produkcję w Jira to blisko 5000 pakietów.

Oznacza to, że o ile łatwo jest stworzyć wizualnie poprawny prototyp, o tyle automatyczne wdrażanie kodu produkcyjnego przez AI wymaga nauczenia modelu kontekstu tysięcy pozostałych bibliotek, testów i standardów. Żeby AI mogło naprawdę budować w Jira, musi znać systemy drugiej i trzeciej warstwy: jak pisać testy, jak używać ich wersji CSS-in-JS (compiled), bibliotekę internationalization specyficzną dla Jira. Hall przyznaje: nawet on jako inżynier nie wie jak pracować w Jira.

To ogromna ilość kontekstu do udokumentowania.

„Każdy może dostarczać” jako nowy paradygmat

Healy definiuje zmianę. Tradycyjnie: wymagania, potem design w Figma, potem inżynier czyta design, potem inżynier buduje. Teraz: ktokolwiek z dowolnym narzędziem może potencjalnie dostarczyć produkt do klienta.

To przerażające pytanie dla wielu ludzi, jak ujmuje to Hall. Ale też kierunek, w którym zmierza branża.

Cel pięcioletni

Hall definiuje wizję: czy możemy dać każdemu możliwość przynajmniej otwarcia pull requesta, uzyskania review od innych programistów, review od klientów i eksperymentowania w produkcji? Niektórzy designerzy Atlassian już dostarczają kod do mniejszych aplikacji. Droga jest długa, ale kierunek jasny.

Design system jest rdzeniem organizacji działającej naprawdę z dużą prędkością. Zakres odpowiedzialności design systemu eksplodował. Zespół musi budować więcej narzędzi, lintingu, wszystkiego, żeby wspierać nowy typ użytkownika.

Checklist: Przygotowanie design systemu do AI prototypowania

Dokumentacja i instrukcje:

Zidentyfikuj elementy, które AI konsekwentnie halucynuje (nawigacja, ikony, logo)
Stwórz wstępnie zakodowane szablony dla tych elementów zamiast polegać na instrukcjach
Dodaj sekcję mapującą popularny framework (Tailwind) na własne komponenty
Stwórz tabelę z każdym design token, ponieważ AI nie zna ich z treningu
Ogranicz dokumentację do 80% przypadków użycia i 20-30 kluczowych komponentów
Stwórz osobne, uproszczone przykłady specjalnie dla AI
Rozważ zmianę nazewnictwa komponentów na bliższe standardom branżowym

Recipes i narzędzia:

Zidentyfikuj powtarzalne elementy (chatbox, dark mode, modale)
Przygotuj recipes: fragment kodu plus instrukcje do wklejenia
Dodaj kopiowalne komendy dla typowych halucynacji
Zaakceptuj podejście „wystarczająco dobre zamiast idealnie dopracowane” jako świadomy wybór

Testowanie i utrzymanie:

Przetestuj dokładność jednego promptu na prostych i złożonych screenshotach
Użyj techniki „printer sheet”: poproś AI o ramki ograniczające i nazwy elementów
Przeprowadź testy na arkuszach kalibracyjnych, aby zrozumieć jak AI interpretuje granice elementów
Stwórz jedno źródło prawdy dla dokumentacji AI (offerings.json)
Zautomatyzuj generowanie wytycznych z jednego źródła
Umieść szablony w monorepo, żeby zmiany wymuszały aktualizacje
Planuj przejście na MCP gdy będzie dostępne

Zadania wizualne:

Instruuj użytkowników, by wgrywali mniejsze wycinki ekranu zamiast całych widoków
Przy złożonych obrazach AI gubi detale, więc dzielenie zadań zwiększa dokładność

Checklist: Adopcja AI prototypowania na dużą skalę

Materiały i dystrybucja:

Przygotuj treści w różnych formatach (wideo, tekst, sesje na żywo)
Stwórz krótki przewodnik po interfejsie (3-5 minut) w stylu „ten przycisk robi to, tamten nie jest ważny”
Rozważ dedykowany tydzień AI z odgórnym wsparciem kierownictwa
Zbuduj mechanizm personalizowanego docierania (prywatne wiadomości zamiast kanałów, bo ludzie czują że muszą odpowiedzieć)

Zaangażowanie i informacja zwrotna:

Zachęć liderów do pokazywania własnych prototypów w przeglądach projektowych
Zbieraj informację zwrotną od nieaktywnych użytkowników przez personalizowane wiadomości
Dokumentuj historie sukcesu i momenty olśnienia
Wykorzystaj efekt wow: interaktywne prototypy generują więcej zaangażowania niż statyczne ekrany

Zmiana sposobu myślenia:

Przenieś fokus z programów i ludzi na dokumentację i instrukcje
Zaakceptuj, że wystarczająco dobre dzisiaj wygrywa z idealnym za rok
Stwórz kulturową presję, w której statyczny design przestaje być wystarczający

Biblioteka promptów z rozmowy

Poniższe prompty to wybrane przykłady z podcastu. Nie stanowią pełnej biblioteki Atlassian, ale ilustrują podejście zespołu.

Prompt do kalibracji widzenia komputerowego („printer sheet”)

I want to calibrate your computer vision model. Can you add the image in and then create bounding boxes? Tell me what font size this is. Tell me what font weight this is.

Kiedy stosować: Gdy chcesz zrozumieć jak AI widzi Twoje screenshoty. Pozwala odkryć które elementy są pomijane, źle interpretowane lub obcinane przy złożonych obrazach.

Rozszerzenie: Po wygenerowaniu ramek ograniczających poproś dodatkowo o nazwanie każdego elementu i opisanie jak AI by go promptowało. To ujawnia rozbieżności między Twoim mentalnym modelem a interpretacją AI. Healy używał tego promptu do diagnozowania, dlaczego model ignoruje elementy o słabym kontraście lub źle dobiera typografię.

Prompt hierarchii ważności

Use Atlassian design system first, use design tokens first, and then use Tailwind for missing things.

Kiedy stosować: Na samym początku instrukcji systemowych. Ustawia priorytety dla modelu, zapobiegając sytuacji, w której AI idzie na skróty używając czystego CSS zamiast firmowych tokenów.

Kontekst: Ten prompt jest kluczowy dla utrzymania spójności z design systemem. Bez jasnej hierarchii model często wybiera najprostszą ścieżkę, czyli standardowe klasy Tailwind, pomijając własne komponenty organizacji.

Prompt „Tłumacz” (Translation Layer)

If you see these class names [Tailwind], it should actually be this React code [Atlassian Component].

Kiedy stosować: W plikach konfiguracyjnych. To kluczowa instrukcja pozwalająca AI mapować ogólnodostępną wiedzę na specyficzne komponenty firmy.

Kontekst: Komunikat dla modelu brzmi: „Jeśli widzisz te klasy Tailwind CSS, użyj tego konkretnego komponentu React z naszej biblioteki”. Dzięki temu model operuje na znanych mu wzorcach, a wynik pozostaje zgodny ze standardami firmy.

Podstawowy prompt ze screenshotem

Build this screenshot

Kiedy stosować: Podstawowy prompt do replikowania istniejącego UI. Działa najlepiej z prostymi layoutami.

Ograniczenia: Przy złożonych screenshotach AI obcina elementy (szczególnie dolne części bocznej nawigacji). Healy zaleca dzielenie złożonych screenshotów na mniejsze sekcje: na przykład „lewa górna część nawigacji bocznej” zamiast całego ekranu.

Doświadczenie filtrowania

Build this filtering sequence

Kiedy stosować: Do tworzenia interaktywnych sekwencji filtrowania. Healy podaje to jako przykład przewagi AI prototypowania, ponieważ coś niemożliwego do zbudowania w Figma zajmuje pięć minut w Replit.

Kontekst: Ten typ promptu pokazuje wartość AI prototypowania dla interakcji, które w statycznych narzędziach wymagałyby dziesiątek ramek lub były niemożliwe do zasymulowania.

Vibe coding dokumentacji

Build a button section
Build a lozenge section
Build the token section. Here's the file.

Kiedy stosować: Do generowania sekcji dokumentacji design systemu dla AI. Hall przyznaje, że około 90% ich pliku Elements.txt (5000 linii) zostało wygenerowane w ten sposób.

Uwaga: Wyniki wymagają weryfikacji przez inżyniera. Hall wspomina o halucynacjach, rozbieżnościach i sprzecznościach w pierwszych wersjach. Vibe coding to punkt startowy, nie produkt końcowy.

Prompt, którego należy unikać

Change logo to Jira

Dlaczego nie działa: AI sięga do wiedzy z treningu i wstawia stare logo Jira zamiast aktualnego. Healy wyraźnie ostrzega przed tym podejściem.

Alternatywa: Zespół Atlassian stworzył kopiowalne komendy i obiekt konfiguracyjny ze stałymi (zakodowane na twardo wartości dla logo i ikon). Zamiast prosić AI o zmianę logo, użytkownicy kopiują przygotowaną komendę, która podmienia wartość w konfiguracji.

Ogólna lekcja: Unikaj promptów odwołujących się do brandingu, logo i elementów, które zmieniły się od czasu treningu modelu. Lepiej wstępnie zakodować te elementy lub używać konfiguracji.

Kluczowe insighty

Insight 1: Dostosuj system do AI, nie AI do systemu

Standardowo myślimy: Trzeba napisać więcej dokumentacji, lepsze instrukcje i przykłady, żeby nauczyć AI naszego design systemu. To AI musi się dostosować do nas.

W praktyce okazuje się, że: Łatwiej zmienić nazewnictwo własnych komponentów na zgodne ze standardami branżowymi niż walczyć z wiedzą modelu wyniesioną z treningu. Hall pyta wprost: dlaczego nazywamy to lozenge, skoro branża nie ma takiego komponentu? Dlaczego nazywamy nasz prop „appearance” zamiast „variant”? Zespół Atlassian rozważa zmianę własnego systemu, żeby pasował do tego co AI już zna z Tailwind, shadcn i Radix.

Dlaczego to jest istotne: AI trenowano na milionach repozytoriów open source. Twój design system to kropla w oceanie. Walka z wiedzą modelu to walka z wiatrakami. Każda unikalna nazwa komponentu to dodatkowa warstwa tłumaczenia, dodatkowe halucynacje i dodatkowa dokumentacja do utrzymania. Zgodność ze standardami branżowymi działa jak mnożnik efektywności.

Test na jutro: Weź pięć komponentów z własnego design systemu. Sprawdź czy ich nazwy i propsy odpowiadają standardom branżowym (Tailwind, Radix, shadcn). Dla każdego, który odbiega, zadaj pytanie: czy ta unikalna nazwa przynosi wartość większą niż koszt ciągłego tłumaczenia dla AI? Jeśli nie, rozważ refactoring.

Insight 2: Paradoks niepełnej wiedzy

Standardowo myślimy: Aby uzyskać najlepszy i najbardziej precyzyjny kod, musimy dostarczyć AI kompletną dokumentację techniczną zawierającą każdy możliwy wariant komponentu i przypadek brzegowy.

W praktyce okazuje się, że: Pełna dokumentacja drastycznie zwiększa liczbę błędów. Hall zauważył, że model mając dostęp do wszystkich rzadkich wariantów i typów, zaczyna je „halucynować” – próbuje łączyć niekompatybilne cechy, tworząc hybrydy, które nie istnieją w systemie. Usunięcie z instrukcji rzadkich przypadków i pozostawienie tylko 80% najpopularniejszych wariantów paradoksalnie zwiększyło poprawność generowanego kodu.

Dlaczego to jest istotne: To zmienia podejście do przygotowania danych dla AI. Jakość wyników zależy nie od objętości wiedzy, ale od celowego ukrywania przed modelem złożoności, której w typowym scenariuszu nie potrzebuje.

Test na jutro: Następnym razem gdy tworzysz plik kontekstowy dla LLM (na przykład dokumentację API lub projektu), usuń z niego sekcje „Zaawansowane użycie” i rzadkie parametry. Zostaw tylko ścieżkę optymistyczną (tzw. happy path) i sprawdź, czy model przestanie generować błędny kod, dostarczając w zamian działające rozwiązanie.

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ć. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Dive Club – „The trick to AI prototyping with your design system”