Codex budował, Claude sprawdzał. A ja nie zgodziłem się na kolejny zielony
· · Nie jednym promptem · odcinek 11 · Read in English
"Zniechęca i daje paździerzem". Tak Maciek podsumował ekran wyboru historyjek w naszej grze. I miał rację 😂
Ale od początku. W 2016 roku zrobiliśmy w trójkę - Magda, Maciek i ja - Agile ZOO, grę dla Product Ownerów. Powstała na szkolenia wewnętrzne w GetResponse (tu jest o niej więcej), a potem pokazywaliśmy ją z Maćkiem na Agile by Example. Zespół prowadzi ZOO przez trzy sprinty. Każdy gracz opiekuje się jednym obszarem - Afrykarium, Ptaszarnią, Oceanarium albo Insektarium - i każdy zna problemy swojego obszaru. A budżet punktów jest jeden, wspólny. Słoń potrzebuje lekarza, flamingi nowego wybiegu, prąd nie jest zapłacony od trzech miesięcy... i trzeba się dogadać. Po sprincie przychodzą (albo odchodzą) odwiedzający, a gazeta pisze, co z tego wyszło.
Jakiś czas temu Maciek z pomocą AI przeniósł grę na nowego Laravela, bo wersja z 2016 roku wymagała PHP, którego nie udało się uruchomić na moim starym serwerze. W październiku Claude przepisał ją z Laravela na nowy stos, 1:1 z oryginałem - sprawdzaliśmy to na 504 grach wzorcowych puszczonych przez stary kod PHP. Do tego doszło animowane ZOO w 3D na stronie głównej. Gra działała jak w 2016. I tak samo wyglądała.
Wersja na warsztaty
W v1 ekran ma tylko trener. Wyświetla go na rzutniku i klika za wszystkie zespoły. W v2 chcieliśmy dać wybór - od wszystkiego robionego przez trenera, po grę zdalną, w której każdy uczestnik klika u siebie. Prowadzący zakłada sesję, uczestnicy dołączają telefonem przez kod QR, każdy dostaje swój obszar, zespół planuje wspólny budżet na żywo, a na rzutniku leci zegar i wyniki.
Tym razem budował Codex (GPT Sol 6.1). I muszę przyznać - zaczął jak porządny zespół. Najpierw dokumenty: produkt, architektura, jedenaście pakietów zadań. Po każdym pakiecie raport z odbioru - co działa, czego nie sprawdzono, zrzuty ekranu.
Funkcjonalnie szło dobrze. Wizualnie... było lepiej niż v1. Ale nie DRAMATYCZNIE lepiej. A po zdaniu Maćka o paździerzu nie chciałem "trochę lepiej".
Jeden projektuje, drugi buduje
Poprosiłem Claude'a o projekt wyglądu v2 - komendą /design prosto w Claude Code, a nie w osobnym Claude Design. Robi robotę i dużo chętniej z niej korzystam 🙂 Było tylko jedno zastrzeżenie - "sam nie zmieniaj wyglądu gry". Codex był w środku pracy, w tym samym repozytorium, i nie chciałem dwóch agentów edytujących te same pliki.
Claude zrobił dziesięć ekranów: planowanie na komputerze i telefonie, dołączanie przez QR, ekran prowadzącego, ekran na rzutnik, wyniki jako "Kurier ZOO". Do tego paczkę dla Codexa - kolory jako gotowe zmienne CSS, specyfikację każdego komponentu i rendery wysp z tej samej sceny 3D, która jest na stronie głównej. Pasek budżetu, na którym każde zadanie to kolorowy kawałek w barwie obszaru, to był jego pomysł.
Pierwsza wersja była zielona. Oczywiście 🙂
Napisałem: "sorry, ale nie zgadzam się na kolejny zielony kolor... Żadnego zielonego dominującego!". Zielone są grafiki tego cyklu, zielona jest połowa aplikacji, które widzę. Poszliśmy w przygaszony granat, szarości, niebieski dla "gotowi" i czerwień dla głównej akcji. A potem jeszcze czcionka - "mniej popularna, pasująca do gry". Wyszedł Unbounded do nagłówków i liczb, szeroki i zaokrąglony, trochę jak z planszówki.
To są decyzje, których żaden agent nie podejmie za mnie. Mogą zaproponować pięć wariantów. Ale to ja wiem, że mam dość zieleni.
Wydanie o pierwszej w nocy
Codex wdrożył projekt i dokończył resztę v2. Wydanie poszło w nocy, około 1:00, gdy ja smacznie spałem.
Za pierwszym razem API przestało odpowiadać. Restrykcyjne uprawnienia przy instalacji pakietu - usługa nie mogła przeczytać własnych plików. Automatyczny rollback... też nie wstał, z tego samego powodu. Codex poprawił uprawnienia, druga próba zatrzymała się na jego własnej kontroli nagłówków, trzecia przeszła. Stara gra działała dalej, żadna zapisana partia nie zginęła.
I tu duży plus - wszystko to jest opisane w raporcie z wydania. Bez upiększania, z kopią zapasową bazy przed każdą próbą i nową bramką w skrypcie, żeby to się nie powtórzyło. Taki raport chciałbym dostawać od każdego, nie tylko od agenta.
Mały minus - cztery commity poszły prosto na główną gałąź, bez pull requesta. Wcześniejsze osiem zmian w tym repo szło przez PR. CI było zielone, tylko nikt poza autorem nie patrzył na kod przed produkcją. To pokazuje, jak ważne jest przygotowanie repo do pracy z agentami, a ja tym razem nie poświęciłem temu wystarczająco uwagi.
Review, czyli drugi agent sprawdza pierwszego
Rano poprosiłem Claude'a o code review i przegląd designu. Nie tylko czytanie kodu - rozegranie sesji. Postawił lokalnie osobny serwer i zagrał: cztery zespoły, czternastu graczy, prowadzący i ekran na rzutnik. Na tym samym etapie, na którym Codex skończył testy.
Testów było naprawdę dużo - 797 w backendzie, 65 we frontendzie, 7 scenariuszy w dwóch przeglądarkach. Wszystkie zielone. A mimo to:
- Kliknięcie gracza potrafiło przepaść. Cały pokój ma jeden licznik zmian. Jeśli ktokolwiek w sali coś kliknął w ciągu ostatnich dwóch sekund, Twój wybór odpada z konfliktem. Przy czterech osobach do testu to rzadkość. Przy szesnastu, które planują jednocześnie - norma. A komunikat brzmiał "Sesja zmieniła się w innej karcie" i na telefonie pokazywał się poza ekranem. Gracz widzi tyle, że kliknął i nic się nie stało.
- Zamknięcie karty = utrata miejsca. Tożsamość gracza żyła tylko w bieżącej karcie przeglądarki. Telefon ubije kartę w tle i prowadzący musi przydzielać kogoś od nowa, przy całej sali.
- Ekran na rzutnik był stroną internetową. Z nagłówkiem, stopką i tabelą, którą z dalszych rzędów trudno przeczytać. Nad wynikami wciąż wisiał napis z planowania.
- Na telefonie, na ekranie planowania, nie było ani jednej historyjki. Trzeba było przewinąć prawie dwa ekrany. Czyli dokładnie ten ekran, o którym Maciek mówił "paździerz" 😮
Żadna z tych rzeczy nie łamie testów, bo testy sprawdzały to, co ktoś przewidział. Dopiero symulacja sali pokazała, jak to się zachowa, kiedy ludzie robią rzeczy jednocześnie.
Nie znaczy to, że Claude jest "lepszy" od Codexa. Gdyby zamienić ich rolami, pewnie to Codex znalazłby coś u Claude'a. Każdy model czegoś nie zauważa, tylko każdy czego innego. Ten, kto buduje, testuje to, co sam zaprojektował. Ten, kto sprawdza, przychodzi bez tego bagażu. Dokładnie jak w zespole ludzi.
Poprawki i co dalej
Raport z review miał czekać na Codexa. W końcu poprawki wprowadził Claude - jeszcze tego samego dnia i tym razem przez pull request. Kliknięcia z kilku telefonów naraz już nie giną. Miejsce w zespole przeżywa zamkniętą kartę, a link z QR proponuje "Wróć do gry". Ekran na rzutnik ma własny układ 16:9, z zegarem i wynikami jako paski gości plus Kurier ZOO. Na telefonie zadania widać od razu, na pierwszym ekranie. Do testów doszły przypadki, których wcześniej nikt nie przewidział - na przykład dwa telefony jednego zespołu klikające w tej samej chwili.
Gdy czytasz ten wpis, gra działa już na agilezoo.pl i domyślnie otwiera się v2. Gdyby na warsztacie coś poszło nie tak, można wrócić do v1. Bo zielone testy mówią, że kod robi to, co miał robić. Nie mówią, czy ludzie przy stole będą się dobrze bawić 😉
Co to znaczy dla Twojego zespołu: jeśli kod pisze agent, niech sprawdza go inny - inny model albo przynajmniej świeża sesja bez kontekstu autora. I niech nie tylko czyta kod, ale uruchomi produkt w warunkach zbliżonych do prawdziwych, z wieloma użytkownikami naraz. A decyzje, których nie da się sprawdzić testem - kolor, ton, co pokazać na pierwszym ekranie - zostają przy człowieku. W ANSLAN tak właśnie przygotowujemy projekty do pracy z agentami AI.
Agile ZOO jest za darmo na agilezoo.pl (i po angielsku na agile-zoo.com).