Analiza, plan, kod, kontrole: nasz rytm pracy z AI 🤖

Nigdy nie ukrywaliśmy, że przy Blocks Beyond The Stars mocno korzystamy z AI — bez niej gra tej wielkości po prostu nie dałaby się zrobić po godzinach. Ale dla nas „tworzenie z AI” nie znaczy: wpisać życzenie, wziąć wynik i liczyć na szczęście. Przez miesiące wykształcił się stały schemat, który brzmi zaskakująco staroświecko — i działa właśnie dlatego. Dziś przedstawiamy go w całości.

Zawsze zaczyna się od człowieka i pomysłu. Zanim AI cokolwiek zrobi, ktoś czegoś chciał albo coś zauważył: gracz, który klawiszem opinii zgłasza, że zwierzęta pojawiają się w jego ścianach — albo my sami, gdy Justus w trakcie gry mówi, czego mu brakuje. AI nie wymyśla tu zadań. Dostaje je.

Potem AI pracuje w fazach. Są cztery, zawsze w tej samej kolejności: analiza, planowanie, implementacja, weryfikacja. (Piąty krok, ręczne testowanie, następuje potem — ale to znów zadanie człowieka, o tym za chwilę.) Najważniejszy trik polega na tym, czego AI nie wolno: od razu pisać kodu. AI, która od razu zaczyna pisać, z imponującą prędkością rozwiązuje zły problem. Dlatego każde większe zadanie zaczyna się od analizy — co już jest, gdzie naprawdę leży przyczyna, co jeszcze się z tym wiąże? Wynikiem jest tekst, nie kod.

Potem przychodzi plan — i ktoś go czyta. Po analizie następuje planowanie: które pliki zostaną ruszone, w jakiej kolejności, jakie pułapki są znane, które decyzje wciąż są otwarte? Właśnie tu wychodzą pytania, na które lepiej odpowiedzieć przed programowaniem („Czy to ma działać także w przeglądarce?”, „Co stanie się ze starymi zapisami?”). Dopiero gdy plan stoi, następuje implementacja — a ta często bywa najnudniejszą częścią całości. I tak właśnie powinno być.

Powiązane rzeczy idą w jednej paczce. Druga reguła, która oszczędza nam mnóstwo czasu: gdy kilka problemów jest podobnych lub powiązanych — pięć menu pada, które mają ten sam problem z fokusem, albo piętnaście ustaleń z tej samej rundy testów — AI dostaje je spakowane w jedno zadanie, nie w piętnaście osobnych. Musi wtedy przejść przez dotknięty kod tylko raz, rozwiązania pasują do siebie zamiast sobie przeczyć, i nic nie wypada między dwoma zadaniami.

Przed każdym wydaniem: dwie osobne rundy kontroli. Po każdym większym kroku pracy — a zawsze przed wypuszczeniem nowej wersji do was — jeszcze raz puszczamy AI na wynik. Ale w dwóch celowo oddzielnych dochodzeniach. Pierwsze: czy zamierzone funkcje i poprawki błędów naprawdę są całkowicie gotowe — czy gdzieś nie siedzi niedokończona resztka, zapomniany przypadek brzegowy, brakujące tłumaczenie? Drugie, w osobnym przebiegu: czy zmiany nie wywołały nowych problemów gdzie indziej? Wrzucenie obu do jednego pytania nie działa — kto jednocześnie poluje na luki i na szkody uboczne, znajduje po połowie z jednych i drugich. Zadane osobno, te dwa pytania oszczędzają nam ogromną ilość poprawek; spora część rzeczy, które w notatkach wydania pojawiają się jako „naprawione przy okazji”, pochodzi właśnie z tych rund kontroli.

I na samym końcu znów testuje człowiek. Piąty krok to nie faza AI, tylko nasza: ręczne testowanie znaczy prawdziwe granie. Świeżo zbudowana wersja, prawdziwy pad, prawdziwe dziecko grające. Mnóstwo rzeczy, które przeżywają każdą analizę, umiera w pierwszych pięciu minutach na kanapie. Bo czy coś dobrze się czuje, to pytanie, na które żadna analiza na świecie nie odpowie.

Przyjrzyjcie się uważnie, a w tym schemacie nie znajdziecie magii AI, tylko odwieczne rzemiosło inżynierskie: najpierw zrozumieć, potem zaplanować, potem zbudować, potem sprawdzić. A dla nas klamra wokół tego jest zawsze taka sama: człowiek ma pomysł, człowiek robi końcowy test — AI pracuje pomiędzy. Nowa jest tylko szybkość, z jaką ta pętla się kręci. 🔍