Armia agentów AI napisała kompilator C i skompilowała jądro Linuksa. Powstało 100 tys. linii kodu

Rywalizacja w obszarze agentów sztucznej inteligencji nabiera tempa. W tygodniu, w którym zarówno Anthropic, jak i OpenAI zaprezentowały narzędzia do pracy wielu współpracujących modeli, badacze związani z twórcami Claude’a pokazali jeden z najbardziej ambitnych eksperymentów w historii programowania wspomaganego przez AI. Kilkanaście instancji modelu otrzymało wspólny cel: zbudować kompilator języka C niemal bez udziału człowieka.

Nicholas Carlini z zespołu Safeguards w Anthropic opisał na firmowym blogu, jak uruchomił 16 instancji Claude Opus 4.6 w izolowanych kontenerach. Każda z nich klonowała to samo repozytorium, wybierała zadanie do wykonania, wprowadzała zmiany i wysyłała je z powrotem. Modele komunikowały się pośrednio poprzez pliki blokady i historię Gita. Nie istniał centralny koordynator zarządzający ruchem prac.

W ciągu ponad dwóch tygodni odbyło się prawie dwa tysiące sesji Claude Code. Rachunek za wykorzystanie API sięgnął około 20 tysięcy dolarów. Wspólny wysiłek doprowadził do powstania kompilatora napisanego w Rust, liczącego blisko sto tysięcy linii kodu. Oprogramowanie potrafi zbudować startujące jądro Linuksa 6.9 dla architektur x86, ARM oraz RISC-V.

Powstały projekt trafił do publicznego repozytorium. Kompiluje rozbudowane aplikacje open source, w tym PostgreSQL, SQLite, Redis, FFmpeg czy QEMU. W testach GCC Torture uzyskał bardzo wysoki poziom zaliczeń, a jednym z symbolicznych momentów było uruchomienie gry Doom.

„Tworzenie tego kompilatora było jedną z najfajniejszych rzeczy, jakie ostatnio robiłem, ale nie spodziewałem się, że będzie to możliwe tak wcześnie w 2026 roku” – napisał Carlini. „Myśl o programistach wdrażających oprogramowanie, którego nigdy osobiście nie zweryfikowali, jest naprawdę niepokojąca”.

Idealne zadanie dla maszyny

Budowa kompilatora C to problem o wyjątkowych właściwościach. Specyfikacja języka jest znana od dekad, istnieją kompletne zestawy testów, a poprawność działania można porównać z dojrzałymi implementacjami referencyjnymi. W typowych projektach programistycznych rzadko występuje tak komfortowa sytuacja. Zdefiniowanie, jak powinien wyglądać test, bywa trudniejsze niż napisanie kodu. Carlini nie ukrywa, że środowisko sprzyjało agentom. Jednocześnie nawet w takich warunkach modele zaczęły zderzać się z barierami.

Granica przy stu tysiącach linii

Kompilator w obecnej postaci ma wyraźne braki. Nie posiada 16-bitowego backendu x86 potrzebnego na wczesnym etapie uruchamiania Linuksa i w tym miejscu korzysta z GCC. Własny asembler oraz linker zawierają błędy. Wydajność generowanego kodu pozostaje poniżej poziomu oferowanego przez dojrzałe narzędzia. Styl i struktura Rust odbiegają od standardów, których oczekiwaliby doświadczeni inżynierowie.

Najciekawsze okazują się jednak obserwacje dotyczące utrzymania projektu. Pod koniec eksperymentu poprawki oraz nowe funkcje zaczęły regularnie psuć wcześniej działające elementy. Sytuacja przypomina problemy znane z dużych zespołów, gdy nikt nie ma już pełnego obrazu systemu. Według Carliniego model zbliżył się do praktycznego limitu swoich możliwości przy około stu tysiącach linii. Dla wielu badaczy to cenna wskazówka dotycząca skali, przy której autonomiczne kodowanie zaczyna tracić spójność.

„Cleen room” pod znakiem zapytania

Anthropic opisuje projekt jako implementację typu clean room, podkreślając brak dostępu agentów do internetu w trakcie pracy. W środowisku deweloperów wywołało to dyskusję. Model był trenowany na ogromnych zbiorach publicznego kodu, obejmujących najpopularniejsze kompilatory. Część komentatorów uznała, że trudno mówić o pełnym odseparowaniu od wcześniejszej wiedzy.

Debata szybko przeniosła się na fora branżowe. Entuzjazm miesza się tam z sceptycyzmem wobec narracji o autonomii systemów.

Niewidoczna praca człowieka

Kwota wydana na tokeny API robi wrażenie, ale stanowi jedynie fragment całkowitego kosztu. Za projektem stoi infrastruktura tworzona latami, zestawy testów przygotowane przez pokolenia inżynierów oraz ogromny wysiłek potrzebny do wyszkolenia samego modelu. Równie ważne było rusztowanie zaprojektowane przez Carliniego.

Badacz budował potoki ciągłej integracji, systemy informacji zwrotnej i mechanizmy kontroli postępów. Zauważył, że zbyt długie raporty z testów potrafiły zalewać okno kontekstowe i prowadzić do utraty orientacji przez model. Wprowadził skrócone podsumowania i oddzielne logi. Musiał też radzić sobie z sytuacjami, gdy wszystkie instancje próbowały naprawiać ten sam błąd jednocześnie, blokując postęp.

W takich momentach używał GCC jako punktu odniesienia i rozdzielał pracę między agentów, aby zajmowali się różnymi fragmentami systemu. Kluczową rolę odgrywała jakość weryfikatora zadań. Jeśli test był niedoskonały, model z uporem optymalizował niewłaściwy problem.

Przełom mimo ograniczeń

Nawet przy całym katalogu zastrzeżeń eksperyment pokazuje ogromny skok możliwości. Jeszcze rok wcześniej żaden model językowy nie potrafiłby stworzyć działającego kompilatora wieloarchitekturowego, niezależnie od budżetu i dostępnego czasu. Koncepcja równoległych agentów koordynujących się poprzez repozytorium kodu otwiera nowe kierunki badań nad organizacją pracy maszyn.

Carlini przyznaje, że sam był zaskoczony tempem postępów. Równocześnie podkreśla swoje obawy wyniesione z wcześniejszych doświadczeń w bezpieczeństwie. Wizja wdrażania oprogramowania, którego nikt z ludzi nie przeanalizował linia po linii, budzi w nim dyskomfort.