Agentic Design Systems: jak sprawić, by agenci AI naprawdę używali Twojego design systemu

Poniższy tekst stanowi notatki z webinaru Chromatic „Agentic Design Systems in 2026″. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od prelegentów: Brada Frosta (autora Atomic Design), Dominica Nguyen (założyciela Chromatic) oraz Kyle’a Suss (inżyniera DX w Storybook).

TL;DR

Agenci AI nie interpretują kontekstu jak ludzie. Gdy brakuje jasnych wzorców, nie zadają pytań, lecz improwizują — tworzą kod poprawny składniowo, ale niespójny z architekturą.
Skuteczny agentic design system opiera się na dwóch filarach: coverage (co agent może ponownie wykorzystać) oraz validation (co musi respektować).
Storybook MCP dostarcza agentom ustrukturyzowane dane zamiast zmuszać je do przeszukiwania node_modules.
Manifest komponentów ujawnia luki w dokumentacji i API, które trzeba uzupełnić przed wdrożeniem agentów.
Testy przestają być obowiązkiem utrzymaniowym — stają się specyfikacją sterującą kreatywnością AI.
Po raz pierwszy da się obiektywnie zmierzyć ROI design systemu, porównując wydajność agenta z systemem i bez niego.
Figma staje się kontraktem, nie źródłem prawdy. Faktycznym źródłem może być YAML opisujący esencję komponentu.

Problem: dlaczego agenci ignorują design systemy

Dominic Nguyen otworzył spotkanie prostym spostrzeżeniem. Design systemy mają świetne nazwy, solidne komponenty i dokumentację będącą dziełem sztuki. Mimo to agenci generują własne wzorce zamiast używać istniejących.

Brad Frost wskazuje na przyczynę: szwy (seams). To miejsca, gdzie informacja przepływa między systemami. Znane od lat przejście z Figmy do kodu stanowi jeden taki szew. Nowe przejście z kodu do agenta tworzy kolejny. W każdym z nich coś się gubi.

Kruchy kontekst i halucynacje

Agenci nie posiadają ludzkich intencji ani zmysłu estetycznego. Zamiast oceniać wygląd, konsumują kontekst w postaci metadanych i typów. Gdy napotykają luki w dokumentacji, nie zadają pytań wyjaśniających — zaczynają improwizować.

Frost nazywa to „halucynowaniem”. Agent generuje kod, który technicznie działa, ale jest generyczny i oderwany od standardów firmy. Jeżeli dostarczony kontekst jest „kruchy” (flaky), rezultat będzie nieprzewidywalny. W konsekwencji systemy muszą ewoluować: z dokumentów tworzonych dla ludzi w precyzyjne instrukcje czytelne dla maszyn.

Dwa filary: coverage i validation

Dominic Nguyen dzieli strukturę agentic design systems na dwa obszary.

Coverage: co agent może ponownie wykorzystać

Coverage mówi agentom, jakie wzorce istnieją. Obejmuje typy, znormalizowane przykłady oraz przewidywalne reguły kompozycji. Gdy wzorce są niekompletne, agent musi improwizować. Zdaniem Frosta rezultaty tej improwizacji prawie nigdy nie odpowiadają oczekiwaniom.

Kluczowe elementy coverage:

Typy i definicje API komponentów
Stories jako przykłady użycia
Opisy w komentarzach JSDoc
Spójne konwencje nazewnictwa

Entropia w design systemach

Frost zwraca uwagę na zjawisko dotykające nawet dojrzałych bibliotek. Komponenty powstają w różnym czasie, a zespoły organicznie zmieniają standardy kodowania. W rezultacie Accordion stworzony trzy lata temu ma inne konwencje niż Modal z zeszłego miesiąca.

Ta niespójność wewnątrz jednej biblioteki dezorientuje agentów. Widzą różne wzorce i nie wiedzą, który jest aktualny. Dlatego regularne audyty oraz ujednolicanie konwencji stają się ważniejsze niż kiedykolwiek.

Validation: co agent musi respektować

Validation pełni rolę strażnika jakości. Testy muszą przejść, a człowiek musi zatwierdzić rezultat. Nguyen podkreśla, że chodzi tu o kod produkcyjny, nie prototypy.

Frost przyznaje otwarcie, że sam nie lubi testów. Rozumie jednak ich znaczenie. Przez lata zespoły traktowały testy jednostkowe jako checkbox do odhaczenia. Era agentów zmienia tę perspektywę. Testy stają się „sosem”, który pozwala z większą pewnością odpowiedzieć na pytanie: czy to jest dobre?

Testy jako specyfikacja, nie QA

To fundamentalna zmiana perspektywy. Tradycyjnie testy pisano na końcu procesu jako element zapewnienia jakości. W erze AI stają się specyfikacją — briefem dla agenta.

Ponieważ agent nie posiada wyczucia UX, „dobry design” to dla niego wyłącznie taki, który przechodzi walidację techniczną: odpowiedni kontrast, prawidłowa struktura nagłówków, poprawne interakcje. Testy przestają być obowiązkiem utrzymaniowym. Stają się językiem sterującym kreatywnością AI.

Garbage in, garbage out

Frost używa tego określenia wprost. Jeśli button nie działa poprawnie w obszarach, gdzie powinien, człowiek nie ma szans tego wyłapać. Traktuje bowiem design system jako autorytet.

Agent jest jeszcze gorszy. Nie zadaje pytań, tylko kopiuje zepsuty wzorzec i powiela go w całej aplikacji. W konsekwencji jakość design systemu bezpośrednio przekłada się na jakość tego, co generują agenci.

Pętla workflow’u agentowego

Agenci pracują w pętli, a design system to tylko jeden jej element. Nguyen opisuje sekwencję w pięciu krokach:

Referencja — agent odwołuje się do wzorców design systemu
Generowanie — tworzy kod na podstawie dostępnego kontekstu
Testowanie — kod przechodzi testy funkcjonalne, wizualne i dostępności
Iteracja — błędy wracają do agenta jako feedback
Aktualizacja — po zatwierdzeniu przez człowieka zwalidowane komponenty aktualizują design system

Tkankę łączącą te kroki stanowi MCP (Model Context Protocol). Storybook buduje własny serwer MCP, który może wykorzystać każdy projekt ze Storybook.

Demo: Storybook MCP w praktyce

Kyle Suss pokazuje działanie systemu na aplikacji Meal Drop (klon DoorDash).

Ważne zastrzeżenie: Storybook MCP działa obecnie tylko z React. Po zakończeniu fazy eksperymentalnej zespół planuje rozszerzyć wsparcie na inne renderery.

Manifest komponentów: serce systemu

Storybook MCP dodaje endpoint /mcp, który generuje manifest komponentów. To ustrukturyzowane dane zoptymalizowane dla agentów. Zamiast przeszukiwać kod źródłowy w node_modules za pomocą prostych wyszukiwań tekstowych, agent otrzymuje listę komponentów z minimalną metadatą, a szczegółowe API pobiera na żądanie.

HTML viewer manifestu pokazuje konkretne braki. Suss widzi komunikat informujący o brakującym opisie komponentu i sugestię dodania komentarza JSDoc. To diagnostyka, którą trzeba przepracować przed wdrożeniem agentów.

Optymalizacja tokenów

Zespół Storybooka bada wpływ formatowania danych (XML vs JSON vs Markdown) na wydajność modeli. Odpowiednie przygotowanie kontekstu drastycznie redukuje zużycie tokenów, co przekłada się na mniejsze koszty i większą szybkość generowania odpowiedzi. Jest to szczególnie istotne przy skalowaniu procesów w dużych organizacjach.

Agent w akcji

Suss wydaje polecenie agentowi, prosząc o stworzenie komponentu recenzji klientów z awatarem, imieniem, oceną gwiazdkową i tekstem.

Agent wykonuje sekwencję:

Pobiera listę komponentów z UI package
Żąda szczegółów o Stars i Typography
Tworzy komponenty Review i CustomerReviews
Generuje stories z wariantami (default, single review, high/medium rating)
Podaje linki do stories w Storybook

Frost komentuje w czasie rzeczywistym, że to dokładnie to, co zrobiłby developer.

Agent przejmuje konwencje projektu

Ciekawy szczegół: agent nie zakodował danych recenzji na stałe. Zamiast tego stworzył mock data, bo Meal Drop konsekwentnie używa mocków w całym projekcie.

Suss wyjaśnia, że Jan (twórca Meal Drop) używa mocków rygorystycznie i spójnie. Agent to zauważył i dostosował się do konwencji projektu. To przykład pozytywnego zachowania, gdy struktura jest czytelna.

Open in editor

Jan dodał też możliwość kliknięcia na story i otwarcia jej bezpośrednio w VS Code. Drobna funkcja, ale przyspiesza iterację między Storybook a edytorem.

Gdy agent improwizuje

Suss pokazuje też ciemną stronę. Agent tworzy formularz recenzji z polem tekstowym. Problem polega na tym, że w design systemie istnieje TextInput, ale nie ma TextArea.

Agent improwizuje i tworzy własne pole. Wynik? Pole nie spełnia standardów dostępności — kontrast jest niewystarczający.

Frost podkreśla lekcję: komponenty zbudowane zgodnie z best practices nie gwarantują dostępnego produktu. Liczy się kompozycja, a ta zasada dotyczy zarówno ludzi, jak i agentów.

Testy jako walidacja

Storybook uruchamia testy komponentowe w prawdziwej przeglądarce (Playwright + vitest). To najbliższe symulacji rzeczywistego użytkownika.

Suss wyjaśnia różnicę: agenci potrafią uruchamiać testy jednostkowe w CLI. Jednak jeśli chcemy symulować prawdziwe zachowanie użytkownika, musimy renderować komponenty w przeglądarce.

Testy wykrywają konkretne problemy:

Błędy interakcji (np. brak play function)
Problemy z dostępnością (4 błędy Axe w demo)
Nieprawidłowa kolejność nagłówków (h4 zamiast h2)
Niewystarczający kontrast w improwizowanych komponentach

Self-healing loop jako cel

Zespół Storybook buduje trzeci toolset: testing. Ambicja sięga jednak dalej.

Suss opisuje docelową wizję: samonaprawiającą się pętlę. Agent nie tylko generuje kod używając komponentów design systemu, ale też uruchamia testy. Gdy test nie przechodzi, iteruje samodzielnie. Człowiek wchodzi dopiero, gdy wszystko jest gotowe.

To przesunięcie odpowiedzialności: agent robi maksimum pracy, zanim zajmie czas człowieka.

Od vibe coding do vibe engineering

Frost widzi w tym demokratyzację tworzenia UI.

Tradycyjnie developerzy siedzieli na końcu wodospadu. Nawet w agile workflow handoff designer–developer pozostawał bolesny. Teraz scenariusz wygląda inaczej: spotkanie z interesariuszami, head of sales mówi czego potrzebuje, Suss wydaje polecenie, komponent powstaje na żywo, wszyscy widzą rezultat w Storybook.

To nie są obrazki UI, lecz działający kod. Head of sales staje się efektywnie „mouth coderem” — osobą kodującą ustami.

Suss nazywa to przejściem od vibe coding do vibe engineering. Różnica polega na rygorystycznej weryfikacji pracy i człowieku w pętli. W vibe coding ludzie często nie patrzą nawet na kod źródłowy. Z kolei w vibe engineering Storybook pokazuje wizualny output każdej zmiany.

Dla inżynierów to też ulga. Eric z Chromatic dodaje, że w starym świecie reviewer dostawał kod, który „jakoś wyglądał”, ale był zepsuty na wiele sposobów. Teraz agent z design systemem dostarcza kod znacznie bliższy produkcji, niezależnie kto uruchomił polecenie.

Neuroplastyczność struktur organizacyjnych

Frost używa mocnej metafory podsumowującej tę część dyskusji. Mówi o „neuroplastyczności struktur organizacyjnych”. Pociąg wyskoczył z torów i teraz trzeba zdecydować, jak chcemy pracować od tej pory.

To brzmi abstrakcyjnie, ale ma praktyczne implikacje. Role się zacierają. Designerzy mogą wydawać polecenia i widzieć działający kod. Developerzy przestają być ostatnim ogniwem łańcucha. W rezultacie organizacje muszą przemyśleć, kto za co odpowiada.

Figma jako kontrakt, nie źródło prawdy

Frost ma niuansowy pogląd na rolę Figmy w erze agentów.

Komponenty w bibliotece Figma to tak naprawdę kontrakt — obietnica, że dany komponent istnieje w kodzie. Gdy designer przeciąga button na canvas, komunikuje: tutaj chcę, żeby developer użył buttona z design systemu.

Figma pozostaje użyteczna jako proxy, szczególnie gdy jeden design system obsługuje wiele platform (web, iOS, Android). Nie jest jednak źródłem prawdy dla agentów.

YAML jako źródło prawdy dla multi-platform

Frost opisuje podejście stosowane z klientami wspierającymi wiele technologii. Źródłem prawdy stają się pliki YAML i Markdown z front matter. Opisują esencję komponentu: jego wymagania, warianty, API.

Agenci potrafią wtedy wygenerować ten sam komponent jako web component, bibliotekę React, bibliotekę iOS lub Android. Każda implementacja podąża za konwencjami danej platformy.

To odwrócenie tradycyjnego podejścia. Zamiast implementacji jako źródła prawdy, źródłem staje się abstrakcyjny opis tego, czym komponent jest.

Ewaluacje: jak mierzyć wpływ design systemu

Nguyen wprowadza koncept Storybook Evals — benchmark design systemu przeciwko zestawowi testowych promptów.

Niedeterministyczna natura AI

Nguyen zaznacza fundamentalną zmianę paradygmatu. Design systemy były deterministyczne: ten sam input dawał ten sam output. Agenci tak nie działają.

Uruchom ten sam prompt 100 razy, a dostaniesz różne rezultaty. Trzeba się z tym pogodzić. Dlatego ewaluacje mierzą trendy i rozkłady, nie pojedyncze wyniki.

Wykrywanie dryfu

Systemy ulegają degradacji w czasie — to naturalna entropia. Ewaluacje działają jak mechanizm obserwowalności znany z DevOps. Alarmują zespół, gdy jakość odpowiedzi agenta spada po aktualizacjach biblioteki lub zmianie modelu.

Bez tego mechanizmu zespół dowiaduje się o problemach dopiero od użytkowników. Z ewaluacjami widzi je w momencie, gdy powstają.

Cztery wymiary ewaluacji

Ewaluacje mierzą cztery wymiary:

Jakość — zgodność kodu z wzorcami i standardami
Koszt — zużycie tokenów na zadanie
Szybkość — czas wykonania promptu
Conformance — procent ponownie użytych komponentów względem improwizacji

Stare porzekadło „good, cheap, fast — pick two” nadal obowiązuje. Optymalizacja pod jakość podnosi koszty, natomiast optymalizacja pod szybkość obniża jakość. Każdy projekt musi znaleźć własne kompromisy.

Zespół Chromatic przebadał kilkanaście design systemów. Wniosek: więcej kontekstu nie zawsze znaczy lepiej. Format danych (XML vs markdown vs JSON) wpływa na szybkość i zużycie tokenów.

Kwantyfikacja ROI

Po raz pierwszy można obiektywnie zmierzyć wpływ design systemu. Agent z design systemem vs agent bez — to naturalny wskaźnik zastępczy dla efektywności ludzi.

Dotąd ROI design systemów opierał się na subiektywnych metrykach typu adopcja. Teraz możliwe staje się porównanie twardych danych: jak radzi sobie agent z podłączonym design systemem (szybciej, mniej zużytych tokenów, lepsza jakość kodu) w zestawieniu z agentem bez takiego wsparcia. Teoretyczne rozważania ustępują konkretnym liczbom.

Przyszłość: generatywne UI

Pytanie z Q&A: czy UI będzie generowane na żądanie użytkownika?

Frost odpowiada twierdząco i podaje przykład. Salesforce Agent Force używa Lightning Design System do tworzenia interfejsów w czasie rzeczywistym. Zamiast dashboardu z „17 warstwami mega menu”, sprzedawca mówi czego potrzebuje, a UI powstaje na miejscu.

Chatboty to kiepski interfejs dla większości zadań. Generatywne UI stanowi następny krok. Pozostaje jednak pytanie: czy to jest dobre?

Design system staje się systemem ograniczeń dla generacji. Bez niego agent tworzy bałagan. Z nim — interfejs zgodny ze standardami organizacji.

Kumulacja, nie zastępowanie

Frost podsumowuje: email nie umarł, gdy pojawiły się komunikatory. Interfejsy głosowe nie zastąpiły ekranów. Alexa i Siri istnieją obok tradycyjnych UI.

Nowe możliwości się kumulują. Będą stare interfejsy i nowe, statyczne i generowane na żądanie. Odpowiedzialność zespołów design systemów rośnie, bo muszą obsłużyć wszystkie te scenariusze.

Checklista: gotowość design systemu na agentów

Coverage

Każdy komponent ma opis w komentarzu JSDoc
Propsy mają typy TypeScript (nie any) i opisy
Stories pokazują realne przypadki użycia z args/controls
Stories zawierają play functions dla elementów interaktywnych
Konwencje nazewnictwa są spójne w całej bibliotece
Starsze komponenty są zaudytowane pod kątem aktualnych standardów
Brakujące wzorce są zidentyfikowane i udokumentowane
Mock data są ustandaryzowane i realistyczne

Validation

Testy funkcjonalne uruchamiane w przeglądarce (nie tylko jednostkowe)
Testy wizualne (Chromatic lub podobne)
Testy dostępności (Axe)
Testy interakcji (play functions w stories)
Pipeline CI/CD blokujący merge przy niepowodzeniach

Workflow

Storybook MCP skonfigurowany i dostępny
Manifest komponentów bez błędów typu „missing description”
Proces review zmian wizualnych przed mergem
Ewaluacje dla kluczowych promptów (opcjonalnie)
Spójne konwencje mockowania danych w projekcie

Prompty z demo: kiedy je stosować

Suss użył podczas demo czterech promptów ilustrujących różne etapy pracy z agentem i Storybook MCP.

Tworzenie komponentu z wariantami

Add a customer reviews component. It should contain multiple reviews. 
Each review should display an avatar, name, star rating and review text. 
Use placeholder images and friendly content.

Kiedy stosować: Gdy potrzebujesz nowego komponentu z określoną strukturą danych. Prompt zawiera nazwę komponentu, strukturę danych oraz wskazówki dotyczące contentu.

Dlaczego działa: Precyzyjne określenie struktury danych oraz prośba o „placeholder images” zapobiega generowaniu błędnych linków do grafik. Agent automatycznie wykrył i użył istniejących komponentów Typography oraz Stars z design systemu.

Rezultat: Agent stworzył dwa komponenty (Review i CustomerReviews), wygenerował stories z wariantami i użył istniejących komponentów z design systemu.

Tworzenie interaktywnego komponentu

Add a review form component that accepts a star rating and text view.

Kiedy stosować: Gdy testujesz, jak agent radzi sobie z minimalnym kontekstem. Celowo krótki prompt pozwala zobaczyć, czy agent rozpozna potrzebę interaktywności i użyje istniejących komponentów.

Rezultat: Agent stworzył formularz, ale musiał improwizować TextArea, bo nie istniał w design systemie. Improwizowany komponent miał problemy z dostępnością.

Bonus: Ten prompt ujawnił lukę w systemie (brak komponentu TextArea). To skuteczna metoda audytu pokrycia — krótkie prompty wymuszające interakcję szybko pokazują, czego brakuje w bibliotece.

Integracja komponentu ze stroną

Put the customer reviews with form on the restaurant detail page.

Kiedy stosować: Gdy masz gotowe komponenty i chcesz je umieścić w kontekście strony. Prompt wskazuje konkretne komponenty oraz stronę docelową, nie narzuca natomiast szczegółów layoutu.

Rezultat: Agent zaimportował komponenty, umieścił je na stronie, stworzył mock data zgodnie z konwencjami projektu i podał link do story.

Generowanie testów interakcji

Test the interactivity of the form.

Kiedy stosować: Gdy chcesz, by agent sam rozpoznał konwencje testowania w projekcie. Prompt nie wspomina o stories ani play functions, delegując decyzję o metodzie testowania.

Rezultat: Agent sprawdził istniejące wzorce, rozpoznał że projekt używa play functions i wygenerował stories z testami interakcji — bez konieczności instruowania go „jak” ma to zrobić technicznie.

Konfiguracja agenta (agents file)

Use that MCP server and then make sure to create stories.

Kiedy stosować: Jako bazową instrukcję w pliku konfiguracyjnym agenta. Zapewnia, że agent korzysta z MCP zamiast przeszukiwać node_modules oraz że każdy nowy komponent ma stories.

Dodatkowa wskazówka: Suss dodaje też instrukcję blokującą nadmierną ugodowość agenta (sykofancję). Eliminacja zbędnych uprzejmości typu „you’re absolutely right” bezpośrednio przekłada się na oszczędność tokenów i szybszy czas reakcji modelu.

Kurs Brada Frosta

Frost wraz z bratem i TJ Petrie przygotowują kurs o AI i design systemach. Cel: pomóc zespołom nawigować moment przełomu bez poddawania się szumowi medialnemu.

Kurs obejmuje podstawowe koncepcje przetrwające zmiany narzędzi, ROI i argumenty dla leadership, przegląd krajobrazu (Figma, nowe narzędzia) oraz społeczność do wymiany doświadczeń.

Frost podkreśla: nie chodzi o kolejny model czy narzędzie, lecz o trwałe fundamenty.

Definicja design systemu

Frost proponuje definicję zyskującą na znaczeniu w erze agentów:

Design system to oficjalna historia o tym, jak organizacja projektuje i buduje cyfrowe interfejsy.

Ta historia obejmuje standardy UI, biblioteki designu, biblioteki kodu oraz dokumentację. Obejmuje też ludzi i procesy. Jakość na poziomie systemu odblokowuje jakość i efektywność w skali.

Frost kończy pytaniem, które powinno towarzyszyć każdemu wdrożeniu agentów: czy to jest dobre?

Kluczowy insight

Spójność konwencji bije kompletność dokumentacji

Standardowo myślimy: Żeby agent dobrze używał design systemu, trzeba napisać obszerną dokumentację. Im więcej opiszemy, tym lepiej agent zrozumie nasze intencje.

W praktyce okazuje się, że: Agent Sussa nauczył się tworzyć mock data nie z dokumentacji, lecz z konsekwentnego stosowania wzorca w kodzie. Jan używał mocków rygorystycznie w całym Meal Drop. Agent to zauważył i dostosował się. Żadna dokumentacja o mockach nie była potrzebna.

Dlaczego to jest istotne: Agenci uczą się z przykładów, nie z instrukcji. Niespójny kod z doskonałą dokumentacją dezorientuje bardziej niż spójny kod bez dokumentacji. To odwraca priorytet: zamiast pisać więcej dokumentacji, najpierw warto ujednolicić istniejący kod.

Test na jutro: Przejrzyj 5 ostatnich komponentów w swoim design systemie. Czy mają identyczną strukturę plików? Identyczny sposób definiowania propsów? Identyczne konwencje nazewnictwa stories? Jeśli znajdziesz niespójności, napraw je przed dodaniem jakiejkolwiek dokumentacji. Potem uruchom ten sam prompt na obu wersjach i porównaj rezultaty.

Ten wpis stanowi część 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ć. Oryginalne źródło: webinar Chromatic „Agentic Design Systems in 2026 with Brad Frost” (nagranie dostępne dla zarejestrowanych uczestników na chromatic.com).