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

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

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.

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.

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.

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.

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ń.

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.

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.

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.

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 .

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.

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.

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.

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!”

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.

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.

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.

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.

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.

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.”

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.

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.

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

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?

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:

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ść.

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.

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.

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.

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ć

• 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)

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.

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.

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.

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

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.

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.

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ę.

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.

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:

1. Najpierw: możliwości refactoringu
2. Potem: failing specs
3. Następnie: błędy lintingu
4. 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.

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ę.

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

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

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