OpenAI Codex stworzył kompletną 16-bitową grę DOS w asemblerze x86 w stylu Asteroids, dostarczając 18 plików źródłowych i około 2500 linii kodu bez ani jednej linii napisanego przez człowieka asemblera. Eksperyment pokazuje, że AI potrafi zarządzać pełnym cyklem życia oprogramowania – od planowania po debugowanie – wykraczając poza typowe demonstracje typu „code-completion”.

Dlaczego ten test był istotny

Większość publicznych pokazów programowania z użyciem AI kończy się na małych fragmentach kodu lub prostych narzędziach. Aby zbadać górną granicę możliwości, eksperyment zmusił Codex do pracy w najbardziej ograniczonym środowisku, jakie można sobie wyobrazić: 16-bitowym asemblerze x86 na systemie DOS, bez silników gier, bibliotek graficznych czy wygód języków wysokiego poziomu. Celem było sprawdzenie, czy AI potrafi nie tylko generować kod, ale także zarządzać towarzyszącymi mu zadaniami inżynieryjnymi.

Jak podzielono role

Odpowiedzialność człowieka ograniczała się do trzech działań:

  • Zdefiniowanie ogólnego celu projektu (strzelanka w stylu Asteroids).
  • Odpowiadanie na wszelkie pytania dotyczące rozgrywki.
  • Testowanie każdej wersji gry i zgłaszanie wykrytych błędów.

Odpowiedzialność Codexu obejmowała wszystko inne:

  • Opracowanie planu projektu i architektury.
  • Napisanie plików źródłowych w asemblerze.
  • Debugowanie, refaktoryzacja i restrukturyzacja kodu.
  • Zarządzanie repozytorium Git, w tym commitami i zarządzaniem gałęziami.
  • Budowanie pliku binarnego i uruchamianie go w emulatorze DOS.

Człowiek nigdy nie wpisał ani jednej instrukcji asemblera, nigdy nie wywołał kompilatora i nigdy nie uruchomił gry podczas procesu tworzenia. Interakcja ograniczała się do opisywania objawów błędów; AI samodzielnie lokalizowało i naprawiało ich przyczynę.

Iteracyjny proces pracy

Każdy cykl zaczynał się od zaproponowania przez Codex kamienia milowego (np. „wdrożenie ruchu statku gracza”). Następnie generował on odpowiednie pliki źródłowe, zatwierdzał je (commit), budował plik wykonywalny i przekazywał gotową wersję testerowi. Codex analizował objawy, śledził je w kodzie źródłowym i wydawał poprawkę bez dalszych wskazówek ze strony człowieka.

Co zawiera końcowy produkt

  • 18 plików źródłowych w asemblerze, zorganizowanych w konwencjonalną strukturę repozytorium.
  • ≈2500 linii asemblera, obejmujących obsługę wejścia, rysowanie sprite'ów, wykrywanie kolizji oraz system wyników (high-score).
  • Grywalny plik wykonywalny DOS, który działa w standardowym środowisku DOS i naśladuje klasyczną rozgrywkę Asteroids.
  • Zero linii asemblera napisanego przez człowieka, co potwierdza, że AI poradziło sobie ze wszystkimi zadaniami programowania niskopoziomowego.

Stawka i implikacje

Jeśli AI może autonomicznie prowadzić projekt od koncepcji do działającego pliku binarnego, tradycyjna rola programisty jako głównego koordynatora bazy kodu ulega zmianie. Firmy mogłyby skrócić czas poświęcany na przygotowanie szkieletów kodu (boilerplate), dokumentację i rutynowe debugowanie, uwalniając inżynierów do skupienia się na projektowaniu i strategii produktu.

Eksperyment uwypukla również ograniczenia. Środowisko testowe było celowo wąskie: gra DOS dla jednego gracza z dobrze znaną mechaniką. Skalowanie tego podejścia do dużych, wielomodułowych systemów z zewnętrznymi zależnościami, ograniczeniami bezpieczeństwa lub krytycznymi pod kątem wydajności ścieżkami kodu pozostaje niepotwierdzone. Co więcej, człowiek-tester wciąż pełnił rolę ostatecznej bramki jakości; niewykryty błąd logiczny mógłby zostać przepuszczony bez tej nadzorczej funkcji.

Kontrargumenty i otwarte pytania

  • Niezawodność: Programowanie w asemblerze nie wybacza błędów; pojedynczy błąd typu „off-by-one” może spowodować awarię całego programu. Codex naprawiał błędy, które widział, ale może przeoczyć subtelne problemy z czasem (timing), które pojawiają się tylko podczas testów obciążeniowych.
  • Utrzymywalność: Kod generowany bez ludzkich wytycznych dotyczących stylu może być trudniejszy do odczytania lub rozbudowy przez przyszłych programistów, zwłaszcza jeśli konwencje nazewnictwa AI będą różnić się od standardów zespołu.
  • Własność intelektualna: Kto jest właścicielem kodu, gdy pisze go AI? Obecne ramy licencyjne zakładają autorstwo człowieka, pozostawiając szarą strefę dla artefaktów wyprodukowanych przez AI.

Na co warto zwrócić uwagę w przyszłości

  • Szersze benchmarki: Zastosowanie tego samego autonomicznego przepływu pracy do aplikacji sieciowych, aplikacji mobilnych lub nowoczesnych projektów C/C++ sprawdzi, czy podejście to skaluje się poza gry w stylu retro.
  • Integracja narzędzi: Osadzenie Codexu w potokach CI/CD mogłoby zautomatyzować nie tylko generowanie kodu, ale także testowanie, skanowanie bezpieczeństwa i wdrażanie.
  • Ewolucja polityk: W miarę rozprzestrzeniania się kodu generowanego przez AI, polityki prawne i korporacyjne będą musiały zająć się kwestiami własności, odpowiedzialności i zgodności (compliance).

Wniosek jest oczywisty: AI może obecnie pełnić rolę samodzielnego inżyniera oprogramowania w przypadku dobrze zdefiniowanych, ograniczonych projektów, dostarczając funkcjonalny kod niskopoziomowy bez konieczności ręcznego kodowania przez człowieka. To, czy ta zdolność przekształci główny nurt rozwoju oprogramowania, zależy od tego, jak szybko ekosystem rozwiąże kwestie niezawodności, utrzymywalności oraz obaw prawnych.