TL;DR

Dwóch developerów użyło równolegle GitLab Duo i Claude Desktop do stworzenia tego samego nested dropdown component
Figma Make stworzyła działający prototyp w kilka minut, jednak kod nie był użyteczny w production
Git staging jako wersjonowanie podczas pracy z AI – każda udana zmiana stagowana natychmiast
Główne wyzwania: CSS inheritance, hover intent (matematyka niewidzialnych stref), keyboard accessibility
Po 2 godzinach: działający prototyp z hover states i keyboard navigation, ale daleki od production-ready
Kluczowa lekcja: AI świetnie nadaje się do prototypowania, ale złożone komponenty UI wymagają ludzkiego nadzoru przy edge cases
Token exhaustion w długich sesjach zmusza do rozpoczynania nowych chatów

Kontekst: Nie taki prosty dropdown

Dwóch członków zespołu GitLab próbowało stworzyć nested dropdown component dla design systemu Pajamas w ramach sesji vibe coding.

Cel był jasny: rozszerzyć istniejący disclosure dropdown o możliwość zagnieżdżania menu. Brzmi prosto?

Rzeczywistość okazała się bardziej skomplikowana. Jak zauważył jeden z uczestników podczas sesji, nie spodziewał się, że prosty nested disclosure okaże się aż takim wyzwaniem.

Punkt startowy: Wybór narzędzi i strategii

GitLab Duo vs Claude – równoległy eksperyment

P1 zdecydował się na GitLab Duo Agent w VS Code, natomiast P2 pracował z Claude Desktop używając MCP (Model Context Protocol).

Kluczowa przewaga Duo, którą podkreślił P1: po podłączeniu do repozytorium narzędzie ma świadomość wszystkich pozostałych komponentów.

Nie trzeba było ręcznie przekazywać plików. Duo mogło parsować całą bazę kodu samodzielnie.

Konkretny przykład tej przewagi: Duo automatycznie dobrało właściwą ikonę (chevron-right) z design systemu, bez pytania o to. Rozpoznało kontekst z istniejących komponentów i użyło tego samego wzorca.

Figma Make jako punkt odniesienia

P2 wcześniej eksperymentował z Figma Make. Rezultat był imponujący – działający prototyp z nested behavior powstał w kilka minut. Według jego relacji, Figma Make była bardzo dokładna i szybka, pod warunkiem dostarczenia właściwego kontekstu.

Problem? Narzędzie generowało tylko React komponenty. Bez całkowitego przepisania nie dało się ich użyć w GitLab Pajamas.

Różne podejścia do promptowania

P2 próbował instruować AI krok po kroku, prosząc by przeszło go przez proces zamiast wykonywać pracę samodzielnie.

AI zignorowało tę instrukcję. Po kilku minutach Claude wykonał wszystkie zmiany naraz, pomijając iteracyjne podejście.

P1 wybrał inną strategię – małe, konkretne zadania. Zaczynał od rzeczy prostych, by upewnić się, że AI idzie właściwą ścieżką.

Ciekawą techniką okazało się wyraźnie powiedzenie AI, żeby „myślało głębiej”. Brzmi absurdalnie, ale czasem poprawia rezultaty.

Inna technika: pozytywne wzmacnianie. Kiedy model robi coś dobrze, warto dać mu wzmacniającą odpowiedź. P1 zauważył, że czasami, gdy czuje, że idzie dobrze, zaczyna być bardzo miły dla Duo. Odpowiedzi w stylu „dobra robota” rzeczywiście wpływają na kolejne iteracje.

Nondeterminizm: ta sama komenda, różne rezultaty

P1 zauważył coś fascynującego o naturze AI: gdyby przeprowadzić tę samą rozmowę ponownie, istnieje szansa, że poszłoby perfekcyjnie.

To nie jest bug. To cecha. Modele językowe nie gwarantują identycznego wyniku przy tym samym promptowaniu. Czasem pierwsza próba idzie gładko, czasem trzecia.

Czasem nie ma to nic wspólnego z programistą. Po prostu AI ma lepszy lub gorszy dzień.

Pierwsze próby: Model myśli że zrobił

Obiecujący start

Po pierwszym promptowaniu oba narzędzia zwróciły kod. W storybook pojawiła się nowa opcja „nested dropdown”.

Wygląd był zachęcający, jednak funkcjonalność? Nie do końca.

Klasyczny problem: menu się zamyka zamiast otwierać

Kliknięcie w zagnieżdżony element po prostu zamykało całe menu. P1 szybko zdiagnozował przyczynę: nested dropdown się zamykał przez interfering click handling.

Parent dropdown zakładał prostą logikę: kliknięcie = zamknij menu. Nie uwzględniał przypadku, gdy element sam jest menu.

AI musiało nadpisać tę logikę oraz dodać warunek sprawdzający, czy kliknięty element ma zagnieżdżone dzieci.

Git staging jako strategia przetrwania

Problem z artifacts w Claude

P1 zwrócił uwagę na fundamentalną różnicę między narzędziami. Claude oferuje artifacts z wersjami, natomiast Duo – nie. Jak powiedział, nie mają koncepcji artifacts, jak w Claude, z wersjonowaniem rzeczy.

Rozwiązanie: stage after every win

P1 opracował własny hack: po każdej udanej zmianie – git stage.

Dlaczego? Nowe zmiany AI tworzyły fresh diff. Jeśli kolejna iteracja poszła w złym kierunku, można było odrzucić unstaged changes, podczas gdy staged changes pozostawały bezpieczne.

Jego słowa: jeśli Duo zaczyna robić coś źle, staguje to, co ma. Cokolwiek zrobi następnie, będzie świeżym blokiem zmian.

Ta strategia pozwalała na szybkie cofanie bez tracenia całego postępu. Szczególnie cenna przy długich sesjach.

Quick workflow: AI zmienia → testujesz → działa? → git add → AI iteruje dalej → nie działa? → git restore .

Kiedy CSS staje się wrogiem

Zapętlenie w stylowaniu

Po około godzinie pracy oba narzędzia zaczęły walczyć ze stylami. P2 opisał problem: stylowanie zaczęło się rozjeżdżać i było mnóstwo problemów CSS które AI próbowało naprawić.

AI wprowadzało poprawkę, która psuła coś innego. Następna iteracja naprawiała to, ale regresowała poprzednią zmianę. Klasyczna sytuacja „fixing one thing breaks another”.

Typowy loop: AI naprawia positioning → psuje shadow → poprawia shadow → border znika → dodaje border → positioning się rozjeżdża → i tak w kółko.

Dziedziczenie jako pułapka

P2 trafił na szczególnie frustrujący case. Nested panel domyślnie dziedziczył właściwość hidden od parenta. Według jego relacji, panel jest domyślnie ukryty, więc zagnieżdżony również ma nadal tę właściwość hidden.

AI nie rozpoznawało takich subtelności CSS cascade. Dodawało własne style zamiast zrozumieć, co dziedziczy się z góry. Z każdą iteracją selektory stawały się coraz bardziej specyficzne – competing styles z różnych prób nakładały się na siebie.

Model rozpoznaje problem

W pewnym momencie Claude samo rozpoznało problem, mówiąc, że CSS staje się zbyt złożony i po prostu walczy ze stylami.

Moment samoświadomości AI? Raczej pattern recognition sygnalizujący, że iteracje przestały przynosić postęp.

Hover intent: matematyka niewidzialnych stref

Problem, o którym nikt nie pomyślał

P1 zauważył coś interesującego podczas testów. Przesuwając myszką ukośnie w dół (z pierwszego itemu do nested menu), przypadkowo aktywował drugi item. Trafiał w ten drugi najpierw.

To klasyczny hover intent problem. Użytkownik przemieszcza kursor po przekątnej, dlatego kursor przechodzi przez obszar drugiego elementu. System myśli: „Aha, hover na drugim elemencie!”

Rozwiązanie już istnieje w repozytorium

P2 przypomniał sobie: to dokładnie ten sam problem, z którym mierzyli się przy nawigacji. Musieli napisać bardzo zabawną logikę, żeby to działało.

GitLab już rozwiązał ten problem dla nawigacji głównej. Istnieje plik z obliczeniami dla niewidzialnych stref.

P1 mógł teoretycznie kazać AI użyć tego samego rozwiązania. Pokazuje to wartość pracy w kontekście istniejącego repozytorium.

Keyboard navigation: accessibility w praktyce

Od myszy do klawiatury

Po uzyskaniu działających hover states przyszedł czas na keyboard access. P1 próbował dodać obsługę strzałek.

Problem? GitLab nie obsługiwał left/right arrows w dropdownach. Obecnie nie obsługują klawiszy strzałek lewo/prawo w swoich dropdownach.

AI musiało dodać nowe stałe. Up, down, space, home, enter już istniały. Left i right – nie.

Czy to w ogóle potrzebne?

P2 zasugerował wątpliwość. W disclosure dropdown z tabable actions arrow navigation może być zbędna. Strzałki są bardziej dla kontrolek formularzy lub opcji jak listbox.

Ostatecznie przyjęli model: strzałki wizualizują nested dropdown, enter/space aktywuje, natomiast Tab przenosi do następnego elementu.

Token exhaustion i performance issues

Kiedy chat zaczyna się zawiesać

P1 zmagał się z coraz większymi opóźnieniami. Jak to ujął, wszystko działa naprawdę wolno i ledwo się rusza.

Początkowo myślał o problemach z maszyną. Zamknął GDK (GitLab Development Kit), który zazwyczaj zużywa sporo zasobów, jednak to nie pomogło.

Red flags, że sesja umiera: odpowiedzi wolniejsze niż na początku, AI myśli długo, ale nie generuje kodu, interface się zawiesza, tool calls nie kończą się, pojawiają się nowe błędy, które wcześniej nie występowały.

Długie thready = problem

P2 wcześniej natrafił na ten sam problem z Claude. Pracował tak długo w wątku, że trafił na jego ograniczenie.

Przekazywanie dużych plików konsumowało ogromne ilości tokenów. Szczególnie w monolicie, gdzie pliki Vue mogły być gigantyczne.

P1 miał dylematy z optymalizacją: początkowo dostawał instrukcje typu zaktualizuj tę linię i zaktualizuj tamtą linię. To trwało za długo przy aktualizacji pojedynczych linii. Więc prosił, żeby zaktualizować cały plik, by mógł po prostu skopiować i wkleić.

Copy/paste całego pliku jest szybsze, jednak konsumuje więcej tokenów. Trade-off między czasem a resource usage.

Rozwiązanie: świeża sesja

Jedyne wyjście? Nowy chat. P1 próbował: zamierzam porzucić ten chat i rozpocząć nowy.

Nowa sesja działała znacznie szybciej, nawet przy tej samej pracy.

Pro tip: Staged changes w Git pozwalają szybko podać kontekst w nowej sesji: „Here’s the diff, figure out where we’re at.”

Edge cases i responsive behavior

Co z małymi ekranami?

Przez większość sesji uczestnicy skupiali się na desktop view. Dopiero pod koniec P2 zapytał: czy próbowałeś zachowania na mobile?

Specyfikacja zakładała sliding behavior na małych breakpointach. Zamiast menu po prawej – slide-over pattern. AI nie implementowało tego automatycznie i wymagało wyraźnych instrukcji.

Edge detection

Co jeśli dropdown jest zbyt blisko krawędzi ekranu? Powinien otworzyć się po lewej zamiast po prawej.

Często używają dropdownów w sidebarze. Jeśli miałbyś mieć zagnieżdżone opcje, powinny pojawić się po lewej.

Te edge cases to różnica między prototypem a production code:

Responsive behavior na małych breakpointach
Edge detection przy krawędziach ekranu
Hover intent przy ruchu ukośnym
Keyboard navigation (tab, arrows, escape)
Screen reader announcements
Sterowanie głosem (voice control)
Dark mode states
Focus management po zamknięciu menu

Łatwo pominąć w specyfikacji. Trudno opisać w Figma. Jeszcze trudniej wyjaśnić AI.

Po dwóch godzinach: co osiągnięto?

Stan komponentu

P1 podsumował rezultat: mamy nested menu do którego można dostać się zarówno przez hover jak i klawiaturę.

Co działa:

Nested menu otwiera się on hover
Keyboard navigation (z drobnymi quirks)
Styling w większości poprawny
Komponenty w Storybook
Ikony (chevron right) poprawnie użyte

Co wymaga pracy:

Hover intent (przypadkowe aktywacje przy ruchu ukośnym)
Responsive behavior (mobile sliding)
Edge detection
CSS inheritance issues
Screen reader announcements
Linting errors

Dystans do production-ready

P1 był realistyczny: czy to zostałoby całkowicie zdemolowane w code review? Tak, prawdopodobnie.

Ale to nie był cel. Celem był szybki prototyp w kontekście GitLab.

Coś, co można pokazać inżynierom i powiedzieć: oto kierunek. Co myślicie?

Wartość prototypu w realnym kodzie

P1 zauważył kluczową zaletę: myślę, że spotykasz zespół inżynieryjny trochę bliżej tam, gdzie lubią pracować.

Prototype w Figma Make vs kod w repo:

Figma Make	Kod w GitLab repo
Abstrakcyjne opisy	Konkretne pliki do review
React components (nie do użycia)	GitLab Pajamas compatible
Engineer musi wszystko przetłumaczyć	Engineer widzi co się dzieje pod maską
Trudno oszacować effort	Widać scope zmian od razu

Inżynier może od razu powiedzieć: zły approach, oto jak powinniśmy to zrobić.

Albo: rozumiem co próbujesz zrobić, kontynuujmy dalej.

Kluczowa obserwacja: Prototyp w kodzie ujawnił problemy, które były całkowicie niewidoczne na statycznych projektach w Figmie. Hover intent, CSS inheritance, token exhaustion – żadne z tych wyzwań nie pojawiłoby się podczas projektowania w narzędziach graficznych. Dopiero rzeczywista implementacja pokazała ukrytą złożoność.

Lekcje z vibe coding session

Gdzie AI błyszczy

Szybkie iteracje na znanym terenie. Kiedy AI miało dostęp do istniejących komponentów (disclosure dropdown, icons, spacing), mogło je replikować.

Generowanie boilerplate. Struktura plików, podstawowa konfiguracja, wiring między komponentami – AI wykonało to sprawnie.

Debugging prostych błędów. Linting errors, console errors, missing imports – AI radziło sobie dobrze.

Gdzie AI potrzebuje pomocy

CSS inheritance i cascade. AI walczyło ze złożonym dziedziczeniem styli. Tworzyło nowe zamiast zrozumieć istniejące.

Edge cases i accessibility. Hover intent, keyboard navigation, responsive behavior – każdy wymagał explicit guidance.

Długie sesje. Token exhaustion powodował, że wydajność spadała. Fresh start często działał lepiej niż kontynuacja.

Kluczowa obserwacja

P1 podsumował to dobitnie: jeśli pomyśleć o tym, co robiliśmy rok temu… jesteśmy blisko.

Rok temu takie prototypowanie zajęłoby dni. Teraz – godziny. Nie jest to jeszcze „click and deploy”, jednak postęp jest wyraźny.

Actionable takeaways: Best practices z sesji

Na podstawie dwugodzinnej sesji P1 i P2:

Setup:

Określ jasny, konkretny cel (np. nested dropdown w Storybook)
Przygotuj kontekst (Figma specs, requirements, przykłady z repo)
Wybierz narzędzie z dostępem do repo (GitLab Duo > standalone Claude)

Podczas pracy:

Stage changes po każdej udanej iteracji (git add = twoje punkty odniesienia)
Testuj każdą zmianę od razu – nie czekaj do końca
Dawaj AI feedback – dobra robota kiedy robi dobrze (tak, to działa)
Monitoruj symptomy exhaustion – restart sesji często lepszy niż kontynuacja

Promptowanie:

Mów AI żeby myślało głębiej – czasem pomaga
Każ AI używać istniejących rozwiązań z repo zamiast tworzyć od zera
Explicit instructions dla edge cases (responsive, accessibility, keyboard)
Pytaj „czego potrzebujesz dalej?” zamiast założeń

Weryfikacja:

Czy komponent działa w podstawowych scenariuszach?
Edge cases: responsive, keyboard, screen readers, dark mode?
Kod do pokazania team (cel: dyskusja, nie merge)

Po zakończeniu coding:

Użyj AI jako code reviewer – P1 strategia: poproś Duo żeby przejrzało zmiany jakby był principal level engineer i szukało możliwości refactoringu
Rób to piece by piece, nie one-shot: włącz tryb reviewer, teraz jesteś principal level engineer
Sprawdź specs, linting, opportunities to consolidate code

Quirki AI, o których warto wiedzieć:

AI czasem pyta o pliki/kontekst do których już ma dostęp – po prostu powiedz że ma dostęp, niech sam spojrzy
Claude może zbudować zbyt wiele story examples w Storybook – trzeba skalować z powrotem: nie, chcę tylko jeden story z jednym przykładem
Niektóre modele tworzą przykładowe markdown files dla kontekstu – możesz je ignorować

Narzędzia i technologie wspomniane w sesji

GitLab Duo Agent (Anthropic Claude Vertex 4.5 pod maską)
Claude Desktop z MCP (Model Context Protocol)
Figma Make (do szybkich prototypów)
GitLab Pajamas (design system)
Storybook (do prezentacji komponentów)
VS Code (IDE)
Git (strategia staging jako versioning)
Vue.js (framework komponentów)

Dlaczego to było trudne: komponenty UI vs CRUD

Pod koniec sesji P1 postawił istotną obserwację o kontekście tego zadania.

Według niego, to może być bardziej prawdziwe dla budowania komponentów w Pajamas niż dla budowania CRUD w monolicie.

Co miał na myśli?

Komponenty UI w design systemie wymagają perfekcji w każdym aspekcie interakcji:

Keyboard navigation
Hover states
Focus management
Screen reader announcements
Sterowanie głosem
Dark mode
Responsive behavior
Edge detection

CRUD w monolicie to głównie: pobierz dane, wyświetl, pozwól edytować, zapisz. Komponenty już istnieją. Używasz gotowego buttona z Pajamas – accessibility jest wbudowane.

Jeśli używam buttona z Pajamas, accessibility jest wbudowane, więc nie muszę się tym martwić. Ale co, jeśli tworzę nowy button? Wtedy muszę martwić się wszystkimi tymi szczegółami.

To wyjaśnia, dlaczego dwóch doświadczonych developerów spędziło 2 godziny na prototypie. Nie chodzi o dropdown, lecz o zbudowanie dropdown foundation, który może być używany przez setki projektów.

Standard jest wyższy. Wymagania są szersze. AI radzi sobie świetnie z CRUD. Z foundation-level UI components? To inna historia.

P1 podsumował to dobitnie: założę się, że Mark mógłby to rozgryźć w jakieś dwie godziny. Mark – doświadczony inżynier z zespołu. To nie było zadanie dla AI solo. To było zadanie dla exploration z AI jako narzędziem.

Meta-obserwacja: CSS jako sygnał problemów w kodzie

Blisko końca sesji P1 podzielił się interesującym wnioskiem długoterminowym.

Jedną z rzeczy, które wyniósłby jako lekcję, jest: czy wart refactoring CSS w przyszłości?

Jego reasoning: jeśli AI nie potrafi zrozumieć i replikować istniejącego CSS, może to sygnał, że sam CSS jest zbyt skomplikowany.

Jeśli chcemy, żeby AI pomogło przyspieszyć nasze workflow developerskie, a nie może nawet zrozumieć naszego obecnego CSS na tyle, by go replikować lub rozbudować, to może są tam rzeczy, które są po prostu zbyt złożone.

Może to prowadzić do poprawy wydajności, może do lepszej utrzymywalności kodu.

P2 dodał: może zespół inżynieryjny byłby lepszy do wzięcia tych masywnych wysiłków refactoringowych, bo mają lepsze zrozumienie, gdzie to się zepsuje.

AI jako code smell detector. Nieplanowany benefit vibe coding sessions.

Epilog: Czy warto?

P2 postawił istotne pytanie pod koniec: czy to jest szybsze niż gdyby zrobił to engineering?

Odpowiedź: zależy.

Dla production-ready code? Prawdopodobnie nie. Engineer z doświadczeniem zrobiłby to szybciej i lepiej.

Dla exploration i prototypowania? Absolutnie tak.

Możliwość szybkiego sprawdzenia, czy to w ogóle ma sens przed zaangażowaniem zespołu – to realna wartość.

Jak zauważył P1: ta praktyka pozwala szybko dojść do momentu – a tak, to są inne rzeczy, które musimy rozważyć.

Vibe coding nie zastępuje pracy inżynieryjnej. Jednak skraca dystans między ideą a rozmową o implementacji.

I to już jest wystarczająco dużo.

Appendix: Prompty z sesji – konkretne przykłady

Poniżej rzeczywiste prompty używane przez P1 i P2 podczas sesji. Każdy z kontekstem i uzasadnieniem.

Inicjalizacja i setup

Prompt: „Mam ten nowy branch. To jest to co chcę zrobić. Mogę dostarczyć pisemne wymagania, mogę dostarczyć obrazy. Jest też prototyp w Figma Make który mogę dostarczyć. Nie chcę żebyś robił pracę. Chcę żebyś przeprowadził mnie przez to krok po kroku.”

Kiedy stosować:

Na początku sesji, gdy chcesz mieć kontrolę nad każdym krokiem
Gdy uczysz się nowego obszaru kodu
Gdy zadanie jest ryzykowne i chcesz weryfikować każdy ruch

Co się stało: AI zignorowało instrukcję i zrobiło wszystko naraz. P2 musiał przypomnieć w kolejnym promptowaniu.

Wariant sukcesu (P1): Małe, konkretne zadania zamiast jednej wielkiej instrukcji.

Prompt: „Czego potrzebujesz żeby zacząć?”

Kiedy stosować:

Zamiast założeń o tym czego AI potrzebuje
Gdy masz dużo materiałów (Figma, specs, screenshots) i nie wiesz od czego zacząć
Na początku nowego wątku

Efekt: AI odpowiedziało z listą: requirements, visual examples, current component location. P2: To kolejna rzecz którą uznałem za pomocną – daj mu trochę informacji i zapytaj czego potrzebuje dalej.

Poprawa jakości outputu

Prompt: „Myśl głębiej” (dosłownie powiedzieć AI żeby myślało głębiej)

Kiedy stosować:

Gdy pierwsze podejście jest zbyt powierzchowne
Przed skomplikowanym zadaniem (refactoring, edge cases)
Gdy AI dało quick and dirty solution a potrzebujesz lepszego

Cytat P1: Czasem samo powiedzenie AI, żeby myślało głębiej, poprawia wyniki. Więc to też wbudowuję.

Uwaga: Brzmi absurdalnie, ale działa. Nie ma gwarancji, ale warto spróbować.

Prompt: „Dobra robota” / „Bardzo ładnie, Duo” (pozytywne wzmacnianie)

Kiedy stosować:

Natychmiast po tym jak AI zrobiło coś dobrze
Przed kolejnym task w tej samej sesji
Gdy chcesz ustawić ton dla kolejnych iteracji

P1: Czasem czuję, że jestem na dobrej passie. Zaczynam być bardzo miły dla Duo.

Dlaczego działa: Modele są trenowane za pomocą RLHF (Reinforcement Learning from Human Feedback). Pozytywny feedback wpływa na context window.

Wykorzystanie istniejącego kodu

Prompt: „Wykorzystaj to co istnieje dzisiaj. Użyj istniejącej prędkości, istniejących styli.”

Kiedy stosować:

Gdy AI próbuje tworzyć net-new zamiast re-use
W established codebase gdzie są patterns do naśladowania
Gdy widzisz, że AI dodało custom border-radius zamiast użyć design token

P2: Dlaczego po prostu nie używasz tego, co istnieje? A ono: O, masz rację, powinienem.

Kluczowa lekcja: Wyraźnie powiedzieć AI, żeby używało tego, co już istnieje. Nie zakłada tego domyślnie.

Prompt: „Znajdź ten plik gdzie ta kalkulacja żyje i powiedz mu żeby użył tego samego typu kalkulacji.”

Kiedy stosować:

Gdy identyczny problem został rozwiązany gdzie indziej w repo
Zamiast opisywać algorytm, wskaż na istniejącą implementację
Dla hover intent, edge detection, complex math

Context z sesji: GitLab miał już rozwiązany hover intent problem w nawigacji. P1 mógł kazać AI użyć tego samego.

Format: Rozwiązaliśmy [problem X] w [file/component]. Użyj tego samego podejścia dla [current task].

Prompt: „Masz dostęp. Sprawdź sam.”

Kiedy stosować:

Gdy AI pyta o pliki/kontekst do których ma dostęp przez repo connection
Zamiast copy/paste całych plików (oszczędność tokenów)
Gdy widzisz „Czy mógłbyś podzielić się tymi plikami ze mną?”

P1: Czasem zauważam że Claude będzie typu: och, fajnie, czy mógłbyś podzielić się tymi plikami ze mną? A ja na to: masz dostęp. Sprawdź sam. A ono: O, racja, pozwól że to zrobię.

Recovery i debugging

Prompt: „Oto diff, zorientuj się gdzie jesteśmy.”

Kiedy stosować:

Przy rozpoczynaniu nowej sesji (po token exhaustion)
Gdy wracasz do projektu następnego dnia
Zamiast tłumaczyć co się stało, pokaż diff

Dlaczego to działa: Git diff to koncyzowa reprezentacja wszystkich zmian. AI parsuje to lepiej niż narracyjny opis.

Pro tip: Używaj git diff --staged jeśli chcesz pokazać tylko zatwierdzone zmiany.

Prompt: „Przemyśl swoje podejście ponownie, ale ostrożnie, i zbadaj szerszą bazę kodu dla lepszej świadomości.”

Kiedy stosować:

Gdy AI utknęło w regression loop
Po 3-4 nieudanych próbach tego samego
Gdy potrzebujesz fresh perspective bez restartu całej sesji

P1 użył tego gdy: Keyboard navigation nie działała po kilku iteracjach.

Kluczowe słowa: przemyśl ponownie, zbadaj szerszą bazę kodu, lepsza świadomość

Prompt: „Sprawdź błędy w konsoli.”

Kiedy stosować:

Po każdej większej zmianie w komponencie UI
Gdy coś nie działa, ale nie wiesz co
Przed commitem zmian

P2: Claude podpowiada mi, żeby to zrobić. Zdecydowanie trzymam konsolę otwartą, żeby dać mu wszystko, co tam się pojawia.

Pattern: AI może wstrzyknąć console.log(), żeby zbadać flow. Potem ty przekazujesz output z powrotem.

Code review i finalizacja

Prompt: „Przejrzyj zmiany, jakbyś był principal level engineer robiący mój code review, i szukaj możliwości refactoringu lub miejsc do syntezy rzeczy razem i zaktualizuj odpowiednio specs.”

Kiedy stosować:

Po zakończeniu feature work
Przed stworzeniem MR/PR
Gdy kod działa ale wiesz że nie jest clean

Follow-up (P1): Włączmy tryb reviewera. Teraz jesteś principal level engineer.

Zrób to piece by piece:

Najpierw: możliwości refactoringu
Potem: failing specs
Następnie: błędy lintingu
Na koniec: możliwości konsolidacji

Uwaga: Nie rób one-shot review. Incremental steps dają lepsze wyniki.

Prompt: „Zbadaj to i daj mi znać, co się pojawia.”

Kiedy stosować:

Gdy coś działa, ale nie rozumiesz jak
Przed refactoringiem nieznanego kodu
Gdy debugujesz cudzą implementację

Kontekst: Duo samo poprosiło P1 żeby to zrobił. Dobry pattern – AI czasem wie czego potrzebuje.

Anty-pattern: co NIE zadziałało

Prompt: „Nie chcę żebyś robił pracę. Chcę żebyś przeprowadził mnie przez to krok po kroku.”

Problem: AI zignorowało i zrobiło wszystko naraz.

Lepsza alternatywa: Dawaj pojedyncze, bardzo konkretne zadania. „Zaktualizuj hover state dla zagnieżdżonych itemów” zamiast „przeprowadź mnie przez aktualizację całego komponentu”.

Prompt: (zbyt długie, szczegółowe wymagania na raz)

Problem: P2 dał AI dump wszystkiego: Figma comps, requirements, repo access. AI się zapętliło w CSS.

Lekcja: Moje następne podejście – niech idzie trochę bardziej krok po kroku. W ten sposób łatwiej jest cofnąć się.

Meta-prompt pattern

Uniwersalny szablon który często działał:

[Context: co próbujesz osiągnąć]
[Constraint: czego AI NIE powinno robić / co powinno re-use]
[Specific task: konkretny, pojedynczy krok]
[Verification: jak sprawdzisz czy działa]

Przykład:

Context: Dodajemy nested dropdown do Pajamas disclosure component
Constraint: Użyj istniejących disclosure dropdown patterns, nie twórz nowego CSS
Task: Dodaj hover state który otwiera nested menu po 200ms
Verification: Przetestuj w Storybook z keyboard navigation

Kluczowe wnioski o promptowaniu z sesji

Konkret > abstrakcja – Użyj chevron-right icon lepsze niż użyj odpowiedniej ikony
Re-use > net-new – Zawsze explicite każ AI szukać istniejących rozwiązań
Small steps > big bang – Łatwiej wrócić z jednego kroku niż z 10
Positive reinforcement works – Dobra robota nie jest głupie
AI czasem kłamie że zrobiło – Zawsze weryfikuj (myśli że zrobiło)
Repo access ≠ automatic awareness – Musisz kazać AI sprawdzić samemu
Fresh session > walka z exhaustion – Nie upieraj się przy umierającym wątku

Kluczowy insight

AI struggle = Twój code smell

Standardowo myślimy: Jeśli AI przez godzinę walczy z moim kodem CSS/TypeScript/whatever i nie może go zrozumieć, to znaczy, że model jest za słaby. Trzeba czekać na lepsze modele.

W praktyce okazuje się, że: Jeśli AI przez godzinę walczy z Twoim kodem, prawdopodobnie Twój kod jest za trudny także dla nowych ludzi w zespole. AI działa jak canary in the coal mine dla code complexity.

Dlaczego to jest istotne: P1 zauważył: jeśli chcemy, żeby AI pomogło przyspieszyć workflows i nie może nawet zrozumieć naszego obecnego CSS na tyle, by go replikować, to może są tam rzeczy, które są po prostu zbyt złożone. To odwraca perspektywę z AI musi się poprawić na może nasz kod musi się poprawić. Implikacje: lepszy onboarding, mniej bugów, łatwiejszy maintenance.

Test na jutro: Następnym razem, gdy AI zapętla się na Twoim kodzie (CSS inheritance, nested logic, complex state), zamiast walczyć z modelem, spróbuj zapytać doświadczonego juniora, czy to jest dla niego intuicyjne i sprawdź, czy odpowiedź brzmi podobnie jak AI feedback. Jeśli tak – masz kandydata do refactoringu.

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ć. Materiał źródłowy to wewnętrzna sesja pair programming zespołu GitLab, nagranie przeznaczone do celów edukacyjnych.Merge request: Add nested dropdown

Tag: Pair Programming

Vibe Coding z GitLab Duo: Dwugodzinna bitwa o nested dropdown #EN350