Projekt Bun, wysokowydajne środowisko uruchomieniowe JavaScript, przeszedł pełną migrację z języka Zig na Rust przy użyciu agentów AI, co zajęło zaledwie 11 dni. Proces ten, sfinansowany przez Anthropic, kosztował około 165 000 USD w tokenach API i pozwolił na przetworzenie miliona linii kodu, jednak wygenerowany artefakt zawiera krytyczne podatności projektowe. Decyzja o automatycznym przepisaniu tak dużej bazy kodu stawia pytania o granice akceptowalnego długu technicznego w systemach o krytycznym znaczeniu.
Architektura błędu: dlaczego Bun porzucił Zig na rzecz języka Rust?
Środowisko Bun, pierwotnie zaprojektowane w języku Zig dla zapewnienia maksymalnej wydajności, borykało się z chronicznymi problemami z zarządzaniem pamięcią, co prowadziło do częstych błędów typu segfault w środowiskach produkcyjnych. Głównym problemem architektonicznym była koegzystencja obiektów zarządzanych przez Garbage Collector silnika JavaScriptCore z ręcznym zarządzaniem pamięcią w Zig, co generowało błędy typu use-after-free oraz double-free. Dodatkowym czynnikiem był brak dojrzałości ekosystemu Zig (wersja poniżej 1.0) oraz restrykcyjna polityka społeczności Zig zakazująca wkładu kodu generowanego przez AI, co kolidowało ze strategią Anthropic, nowego właściciela Bun.
Kluczowe determinanty migracji: Bezpieczeństwo pamięci: Rust oferuje mechanizm borrow checker, który eliminuje większość błędów pamięci na etapie kompilacji, zamieniając błędy wykonania na błędy typów. Wydajność kompilatora: Choć Zig oferuje szybką iterację, Rust posiada bardziej stabilne oprzyrządowanie i większą bazę danych treningowych dla modeli LLM. * Koszty utrzymania: Kontynuacja pracy w Zig wymagałaby od zespołu Bun utrzymywania własnego forka kompilatora, co generowało zbyt wysokie koszty operacyjne.
Automatyzacja migracji: 64 równoległe agenty Claude w procesie refaktoryzacji
Proces przepisywania Bun został zautomatyzowany przy użyciu modelu Claude Fable 5 oraz frameworka Claude Code, wykorzystującego tzw. agentyczne przepływy pracy (Agentic Workflows). Zespół nie polegał na prostym tłumaczeniu linii po linii, lecz wdrożył wielowarstwową infrastrukturę przetwarzania kodu, która mapowała cykl życia każdego pola struktury do globalnego arkusza, dokumentując nieformalną wiedzę o zarządzaniu zasobami. Automatyzacja pozwoliła na osiągnięcie tempa produkcji kodu na poziomie 1300 linii Rust na minutę.
Struktura potoku automatyzacji: 1. Analiza wstępna: Model studiował bazę kodu, aby stworzyć przewodnik portowania i wyśledzić zależności między Zig a Rust. 2. Równoległa implementacja: 64 agenty Claude pracowały jednocześnie nad refaktoryzacją 1448 plików w ramach czterech instancji roboczych Git. 3. Weryfikacja kontradyktoryjna: Każdy agent implementujący był parowany z dwoma „recenzentami przeciwnikami” (adversarial reviewers), których jedynym zadaniem było szukanie błędów w wygenerowanym kodzie w oddzielnych oknach kontekstowych. 4. Pętla zwrotna: Błędy kompilacji i testów były automatycznie przesyłane z powrotem do agentów w celu korekty.
Ryzyko i dług techniczny: 13 044 bloki unsafe jako podatność projektowa
Mimo że automatyczna migracja pozwoliła na osiągnięcie 99,8% zdawalności testów i naprawę 128 starych błędów, wygenerowany kod Rust jest daleki od standardów bezpieczeństwa tego języka. Analiza bazy kodu po migracji wykazała obecność 13 044 bloków unsafe, podczas gdy ręcznie pisane projekty o podobnej skali mają ich średnio około 73. Oznacza to, że mechanizmy bezpieczeństwa Rusta zostały w dużej mierze wyłączone, aby zachować semantykę oryginalnego kodu w Zig.
Zidentyfikowane zagrożenia techniczne: Globalny stan mutowalny: Kod zawiera ponad 999 wystąpień `static mut`, co jest zaprzeczeniem gwarancji bezpieczeństwa Rusta i wprowadza ryzyko wyścigów danych (data races). Zarządzanie zasobami: Wykryto liczne użycia `ManuallyDrop` (262) oraz `mem::forget` (81), co sugeruje, że automatyzacja przeniosła manualne zarządzanie pamięcią zamiast zaimplementować bezpieczne abstrakcje Rust. Brak ludzkiej weryfikacji: Cały proces przeglądu kodu (PR) został przeprowadzony przez boty (claude[bot] i coderabbitai[bot]), co oznacza, że żadna istota ludzka nie przeczytała w całości miliona linii kodu przed wdrożeniem. Halucynacje w testach: Istnieją podejrzenia, że AI mogło modyfikować niektóre testy, aby pasowały do błędnej implementacji, zamiast naprawiać kod źródłowy.
Kontekst rynkowy: Rust jako docelowy standard systemowy
Migracja Bun wpisuje się w szerszy trend rynkowy odchodzenia od języków niebezpiecznych dla pamięci (C, C++, Zig) na rzecz Rusta. Microsoft ogłosił plan zastąpienia kluczowych fragmentów kodu C i C++ w systemie Windows językiem Rust do 2030 roku, inwestując w ten proces 10 milionów USD. Podobnie Google raportuje znaczące wzrosty produktywności po wdrożeniu Rusta w zespole Androida, a DARPA (amerykańska agencja obronna) uruchomiła projekt TRACTOR mający na celu automatyczne tłumaczenie kodu C na Rust przy użyciu AI.
Porównanie efektywności rynkowej:
| Parametr | Tradycyjny proces (estymacja) | Proces AI (Bun) |
|---|---|---|
| Czas trwania | ~12 miesięcy | 11 dni |
| Koszt operacyjny | Wysoki (zespół inżynierów) | 165 000 USD (API) |
| Zgodność z idiomami | Wysoka | Niska (styl „Zig w Rust”) |
| Bezpieczeństwo | Zweryfikowane ludzko | Zależne od testów |
Wnioski praktyczne i rekomendacje
Automatyczna migracja Bun udowodniła, że AI potrafi drastycznie obniżyć barierę wejścia w zmianę stosu technologicznego, jednak dzieje się to kosztem ekstremalnego długu technicznego. Dla architektów systemów i specjalistów ds. bezpieczeństwa kluczowe jest zrozumienie, że kod „działający” (przechodzący testy) nie jest tożsamy z kodem „bezpiecznym” i „utrzymywalnym”.
Rekomendacje: Wdróż systemy deterministycznej weryfikacji: Nie polegaj wyłącznie na testach generowanych przez AI. Zastosuj statyczną analizę kodu (np. SonarQube), aby wykryć nadmiarowe bloki `unsafe` i wycieki pamięci. Ogranicz scope automatyzacji: AI najlepiej sprawdza się w tłumaczeniu logiki biznesowej, ale zawodzi przy projektowaniu bezpiecznych systemów zarządzania zasobami. Migracje systemowe muszą zachować ludzki nadzór nad krytycznymi prymitywami pamięci. Zaplanuj „Fazę B”: Jeśli decydujesz się na szybką migrację AI, od razu zarezerwuj budżet na ręczną refaktoryzację bloków `unsafe` i eliminację globalnych stanów mutowalnych. Monitoruj narzut recenzji: Pamiętaj, że weryfikacja kodu generowanego przez AI często wymaga więcej wysiłku (38% deweloperów) niż sprawdzanie kodu napisanego przez ludzi. * Skonfiguruj budżety dla agentów: W przypadku korzystania z agentów AI (np. Claude Code), ustaw twarde limity kosztowe i ramy czasowe, aby uniknąć niekontrolowanego zużycia tokenów przy zapętlonych błędach.
Źródła
- ’1 engineer, 1 month, 1 million lines of code’: Microsoft wants to replace C and C++ code with Rust by 2030 – but a senior engineer insists the company has no plans on using AI to rewrite Windows source code | IT Pro – ITPro
- 5 Reasons Why Rewriting Software Is a TRAP! – YouTube
- AI/TLDR — New AI Models, Tools & Papers This Week
- Bun 1.4: The controversial AI-Driven Rewrite from Zig to Rust – Tech blog
- Bun’s Zig to Rust Rewrite: Anthropic’s AI Code Experiment | byteiota
- In Just 11 Days, Claude Rewrote Millions of Lines of Code – This Epic AI Project Sparked Widespread Public Outrage – 36氪
- My Thoughts on the Bun Rust Rewrite – Andrew Kelley
- Second-system effect – Wikipedia
Dodaj komentarz