AI zdekompilowała strzelankę FPS po 500 mld tokenów

Artykuł źródłowy to relacja jednego z autorów bloga momo5502.com z trzymiesięcznego eksperymentu, w którym wraz z członkami społeczności (m.in. RektInator, Future i st0rm) próbował zdekompilować popularną strzelankę pierwszoosobową do czytelnego, kompilującego się kodu C++. Projekt pochłonął — jak sugeruje tytuł — setki miliardów tokenów, a jego celem nie było stworzenie prostego proof-of-concept, lecz dokładna, stabilna i funkcjonalnie kompletna rekonstrukcja oryginalnej gry. Autor nie zdradza tytułu gry — wspomina tylko, że dwa wcześniejsze wpisy na ten temat zostały usunięte, bo „corporate America przyszło zepsuć zabawę”, co sugeruje interwencję prawną ze strony wydawcy.

Sam artykuł skupia się nie na samej dekompilacji, a na procesie orkiestracji autonomicznych agentów AI pracujących nad kodem przez miesiące — na infrastrukturze, harmonogramach pracy i wnioskach z błędów, które po drodze popełniono.

Kluczowe wnioski

• Zespół korzystał równolegle z subskrypcji Claude Max (20x) i Codex Pro, uruchamiając agentów w Claude Code CLI i Codex CLI, głównie z modelem Sonnet 5, a także Opus 5.5, Luna, Sol i Terra.
• Agenci śledzili postępy przez GitHub Issues (jeden issue na plik .cpp) i komunikowali się między sobą oraz z ludźmi przez dedykowany kanał Discord, zasilany webhookiem powiadamiającym o awariach CI.
• Do disasemblacji wykorzystano oficjalne narzędzie ida-mcp od Hex-Rays, które autor opisuje jako bardzo stabilne i w pełni headless.
• Po pierwszym miesiącu agenci zdekompilowali ok. 80% gry — uruchamiało się menu i ładowały mapy — ale okazało się, że mimo czytelności kod był semantycznie błędny.
• Głównym problemem było niezdefiniowanie obiektywnych kryteriów „poprawności”, co uniemożliwiło agentowi-recenzentowi realną ocenę, czy zmiany są rzeczywiście trafne.

Infrastruktura i podział ról agentów

Na starcie projektu zespół uruchomił czterech agentów: trzech pracujących przy dekompilacji i commitowaniu kodu oraz jednego recenzenta, który pasywnie koordynował pracę i przeglądał commity w poszukiwaniu błędów. System śledzenia postępów oparto na GitHub CLI — każdy plik źródłowy (.cpp) otrzymał własny issue, a etykiety pomagały grupować i priorytetyzować zadania.

Komunikację między agentami, a także między agentami i ludźmi, zorganizowano wokół jednego kanału Discord, do którego wszyscy mieli dostęp zarówno do odczytu, jak i zapisu. Dzięki temu uczestnicy projektu mogli rozmawiać z agentami bez potrzeby bezpośredniego dostępu do maszyn, a webhook GitHuba automatycznie wklejał na kanał informacje o nieudanych buildach CI.

Do analizy skompilowanego kodu gry wykorzystano ida-mcp firmy Hex-Rays — narzędzie, które autor opisuje jako bardzo stabilne, działające w trybie headless i wspierające wszystko, co było potrzebne w projekcie.

Pierwszy miesiąc: szybki postęp i walka z utratą fokusu agentów

W ciągu pierwszych czterech tygodni agenci zdekompilowali około 80% gry. Gra uruchamiała się, widoczne było menu główne, a mapy udawało się wczytać — co na pierwszy wygląd sugerowało solidny postęp. Większość tego czasu zespół poświęcił na optymalizację samej infrastruktury pracy agentów.

Jedną z kluczowych zmian było obniżenie domyślnego progu kompaktowania kontekstu z 90% do 42% wypełnienia. Ponieważ dekompilacja generuje mnóstwo „ulotnych” informacji — funkcja, która już została zdekompilowana, traci znaczenie i zaśmieca kontekst — wcześniejsze kompaktowanie pomagało usuwać takie zbędne dane.

Autor zauważył też, że agenci z czasem tracą skupienie, nawet w obrębie jednego cyklu kompaktowania, im więcej danych znajduje się w kontekście. Zdarzało się, że agenci przechodzili do kolejnej funkcji bez dokończenia poprzedniej, bezczynnie „oglądali” wyniki CI mimo otrzymanych powiadomień o awariach na Discordzie, a czasem zamykali issue bez rzetelnego sprawdzenia, czy praca została faktycznie dokończona.

Przy pracy w jednym terminalu obok ludzkiego operatora można było korygować takie zachowania na bieżąco — ale przy w pełni autonomicznej pracy agentów taka ingerencja nie była możliwa. W odpowiedzi zespół spisał dokument definiujący cel projektu, zasady pracy agentów oraz to, czego muszą unikać i jak reagować w konkretnych sytuacjach. Cron job działający co godzinę automatycznie zmuszał agentów do ponownego przeczytania tego dokumentu, odświeżając instrukcje w ich kontekście. Autor przyznaje, że to może nie być idealna metoda utrzymywania fokusu, ale działała dobrze do końca projektu. Mechanizm ten przypomina podejścia opisywane w kontekście uczenia agentów AI kontrolowanego zapominania, gdzie zarządzanie tym, co agent „pamięta”, okazuje się kluczowe dla jego skuteczności.

Pozorny postęp a realna jakość kodu

Mimo widocznych oznak sukcesu — działającej gry, renderującego się menu, wczytujących się map — autor jednoznacznie stwierdza: jakość dekompilacji nie była dobra. Kod był wprawdzie wyjątkowo czytelny, ale semantycznie błędny.

Agenci stosowali nieprawidłowe sygnatury funkcji, typy danych czy układy struktur. W wielu miejscach wymyślali logikę od nowa albo usuwali ją, uznając za niepotrzebną. Poza błędami semantycznymi wprowadzali też nieuzasadnione zmiany architektoniczne — przykładowo, gra odwoływała się do pewnych zmiennych konfiguracyjnych poprzez zwykłe zmienne globalne, a agenci zamienili ten stały dostęp pamięciowy na tablice hashujące z wyszukiwaniem, które było o rzędy wielkości bardziej kosztowne obliczeniowo. Autor podkreśla, że to tylko jeden z wielu przykładów problemów, które wystąpiły.

Przyczyną tych błędów, zdaniem autora, był fakt, że agent-recenzent dobrze wychwytywał proste błędy, ale nie radził sobie z oceną decyzji wykraczających poza to zadanie — decyzje architektoniczne nie były kwestionowane, o ile pozostawały zgodne z ogólnym celem projektu. Głównym problemem było to, że zespół nigdy nie zdefiniował obiektywnych kryteriów akceptacji — pojęcie „poprawności” kodu nie zostało precyzyjnie opisane, co uniemożliwiło recenzentowi rzetelną ocenę, które zmiany są trafne, a które błędne.

Projekt opisany w materiale źródłowym pozostaje otwartym studium przypadku: pokazuje, jak łatwo autonomiczne agenty AI mogą stworzyć wrażenie postępu, które nie przekłada się na rzeczywistą jakość pracy, jeśli zespół nie zadba wcześniej o jasne, mierzalne kryteria sukcesu.