TL;DR

40% planowania, 10% kodowania, 40% review – nowy podział czasu w AI-assisted development, gdzie faktyczne pisanie kodu to margines
Zarządzanie kontekstem to fundament skutecznej pracy z AI – folder .agent z plikami .rules i scratchpad, szczegółowe specyfikacje i wymuszanie skanowania codebase przed działaniem
AI-friendly codebase wymaga regularnych refaktoryzacji, dokumentacji w plikach i małych, zagnieżdżonych struktur
Koszt narzędzi AI: $300-500/miesiąc – ułamek kosztów tradycyjnego developmentu przy znacznie większej prędkości
GPT-5 oferuje najlepszy stosunek ceny do jakości – $1 za milion tokenów przy wysokiej wydajności
Storybook MCP redukuje token usage o 45% i przyspiesza generowanie kodu o 200% przez lepsze zarządzanie kontekstem
Human in the loop to klucz – monitorowanie diff’ów i rozumienie zmian w codebase, nie pasywne czekanie

Uwaga: Ten wpis to notatki z webinaru „Rapid Frontend Prototyping with Cursor & Storybook”, który poprowadzili Dominic Soellner (założyciel Chromatic, firmy stojącej za Storybook) i Kevin Lenaway (Principal Software AI Engineer w Pioneer Square Labs). Wszystkie przemyślenia, obserwacje i strategie opisane poniżej pochodzą bezpośrednio od prelegentów.

O czym mówimy, gdy mówimy o szybkości

Dominic rozpoczyna od fundamentalnej obserwacji: szybkość ma znaczenie. Całe value proposition AI polega na skróceniu czasu między pomysłem a działaniem w rozwoju aplikacji.

W wyścigu o rozwój aplikacji masz trzy opcje: ship fast, ship smart, lub cut corners. Ponieważ 90% pomysłów i tak ląduje w koszu, o wiele łatwiej jest po prostu działać szybko.

Kevin jest żywym dowodem skuteczności tego podejścia. Przez osiem lat w Pioneer Square Labs pracował nad około 50 pomysłami, z czego większość się nie powiodła. Jednak sześć otrzymało finansowanie venture capital, w tym Recurrent (battery health, $20M funding) i Single File (AI compliance, $24M funding). Kilka zostało przejętych.

Pioneer Square Labs to venture studio, które profesjonalnie zajmuje się budowaniem startupów szybko. Kevin musi znaleźć balans: prototyp musi powstać ekspresowo, żeby testować z użytkownikami, ale jednocześnie te 10% projektów, które się sprawdzą, potrzebują solidnego fundamentu, żeby nie tracić czasu na re-platforming później.

Dwie ścieżki AI w kodowaniu – która prowadzi do sukcesu?

Dominic dzieli współczesne podejścia do przyspieszania developmentu na dwie kategorie.

Po pierwsze mamy AI-assisted coding – narzędzia takie jak Cursor, Windsurf, Codecs czy Claude Code. Piszesz kod, jednak AI ci pomaga. To wciąż inżynieria oprogramowania wymagająca dyscypliny.

Po drugie jest vibe coding – Lovable, Bolt, Replit, V0. Próbują wygenerować całą aplikację na podstawie ogólnego opisu (vibes). Generujesz gotowe rozwiązania z promptu.

Dlaczego ten webinar skupia się na pierwszej kategorii? Według Dominica, mimo że AI pisze Twój kod, nadal uprawiasz software engineering. A to profesjonalna dyscyplina z własnymi wymogami: maintenance, jakość, wydajność, bezpieczeństwo, całkowity koszt posiadania.

Dla tych 10% projektów, które faktycznie odniosą sukces, solidny fundament kodu oparty na zasadach software engineering pomaga dotrzeć do następnego milestone’u.

Frontend to nie backend – rola przeglądarki

Dominic zwraca uwagę na coś, co łatwo przeoczyć. Front end development różni się fundamentalnie od reszty stacku.

Cały kod jest intermediowany przez przeglądarkę. Source code nie jest one-to-one z rendered code, który widzą użytkownicy, dlatego workflow LLM dla backendu nie działa dla frontendu.

Problem: Same narzędzia IDE skoncentrowane na kodzie (jak sam Cursor) nie wystarczą. Nie da się łatwo odgadnąć renderowania, patrząc tylko na kod React.

Problem: Weryfikacja wizualna w standardowej aplikacji jest wąskim gardłem. Wymaga uruchomienia całej aplikacji, bazy danych i ręcznego przeklikiwania różnych stanów interfejsu.

Cursor niedawno wprowadził browser awareness, co jest ekscytujące. Kevin pokazuje to w demo, jednak ma to podobny speed profile jak end-to-end testing – musisz uruchomić całą aplikację, bazę danych, wszystko. Tak, jest zautomatyzowane, ale fizycznie nadal wolne.

Rozwiązanie: Storybook daje ustrukturyzowany widok skompilowanych komponentów i ich stanów w izolacji. Umożliwia to natychmiastą wizualną weryfikację, czy kod wygenerowany przez AI renderuje się poprawnie.

W rezultacie, Storybook to naturalne połączenie dla AI-assisted coding workflow, bo pozwala wizualnie zweryfikować, że output LLM jest wystarczająco dobry i drastycznie przyspiesza pętlę zwrotną.

Rewolucyjna proporcja 40-10-40

Kevin przedstawia model pracy, który całkowicie zmienia sposób myślenia o kodowaniu z AI.

Tradycyjnie developer spędzał większość czasu na pisaniu kodu. Teraz ten czas rozdziela się zupełnie inaczej:

40% na specyfikację i planowanie
10% na faktyczne kodowanie (które wykonuje AI)
40% na przegląd i weryfikację

To nie jest arbitralna proporcja. Kevin podkreśla, że im więcej czasu poświęcisz na początku na szczegółowe rozpisanie tego, co ma powstać, tym lepszy output otrzymasz od AI.

Strukturyzowane podejście z listami tasków i detalicznymi specyfikacjami daje znacznie lepsze rezultaty niż minimalistyczne promptowanie. Kevin używa na to określenia: „night and day difference”.

Z jego doświadczenia wynika, że możesz spędzić cztery godziny na przygotowanie specyfikacji. To nie jest dobry materiał na webinar czy wideo, ale to rzeczywistość production coding.

Kevin zauważa, że rozmawiając z różnymi developerami słyszy skrajnie różne opinie o AI. Jedni mówią „jestem 10x szybszy”, inni „co ty w ogóle gadasz, to w ogóle nie działa”. Gdy zagłębiasz się w szczegóły, największa różnica polega na tym, że musisz over-specify i spędzić dużo czasu upfront, zamiast wpisać kilka zdań, zobaczyć co wyjdzie i być rozczarowanym.

Najlepsza rada według Kevina? Przesuń swój czas – 40% na specyfikację, 40% na review. Pozwól agentowi zająć się środkową częścią.

Generowanie 150,000 pomysłów startupowych – przykład w akcji

Kevin pokazuje praktyczny przykład swojego workflow. Kilka tygodni przed webinarem chciał wygenerować 10-20 dobrych pomysłów startupowych. Podszedł do tego systematycznie: stworzył 150,000 pomysłów używając AI, a następnie użył podejścia opartego na rubryce, żeby zawęzić to do 20 absolutnie najlepszych pomysłów z całej przestrzeni poszukiwań.

Kryterium? Quick side project type things. Z egoistycznego punktu widzenia byłoby wspaniale mieć mały startup generujący $5k rocznie, który robi jedną bardzo specyficzną niszową rzecz i nie wymaga dużo czasu na wsparcie czy utrzymanie.

Na potrzeby demo losuje jeden z tych pomysłów – subcontractor invoice tool. Niszowa aplikacja dla podwykonawców do porównywania estimates z actual spend.

Kevin bierze ten pomysł, wkleja go do ChatGPT i używa swojego prompta do wygenerowania task listy dla AI agenta. Ma to już wcześniej przygotowane dla wszystkich 20 pomysłów, żeby zaoszczędzić czas podczas webinaru.

W ciągu około 10 minut powstał działający prototyp z pełnym interfejsem użytkownika.

Folder .agent – centrala zarządzania kontekstem

Kevin używa strukturyzowanego podejścia do organizacji informacji dla AI. W swoich projektach tworzy folder .agent, który zawiera:

Plik .rules – zasady kodowania specyficzne dla projektu:

Konwencje nazewnictwa
Ścieżki do plików
Preferencje architektoniczne
Standardy formatowania

Scratchpad – notatnik dla agenta:

Miejsce na zapisywanie postępów
Lista istotnych plików do zadania
Notatki o kontekście projektu

Epiki – wysokopoziomowe cele projektu i wizja końcowego produktu

Implementation guides – ekstremalnie szczegółowe taski dla AI z instrukcjami krok po kroku

Dokumentację – skopiowane docs nowych technologii, których AI jeszcze nie zna (np. GPT-5), referencje do API i best practices

Pokazuje przykład: projekt aplikacji desktopowej w Rust z React UI. Folder .agent zawiera wszystkie zmiany, jakie AI dokonało, szczegółowe instrukcje dla każdego zadania, a nawet dokumentację GPT-5, którą wkleił ręcznie.

Dlaczego to działa? Bo zamiast każdorazowo tłumaczyć AI kontekst projektu, dostarczasz mu gotowej, zorganizowanej bazy wiedzy.

Kevin mówi agentowi wprost: „Nie dotykaj mojego repo, ale wszystko w tym folderze jest dla ciebie. Możesz użyć tego do śledzenia tego, co robisz.” Ma tam instrukcje dla agenta, logi, przykładowy kod, scratchpad. Agent może nawet usunąć ten folder jeśli chce – to jego przestrzeń.

Kevin przyznaje, że musi stworzyć osobne wideo wyjaśniające tę metodę. To lżejsza wersja tego, co stosuje w prawdziwych projektach, dlatego w produkcyjnym środowisku jego folder .agent to kompleksowa mapa drogowa dla każdego agenta, który dotknie kodu.

Znaczenie zarządzania kontekstem

Dominic pyta wprost: dlaczego to jest pomocne? Chodzi o dodawanie kontekstu przed generowaniem kodu?

Kevin wyjaśnia. Jedną z największych rzeczy, która może zrobić różnicę między slopem, który wyrzucasz, a naprawdę dobrym kodem (95% drogi do celu), jest zarządzanie kontekstem.

Model AI działa z określoną ilością pamięci, mierzoną w tokenach. Token to około 1/3 słowa, zaś nowoczesne modele mają 100,000 do 200,000 tokenów, czyli około 100,000 słów.

Musisz być ostrożny. Jeśli nie wykorzystujesz tego kontekstu, AI nie będzie wiedziało co robić, nie będzie wiedziało wystarczająco dużo o twoim codebase czy o tym, co próbujesz osiągnąć. I nie powie ci tego – będzie zgadywać.

A naprawdę nie chcesz, żeby zgadywało. Chcesz, żeby robiło dokładnie to, co chcesz, bo gdy zaczyna zgadywać, to koniec.

Chodzi o trzymanie go na torach. Dając mu przestrzeń do zarządzania tym, gdzie jest w procesie, naprawdę pomagasz mu pozostać on track przez dłuższe zadania.

Przykład: scratchpad. Kevin często mówi agentowi: „Idź i zacznij robić to 20-minutowe zadanie, ale chcę, żebyś stale odnosił się do tego scratchpada i dawał mi znać, co robisz.”

I nie tylko daje mu znać. Za każdym razem, gdy wraca żeby zapisać, czyta to i pamięta gdzie jest. To kwestia trzymania prawdziwych tasków w kontekście, w przeciwnym razie powiesz to na początku i agent zapomni. Zabraknie miejsca. Jest tyle śmieci, że nie wie co jest ważne.

Stale próbujesz trzymać to, co ważne, na górze umysłu AI agenta.

Jak zmusić AI do myślenia przed działaniem

Jeden z najważniejszych tricków Kevina dotyczy zarządzania kontekstem w czasie rzeczywistym.

Dodaje do swojego start promptu instrukcję: „Zanim wykonasz jakąkolwiek pracę, przejdź przez codebase. Znajdź wszystkie pliki, które mogą być istotne dla tego zadania. Nie pisz żadnego kodu, dopóki tego nie zrobisz.”

Ale to nie koniec. Kevin każe AI wypisać swoją pracę, bo chce widzieć w scratchpadzie, jakie pliki agent uważa za najważniejsze.

To jak sprawdzanie pracy domowej u dziecka. Nie chcesz, żeby zgadywało – chcesz widzieć tok rozumowania.

Dopiero po tym, jak przejrzysz listę i ją zaaprobowałeś, pozwalasz agentowi przejść do kodowania.

To technika dwóch promptów. Pierwszy prompt to context setting – zmuszasz AI do skanowania, zaś drugi to Twoja weryfikacja: „Tak, jesteś na dobrym tropie”.

Nowoczesne narzędzia są całkiem dobre w crawlowaniu codebase i rozumieniu, gdzie co się znajduje. Widzą importy, sprawdzają parent files, jednak bez jawnej instrukcji mogą pominąć istotne fragmenty.

Atomic Design – system przyjazny dla AI

Kevin używa Atomic Design System i ma ku temu konkretne powody.

Koncepcja jest prosta: zaczynasz od małych komponentów. Atom to może być text box lub button, następnie budujesz je razem w organizmy – np. button + text box = część formularza do submitu imienia. Potem page – cały formularz z nazwą, adresem, numerem telefonu i przyciskiem submit na dole.

Co jest super w tym podejściu? Często, gdy idziesz do ChatGPT, wygeneruje ci kupę powtarzającego się kodu albo zrobi wszystko w HTML jako wielki bałagan. Popychając go w stronę design systemu (użyj dowolnego, ale użyj jakiegoś), AI jest naprawdę dobre w reużywaniu komponentów i składaniu ich w sposób production-level, zamiast kopiować-wklejać i rozrzucać random buttony, teksty i style wszędzie.

Dominic pyta: czy to jedyna referencja, którą dajesz agentowi dla atomic design, czy dostarczasz markdown z dokumentacją?

Kevin wyjaśnia: Atomic Design jest wystarczająco dobrze znane, więc nie musi dawać guidance. Ale jeśli masz własny, szczególnie in-house design system, tak, musisz dać guidance. W końcu skąd AI ma wiedzieć?

Dobry sposób? Zrób snapshot swojego codebase, wyślij do LLM i powiedz: „Daj mi instrukcje do promptowania AI, żeby tworzyło komponenty używając mojego design systemu.” Dostaniesz pierwszy draft. Kevin przyznaje: jestem leniwy, więc używam tego podejścia.

Wybór narzędzi „przyjaznych AI”

Kevin podkreśla kluczową praktyczną zasadę: celowo używa narzędzi „przyjaznych AI”. Oznacza to technologie, które są dobrze znane modelom i istnieją w ich danych treningowych.

Jak sam przyznaje, jego szablon startowy używa celowo nieco starszej wersji Storybook. Dlaczego? Bo nowsze funkcje mogą jeszcze nie być znane AI (według stanu wiedzy z września 2024), co prowadziłoby do błędów, halucynacji i frustracji.

To całkowicie odwraca tradycyjne priorytety przy wyborze stacku technologicznego. Zamiast automatycznie sięgać po najnowsze wersje (bleeding-edge), stabilność i „znajomość” przez AI stają się ważniejsze niż dostęp do najnowszych, eksperymentalnych funkcji.

Starter template – AI-friendly od początku

Kevin stworzył starter template pełen AI-friendly narzędzi. Storybook jest jednym z nich – dostaniesz Storybook setup out of the box.

Tu Kevin mówi do Dominica: „Zakryj uszy.” Używa nieco starszej wersji Storybook. Częściowo bo jest leniwy, ale głównie celowo, bo nowsze rzeczy po prostu nie są w training data i będziesz walczył z AI, próbując zmusić je do używania nowych rzeczy, które myśli, że robi prawidłowo… według stanu z września 2024.

Dominic od razu wskakuje: Storybook team aktywnie pracuje nad naprawieniem tego problemu. Dostarczają MCP server, żeby pomóc LLM znać wszystkie capabilities Storybook. Docs przyjazne dla LLM, markdown jednym klikiem, tego typu rzeczy. To się poprawia.

Kevin jest podekscytowany. To będzie kluczowe, dlatego widzi, że z toolingiem to się coraz bardziej poprawia.

Prompt engineering – sztuka i nauka

Kevin pokazuje swój prompt do kickstartowania zadań agenta. Mówi otwarcie: to trochę sztuka, trochę nauka, trochę rzucanie rzeczy w ścianę i patrzenie co się przyklei. Nie czuj, że musisz robić dokładnie tak – to dobry starting point, który dla niego działa całkiem dobrze.

Podstawy prompta:

„Jesteś świetnym developerem”
„Dostałeś tę task listę”
„Przejdź przez nią, aż skończysz”

Cursor wprowadził fajną rzecz – możesz wstawić common prompts i używać polecenia z ukośnikiem (slash command). Kevin po prostu robi /start-task.

Używa nowego Claude Sonnet 4.5, który jest fajnym modelem. Całkiem szybkim, jednak nie tak dobry jak GPT-5.

Kevin wyjaśnia różnicę między system prompt a user prompt. System prompt to coś, co zawsze tam jest, trochę bardziej ważne, ogólne guidance, informacje, które chcesz podać LLM. User prompt jest bardziej specyficzny: „idź i zrób X”, używając informacji z system prompta do robienia tego w określony sposób.

Best practices według Kevina:

Daj modelowi rolę – jeśli wybierasz rolę, równie dobrze może to być world’s best software engineer, nie mów mu, żeby był drugi najlepszy albo junior engineer
High level information
Bardzo specyficzne zasady

Przykład: ponieważ używamy Storybook, jest to obowiązkowe. Zawsze miej storybook stories. Bądź specyficzny.

Najważniejsza część prompta? Output format. Kevin zaczyna od jednego paragrafu opisującego co agent robi. Nie wystarczy sama checklist, dlatego daj agentowi trochę więcej kontekstu bigger picture, żeby wiedział jak składać kawałki razem.

Storybook stories za darmo – zjadanie brokuła bez wysiłku

Kevin podkreśla coś ważnego o Storybook. Kocha Storybook i dostaje z niego tonę wartości.

Ale jest koszt. Zajmuje czas pisanie stories, jak każde testy. Powinieneś to robić. To trochę jak jedzenie brokuła. „Okej, muszę napisać moje testy, jestem dobrym chłopcem” i wszystko to.

Co jest super fajne z AI? Dostajesz te stories za darmo.

Masz najlepsze z obu światów. Dostajesz piękny, ładny interfejs Storybook i nie musisz spędzać dnia czy dwóch pisząc swoje stories. Szczególnie – Dominic, zakryj uszy znowu – Kevin nie jest ekspertem w pisaniu stories. Za każdym razem jak wraca do tego, musi… Jest dla niego trochę wolno.

To po prostu super przyjemny sposób na dostanie świetnego frameworku bez spędzania kupę czasu i debugowania z jego słabymi umiejętnościami Storybook.

Dominic podkreśla kluczowy punkt: całkowicie zmieniasz value proposition, bo AI fundamentalnie pisze stories za ciebie. Dostajesz całą wartość bez żadnej pracy.

Kevin zgadza się w 100%. To fundamentalna zmiana propozycji wartości Storybooka – deweloperzy otrzymują 100% wartości (weryfikację, testy, dokumentację UI) praktycznie „za darmo”, bez ponoszenia kosztu czasowego.

Od frontendu do backendu – nieoczywista przewaga Storybook

Kevin wspomina coś, co nie jest oczywiste dla większości ludzi. Ma na to osobne wideo, bo nie będzie tego pokazywał podczas webinaru.

To bardzo niedoceniana część tego podejścia: ponieważ te storybook stories są wypełnione tak dużą ilością kontekstu o danych, które do nich wchodzą, i kształcie tych danych, jest teraz naprawdę łatwo przejść od twojego frontendu i zbudować data access layer.

Niesamowicie łatwo. Nie musisz dawać prawie żadnych instrukcji, możesz zasadniczo powiedzieć: „Oto moje komponenty, oto moja strona, zbuduj mi endpointy.” I może wywnioskować, bazując na twoich storybook stories, jak to powinno wyglądać.

To jest ekstremalnie pomocne. Stories definiują kształt propsów i strukturę danych, co staje się idealną bazą do automatycznego generowania warstwy dostępu do danych.

Live demo – moment prawdy

Kevin kickstartuje zadanie. Agent zacznie pracować przez następne 5-10 minut, przechodząc przez całą task listę.

Podczas gdy to działa, pokazuje rezultaty. Otwiera Storybook i widzi wszystkie komponenty wygenerowane przez AI, podzielone na atoms, potem organisms (kombinacja atomów razem).

Wszystko wygenerowane automatycznie. Edge cases, long badges, małe ikony, high contrast, accessibility stuff. Dostajesz to za darmo, możesz pobawić się, spróbować różnych rzeczy, zobaczyć jak to wygląda.

Kevin widzi to pierwszy raz na żywo. Nie wie co agent wygenerował, dlatego jest szczerze zaskoczony, jak dobrze to wygląda.

Przyznaje: trochę żartuję, ale szczerze, nie robiłbym live demo i nie pociłbym się tylko lekko, gdybym nie miał dużej pewności, że to po prostu zadziała. Robił to wiele razy i prawie za każdym razem po prostu działa.

Gdy wszystko jest poprawnie ustawione, nawet jeśli AI nie jest deterministyczne i nie zawsze robi co chcesz, gdy je wpuścisz na szyny i z nowoczesnymi modelami, robi całkiem dobrą robotę przez większość czasu.

Pokazuje komponenty: filter bar, summary bar, różne stany, różne informacje. Sprawdza czy aplikacja w ogóle się uruchamia na localhost:3000.

Ta-da. Działa. Invoice tool dla subcontractorów – możesz uploadować dokumenty, drag and drop, sample data. Przechodzi przez estimates vs actual spend, pokazuje gdzie byli close, gdzie stracili pieniądze.

Czy to najlepsza aplikacja na świecie? Czy wygląda amazing? Jeszcze nie. Czy to świetny starting point do zbudowania tej aplikacji, którą ktoś z audytorium może wziąć i może zarobić $5k i wysłać Kevinowi $20 za rok? Być może.

Ale chodzi bardziej o technikę niż cokolwiek innego.

Browser Use – zamknięcie pętli feedbacku

Kevin pokazuje zupełnie nową funkcję Cursor – browser use. To wyszło dosłownie dwa dni przed webinarem.

Daje agentowi prostą instrukcję: „Otwórz Storybook i przejdź przez każdą story jeden po jednym. Napraw jakiekolwiek błędy lub dziwne rzeczy.”

To zamyka pętlę feedbacku.

Dominic jest podekscytowany. Co fajne, oczywiście przechodzisz przez to jako człowiek. Chcesz się upewnić, że wszystko wygląda dobrze, jednak gdy masz długo działające taski, możesz to zrobić automatycznie.

Cursor otwiera własną specjalną przeglądarkę. Agent wie, że Storybook jest na porcie 6006. Nie musiałeś mu tego mówić, w rezultacie klika przez komponenty jeden po drugim i robi screenshoty.

Dominic: „Screenshoty są fantastyczne!”

Kevin: „Naprawdę fajne. Możesz dostać poczucie jak to wygląda.” Co jest super fajne – jeśli chcesz, żeby to był długo działający task, możesz powiedzieć: „Idź i zrób wszystkie te rzeczy. Potem po prostu przejdź i zreviewuj to.”

Może to działać samo. Idziesz na lunch, zostawiasz na noc, wracasz i masz naprawdę ładny log jak to wyglądało, jakie błędy znalazł, co zrobił żeby je naprawić.

Kevin jest trochę zadziwiony co to faktycznie robi i próbuje myśleć o innych sposobach użycia tego. To wyszło dwa dni temu, dlatego jest naprawdę fajnym dodatkiem do workflow.

Balansowanie kosztów i wydajności

Pytanie z audytorium: czy jest price sensitivity dla tego wszystkiego? Bo nie trzeba dużo mrużyć oczy żeby zobaczyć, że robi dużo pracy. Zostawiasz na godziny, to może być nieograniczona ilość tokenów, którą wydasz. A do tego słyszysz o Claude sub-agents – możesz uruchomić cztery agenty i zrobić tę samą ilość pracy. To może być przerażające, szczególnie jeśli jesteś engineering managerem odpowiedzialnym za budżet inżynieryjny.

Kevin odpowiada szczerze. Jako osoba, która zarządzała stażystami latem i dostała niespodziewane rachunki, bo klikali przycisk milion razy z największym modelem – absolutnie musisz o tym myśleć. To prawdziwy concern.

Ale też – niedawno ktoś w ich zespole myślał, że ma darmowe kredyty. Używał top Opus 4.1, który kosztuje $75 za milion tokenów, co jest niewiarygodnie nieracjonalnie drogie. Kevin dostał rachunek na trzy tysiące dolarów.

Jego reakcja? Szybko wyłączyli to, jednak spojrzał na bill i policzył godziny pracy, które ten deweloper włożył w ten okres. Było warte tych trzech tysięcy. Dostali znacznie więcej wartości niż wydali.

Czy chcesz to robić każdego dnia? Nie. Ale często ludzie są bardzo wrażliwi na koszt. Widzisz ogromne liczby – $300, $500 miesięcznie – i myślisz „wow, to dużo pieniędzy na AI.”

Kevin pyta wprost: ile kosztuje zatrudnienie kontraktora na godzinę czy miesiąc? O wiele, wiele więcej. A będziesz produkował o wiele szybciej.

Koszty AI-assisted development powoli wkradły się do ich budżetu inżynieryjnego. To coś, co musisz udowodnić management team przez przyspieszenie delivery.

Kevin robi dema i pokazuje: „Hej, zbudowałem to w jeden dzień”. Reakcja? „Wow, nie mogę uwierzyć, że to zrobiłeś.”

W ich głowach wydanie dodatkowych $50, żeby dostać prototyp w dzień zamiast w tydzień, to no-brainer. Absolutne tak, pod warunkiem, że jesteś z tym odpowiedzialny.

Kevin wspomina też o open source modelach jako opcji dla osób na budżecie, jednak różnica między profesjonalną pracą w firmie a własnymi projektami jest istotna.

Jeśli chodzi o wybór modelu, GPT-5 to według Kevina złoty środek – $1 za milion tokenów przy bardzo dobrej jakości outputu.

Ale uwaga: pełna paleta technik optymalizacyjnych (refactoring, dokumentacja) dodaje tokeny i koszty. Musisz balansować między jakością a ekonomią.

Kevin stosuje wszystkie te techniki gdy buduje produkcyjną rzecz od zera, ma realny budżet, a czas jest większym ograniczeniem niż koszt.

Co robisz, gdy agent pracuje?

Kwestia czasu bezczynności to coś, o czym Kevin rozmawia cały czas w swoim zespole.

Dominic pyta: jak optymalizujesz swój czas żeby najmniej czekać na agenta? Czy to w ogóle ma znaczenie?

Kevin: 100%. 100%.

Jego główne podejście? Nie odchodź. Obserwuj.

Nawet jeśli agent pisze dobry kod, który przechodzi testy i działa, musisz mentalnie rozumieć swój codebase. To szczególnie ważne, gdy projekt rośnie.

Kiedy piszesz kod sam, ta wiedza przychodzi naturalnie. Z AI to bardziej przypomina review kodu współpracownika albo osoby, która dla Ciebie pracuje.

Najlepszy sposób? Stale sprawdzaj diff’y. Patrz, co się zmienia w kodzie w czasie rzeczywistym, bo Cursor ma narzędzia do przeglądania tego, co zostało zrobione.

Kevin przyznaje, że czasem idzie po kawę albo sprawdza Hacker News. Jest nawet dźwięk powiadomienia (który słychać w nagraniu), który pomaga mu wrócić do pracy. W zależności od nastroju i poziomu leniwości, robi to.

Nowa technika? Gdy tworzy task listę dla AI, pyta: „A co JA muszę zrobić?”

AI odpowiada: ustaw ten klucz, skonfiguruj org, przygotuj bazę danych staging, itd. Kevin zauważa, że to całkiem użyteczna lista rzeczy do zrobienia, gdy kod jest pisany.

Nieco dystopijne, że AI go prowadzi, jednak na razie pomija tę obserwację.

Utrzymywanie codebase przyjaznego dla AI

Pytanie z audytorium: masz tip jak sprawić, żeby Cursor czy inne agenty pracowały przez cały codebase? Ludzie doświadczają, że proszą o zastąpienie hard-coded values z design token variables i robi to częściowo, ale nie dotyka większości plików.

Kevin ma kilka rzeczy.

Po pierwsze – po prostu powiedz mu. Dodaj to do start prompta: „Zanim wykonasz jakąkolwiek pracę, przejdź przez codebase. Oto co zrobisz. Chcę, żebyś znalazł wszystkie pliki, które mogą być istotne dla tego zadania i nie pisał żadnego kodu, dopóki tego nie zrobisz.”

I też wypisz to. Chcę widzieć twoją pracę. To jak zadanie domowe dla dziecka – nie zgaduj.

Powiedz mi w scratchpadzie, jakie pliki uważasz za najważniejsze dla mnie. Przeczytaj to i zdecyduj: okej, tak czy nie.

To generalnie dobry sposób. I znowu, wszystko sprowadza się do zarządzania kontekstem, wpuszczenia tego tam.

Dominic podsumowuje: promtujesz agenta do skanowania codebase, agent pisze coś do scratchpada, dajesz human-in-the-loop review typu „hej, czy to na to powinienem patrzeć?”, mówisz tak. Więc są dwa prompty – pierwszy to context setting, drugi to weryfikacja.

Kevin potwierdza. To jedna rzecz, którą możesz zrobić z codebase.

Praktyka 1: Automatyczna refaktoryzacja

Druga rzecz, naprawdę pomocna. Kevin ma komendę, którą uruchamia po każdej zmianie, którą poprosił agenta o zrobienie, na końcu runa.

Zasadniczo mówi: „Chcę, żebyś upewnił się, że ten codebase jest przyjazny dla następnego agenta, który przyjdzie. Przychodzą świeżo i nie będą mieli żadnej pamięci o tym.”

To znaczy: używanie wielu zagnieżdżonych plików, mniejsze pliki. Jeśli widzisz plik, który ma więcej niż 500 linii kodu, refaktoryzuj to, zrób to teraz. Pozwól mi to zreviewować. Nie czekaj dwa tygodnie, a potem masz ogromny bałagan kodu do refaktoryzacji.

Zrób to teraz.

Kevin używa komendy /refactor w swoim workflow: „Przejrzyj kod i upewnij się, że jest przyjazny dla AI. Podziel pliki, które mają więcej niż 500 linii, na mniejsze moduły.”

Praktyka 2: Dokumentacja zmian

Druga rzecz to krok „document”, który zasadniczo mówi: używając git, spójrz na wszystkie pliki, które zmieniłeś, i dodaj trochę kontekstu na górze każdego pliku, żeby prowadzić następnego agenta o tym, co ten plik robi, jakie zmiany zostały ostatnio wprowadzone, co powinieneś wiedzieć.

Kevin używa komendy /document: „Użyj git diff, aby znaleźć wszystkie pliki, które ostatnio zmieniłeś. Na górze każdego z nich dodaj krótki komentarz z kontekstem, co ten plik robi i co się zmieniło, aby poprowadzić następnego agenta.”

Ten trick pochodzi od jego kolegi Jareda. Kevin szczerze przyznaje: „Jest dużo mądrzejszy ode mnie. Kradnę wszystko to. Dzięki, Jared.”

To naprawdę pomaga agentowi pozostać na torach.

Dominic zauważa: posiadanie codebase, który jest AI-friendly, jest niedocenione. I wie, że to trudne jeśli masz istniejący codebase.

Kevin ma szczęście – zaczyna nowe rzeczy od zera z wszystkimi najlepszymi praktykami, jednak możesz użyć niektórych z tych rzeczy. I niektóre z nich to common sense i best practices tak czy inaczej, dlatego możesz dostać niektóre z tych rzeczy za darmo, gdy zazwyczaj prawdopodobnie powinieneś je robić tak czy inaczej.

Dominic przyznaje: niektóre best practices, które Kevin przedstawił, są tak powszechne, że nawet on o nich zapomina. Są po prostu wbudowane i myślisz „och, nie pomyślałbym, żeby wspomnieć o tym agentowi.”

Kevin robi to, jednak z pewnością nie jest to top of mind dla niego.

Refaktoryzacja dodaje tokeny, dodaje więcej rzeczy. Musisz balansować.

Kevin generalnie robi to, gdy przychodzi czas na: dobra, buduję tę rzecz production quality od zera, mam prawdziwy budżet, a czas jest większym ograniczeniem niż koszt. Ładuje to całą kupą tych rzeczy, żeby dostać najlepszą możliwą jakość codebase.

Nie musisz tego robić, jednak zawsze powinieneś balansować koszt, czas i wysiłek.

Storybook MCP – optymalizacja przyszłości

Dominic wspomina o czymś, nad czym teraz pracują. Storybook MCP – bardzo eksperymentalny projekt. Jest repo.

Rzeczy, o których myślą? Jakość outputu, jasne, ale też token usage. Jak ekonomiczne to jest?

Wczesne benchmarki pokazują imponujące rezultaty:

45% redukcja token usage przez dostarczanie właściwego kontekstu we właściwym czasie
200% przyspieszenie generowania kodu

To oznacza szybszą pętlę feedbacku. Mniej kawy, mniej Hacker News (chyba że naprawdę chcesz), jednak więcej czasu na upewnienie się, że agent jest na właściwym torze.

Projekt jest na wczesnym etapie, ale pokazuje kierunek: lepsze zarządzanie kontekstem = mniej tokenów + szybsza praca.

Kluczowe wnioski

Webinar Dominica i Kevina pokazuje, że skuteczne AI-assisted development to nie magia. To metodyka.

Przesunięcie czasu z kodowania na planowanie i review. Strukturyzacja kontekstu w przemyślany sposób. Wymuszanie na AI skanowania projektu przed działaniem. Regularne refaktoryzacje i dokumentacja dla kolejnych agentów.

Praktyczna checklist: Metodyka AI & Storybook (wg. Kevina Lenawaya)

Przygotowanie projektu:

Czy masz bardzo szczegółową specyfikację i listę zadań dla agenta AI? (Zasada „over-specification”)
Czy folder .agent zawiera plik .rules z zasadami nazewnictwa, ścieżkami plików i preferencjami architektonicznymi?
Czy folder .agent ma scratchpad (notatnik) dla agenta do śledzenia postępów?
Czy używasz narzędzi i bibliotek „przyjaznych AI” (dobrze znanych modelom, nie najnowszych wersji)?

Instrukcje dla AI:

Czy prompt jasno określa, jakiej metodologii ma użyć AI (np. Atomic Design)?
Czy dostarczyłeś wskazówki dla niestandardowych systemów projektowych?
Czy polecenie dla AI zawiera wymóg automatycznego tworzenia plików .stories.js dla każdego komponentu i jego stanów?

Praca z agentem:

Czy wymuszasz skanowanie codebase przed rozpoczęciem pracy (zapisanie istotnych plików w scratchpadzie)?
Czy weryfikujesz listę plików przed daniem zielonego światła agentowi?
Czy monitorujesz diff’y w czasie rzeczywistym?

Weryfikacja i iteracja:

Czy natychmiast po wygenerowaniu kodu sprawdzasz wizualnie komponenty i ich stany w Storybooku?
Jeśli AI zawodzi, czy pytasz je, jak możesz poprawić swój prompt, zamiast tylko naprawiać kod?
Czy używasz Browser Use do automatycznej weryfikacji Storybook?

Utrzymanie jakości:

Czy uruchamiasz /refactor po zakończeniu pracy agenta (pliki <500 linii)?
Czy używasz /document do dodawania kontekstu na górze zmienionych plików?

Kevin kończy z obietnicą: dostępne repo z przykładami pojawi się tego samego dnia. Jego folder .agent zasługuje na osobne wideo, które planuje nagrać.

Chat podczas webinaru eksplodował entuzjazmem. Dominic dziękuje za liczne pro tips, które sam będzie musiał ponownie obejrzeć, żeby zanotować.

A najważniejsza lekcja? AI nie zastępuje software engineering. Zmienia sposób, w jaki je uprawiamy.

Biblioteka promptów do AI-assisted development

Kevin Lenaway podczas webinaru udostępnił kilka kluczowych promptów, które stosuje w codziennej pracy. Poniżej znajdziesz te prompty wraz z kontekstem, kiedy i jak je używać.

1. Logika promptu: Generowanie planu działania (Task List)

Kiedy używać: Jednorazowo na początku projektu, poza edytorem (np. w ChatGPT), aby wygenerować nadrzędny plan, który następnie wklejasz do swojego edytora (np. do pliku agent.md).

Prompt:

Jesteś najlepszym na świecie inżynierem oprogramowania i menedżerem produktu.

Przeanalizuj ten pomysł na startup: [TU WSTAW OPIS POMYSŁU] oraz moje zasady kodowania: [TU WSTAW ZASADY, NP. Z cursor.rules]

Wygeneruj listę zadań (checklist) do stworzenia prototypu, używając metodologii Atomic Design. Lista powinna zaczynać się od atomów, przechodzić do organizmów, a na końcu do stron.

Dla każdego komponentu UI zawsze twórz pliki .stories.js (Storybook), uwzględniając stan domyślny oraz przypadki brzegowe.

Uwagi: Ten prompt używa się poza edytorem (np. w ChatGPT) do wygenerowania strukturalnego planu, który potem stanowi bazę dla agenta w Cursor.

2. Logika promptu: Uruchomienie agenta

Kiedy używać: Jako główne polecenie w edytorze (jak Cursor), aby uruchomić agenta AI i kazać mu wykonać zadania z przygotowanej wcześniej listy.

Prompt:

Jesteś świetnym programistą. Otrzymałeś tę listę zadań [wskazanie na plik agent.md]. Przejdź przez nią krok po kroku, aż skończysz.

Jak to działa: Kevin używa tego jako polecenie z ukośnikiem w Cursor (/start-task), co pozwala szybko uruchomić standardowy workflow.

Uwagi Kevina: To jest trochę sztuka, trochę nauka, trochę rzucanie rzeczy w ścianę i patrzenie co się przyklei. Nie czuj, że musisz robić dokładnie tak, ale to dobry starting point.

3. System Prompt – ogólne wytyczne dla agenta

Kiedy używać: Jako stały element w konfiguracji projektu, żeby agent zawsze działał zgodnie z Twoimi zasadami.

Struktura według Kevina:

Role: You are the world’s best software engineer

Context: You are a product manager working on [project description]

High-level information: [project goals, constraints]

Specific rules:

[Rule 1: e.g., „Always create Storybook stories – this is mandatory”]
[Rule 2: e.g., „Use Atomic Design System”]
[Rule 3: e.g., „Remember you’re updating an existing codebase”]
[Add your specific requirements]

Storybook requirements:

Create default state
Create edge cases
Include accessibility considerations
[Add your specific story requirements]

Output format:

Start with one paragraph describing what you’re doing (give the agent bigger picture context)
Then provide a checklist of tasks to complete

Best practices według Kevina:

Daj modelowi rolę – jeśli wybierasz, niech będzie „world’s best”, nie „second best” czy „junior”
Bądź bardzo specyficzny w zasadach
Output format jest najważniejszą częścią prompta

4. Logika promptu: Zbieranie kontekstu (przed zmianami w istniejącym kodzie)

Kiedy używać: Przy rozpoczynaniu złożonych zadań w istniejącym projekcie. Wymusza to na AI zapoznanie się z kontekstem, zanim zacznie „na ślepo” wprowadzać zmiany.

Prompt:

Zanim zaczniesz pisać jakikolwiek kod, przeanalizuj całą bazę kodu. Chcę, żebyś znalazł wszystkie pliki, które mogą być istotne dla tego zadania. Nie pisz kodu, dopóki tego nie zrobisz.

Zapisz w 'notatniku’ (scratchpad), co znalazłeś, żebym mógł to zobaczyć.

Proces (2 prompty):

Pierwszy prompt: Context setting – zmuszasz AI do skanowania
Drugi prompt: Przejrzyj listę i powiedz „Yes, you’re on the right track” lub skoryguj

Dlaczego to działa: Nawet jeśli nowoczesne narzędzia są dobre w crawlowaniu codebase, bez jawnej instrukcji mogą pominąć istotne fragmenty.

5. Prompt: Weryfikacja wizualna (z „Browser Awareness”)

Kiedy używać: Po tym, jak AI zakończy generowanie komponentów UI. Jest to idealne zastosowanie dla funkcji „Browser Awareness”, aby AI samo zweryfikowało wizualnie swoją pracę w Storybooku.

Prompt:

Świetnie. Teraz otwórz Storybooka i przejdź przez każdą 'story’ (historię) jedna po drugiej. Napraw wszelkie błędy lub dziwne rzeczy, które zauważysz.

Co się dzieje:

Cursor otwiera własną przeglądarkę
Automatycznie nawiguje do Storybook (port 6006)
Przegląda każdy komponent jeden po drugim
Robi screenshoty
Identyfikuje i naprawia błędy
Tworzy log z wykonanych akcji

Bonus: Możesz to zostawić na noc jako long-running task. Rano masz kompletny log co zostało sprawdzone i naprawione.

6. Logika promptu: Profesjonalna rada (debugowanie własnego promptu)

Kiedy używać: Gdy AI kompletnie zawodzi i nie jest w stanie wykonać zadania. Zamiast walczyć z AI, prosi się je o pomoc w poprawieniu własnego polecenia.

Prompt:

Wygląda na to, że się pogubiliśmy.

Co poszło nie tak? Co mogę zrobić następnym razem w moim prompcie lub jakie informacje mogę dostarczyć, aby pomóc ci lepiej wykonać to zadanie?

Kevin o tym: „You’d be surprised at how effectively it will be able to go through and say, like, 'Oh, you know what? I had some instructions here that were conflicting with some instructions here. I wasn’t quite sure what you wanted me to do, so I did X.'”

Reakcja Kevina: „Oh my gosh, you’re right, I should do that!”

Bonus: Czasem AI powie Ci brutalnie: „I tried to do it, but your code is just so horribly written that I just don’t even start.” Kevin przyznaje: „That burns. Maybe you’re right.”

7. Polecenia: Utrzymanie „Bazy kodu przyjaznej AI”

Kiedy stosować: Okresowo, aby utrzymać higienę bazy kodu i ułatwić przyszłym agentom AI pracę z nią.

Logika /refactor:

Przejrzyj kod i upewnij się, że jest przyjazny dla AI. Podziel pliki, które mają więcej niż 500 linii, na mniejsze moduły.

Requirements:

Use lots of nested files
Use smaller files (if a file has more than 500 lines of code, refactor it NOW)
Break it down logically
Don’t wait – do this refactoring immediately

Let me review it before we move on.

Logika /document:

Użyj git diff, aby znaleźć wszystkie pliki, które ostatnio zmieniłeś. Na górze każdego z nich dodaj krótki komentarz z kontekstem, co ten plik robi i co się zmieniło, aby poprowadzić następnego agenta.

For each modified file, add:

What this file does
What changes have been made recently
What the next agent should know

Źródło tricka: Kevin przyznaje, że pomysł /document pochodzi od jego kolegi Jareda. „He’s much smarter than me. I steal all this.”

Dlaczego to ważne: Następny agent (lub ten sam agent w nowej sesji) nie będzie miał pamięci o tym, co zrobił poprzedni. AI-friendly codebase to kluczowa inwestycja.

8. Prompt do generowania „Twojej” task listy

Kiedy używać: Podczas gdy agent pracuje, żeby efektywnie wykorzystać czas bezczynności.

Prompt:

All right, make the task list for the AI, but what other things do I need to do?

Co otrzymujesz:

Lista rzeczy do manualnej konfiguracji (API keys, organizacje)
Setup bazy danych (staging, production)
Infrastruktura i dependencies
Inne non-coding tasks

Kevin o tym: „Oh, actually, this is quite useful to have this task list of things I have to go and do while the code is being written. Yeah, it’s kind of a fun little technique. I’ve just started using that, but a little bit dystopian of the AI guiding me.”

9. Prompt do budowania backendu ze Storybook

Kiedy używać: Po zakończeniu pracy nad frontendem ze Storybook stories.

Prompt:

Here’s my components, here’s my page, go build me some endpoints.

Dlaczego to działa: Storybook stories są wypełnione kontekstem o strukturze danych i ich kształcie. AI może wywnioskować jak powinny wyglądać endpointy bez dodatkowych instrukcji.

Kevin o tym: „It’s actually really easy now to go from your front end and build out your data access layer. Incredibly easy. You don’t have to give it almost any instruction.”

Złote zasady promptowania według Kevina

Over-specify na początku – to największa różnica między „to nie działa” a „jestem 10x szybszy”
Daj agentowi rolę – jeśli już, to „world’s best software engineer”
Output format to król – zawsze określ jak ma wyglądać rezultat
Context management > wszystko inne – 95% sukcesu vs slop zależy od zarządzania kontekstem
Nie bój się restartować – jeśli nie działa po 1-2 próbach, nigdy nie zadziała
Pytaj AI jak je lepiej promptować – modele są zaskakująco dobre w dawaniu feedback
Dokumentuj dla następnego agenta – pamięć jest efemeryczna
Bądź leniwy strategicznie – pozwól agentowi iść samemu, dopóki może

Kluczowe insighty

Paradoks AI: Więcej planowania = mniej pracy

Standardowo myślimy: AI ma nas uwolnić od planowania i przyspieszyć kodowanie. Wpisujemy szybki prompt, patrzymy co wyjdzie, iterujemy na bieżąco.

W praktyce okazuje się, że: Kevin spędza 4 godziny na szczegółową specyfikację i 10 minut na kodowanie. Ta odwrócona proporcja (40% planowania, 10% kodowania, 40% review) daje kod, który jest „95% drogi do celu”, zamiast slopu do wyrzucenia. Różnica między developerami, którzy mówią „jestem 10x szybszy” a tymi, którzy twierdzą „AI w ogóle nie działa” sprowadza się do jednej rzeczy: over-specification upfront.

Dlaczego to jest istotne: AI nie zwalnia Cię z myślenia – przenosi Twoje myślenie na wcześniejszy etap. Gdy zaoszczędzisz 90% czasu na kodowaniu, ale nie zainwestujesz go w planowanie, dostajesz kod który trzeba przepisać. To nie jest oszczędność czasu, to przesunięcie długu technicznego.

Test na jutro: Następnym razem gdy zlecasz zadanie AI, zamiast napisać 3-zdaniowy prompt i czekać na rezultat, spróbuj poświęcić 30 minut na rozpisanie szczegółowej specyfikacji w formacie: kontekst → konkretne kroki → oczekiwany format outputu. Sprawdź czy kod wymaga mniej poprawek niż zwykle.

Paradoks aktualizacji AI: Starsze wersje = lepsze wyniki

Standardowo myślimy: Aby uzyskać najlepsze rezultaty, musimy zawsze używać najnowszych wersji bibliotek i frameworków (tzw. „bleeding-edge”).

W praktyce okazuje się, że: W pracy z AI, narzędzia „przyjazne AI” to często te, które są nieco starsze i dobrze ugruntowane w danych treningowych modelu. Kevin celowo używa starszej wersji Storybook, bo nowsze funkcje mogą jeszcze nie być znane AI (według stanu wiedzy z września 2024). W rezultacie, używanie najnowszych wersji (np. v.latest), których AI jeszcze „nie zna”, prowadzi do frustracji, halucynacji i błędów w generowanym kodzie.

Dlaczego to jest istotne: To całkowicie odwraca priorytety przy wyborze stacku technologicznego. Stabilność i „znajomość” przez AI stają się ważniejsze niż dostęp do najnowszych, eksperymentalnych funkcji.

Test na jutro: Następnym razem gdy rozpoczynasz projekt z AI, zamiast automatycznie wybierać v.latest każdej biblioteki, sprawdź datę graniczną wiedzy modelu AI, którego używasz. Celowo wybierz wersję o ugruntowanej pozycji, która istniała 6-12 miesięcy przed tą datą, i zobacz, czy AI generuje kod pewniej i z mniejszą liczbą błędów.

Polecane narzędzia

Cursor – AI-assisted IDE z browser-aware features
Storybook – narzędzie do budowania UI components w izolacji
Storybook MCP – eksperymentalne rozwiązanie do optymalizacji token usage
ChatGPT – do generowania task list i planowania
Claude Sonnet 4.5 – szybki model do codziennej pracy
GPT-5 – złoty środek między ceną ($1/milion tokenów) a jakością

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: [Rapid Frontend Prototyping with Cursor & Storybook]

Tag: Prototypowanie Frontendu

Prototypowanie z Cursor i Storybook – nowy model pracy dewelopera w erze AI #EN339