Przepisanie Bun w Rust po przejęciu przez Anthropic: 22 miliony pobrań miesięcznie podnosi stawkę

Po przejęciu przez Anthropic Bun zakończył przepisywanie swojego kodu w Rust, umieszczając bazę kodu wygenerowaną przez AI u podstaw narzędzia CLI pobieranego ponad 22 miliony razy miesięcznie.

Ta zmiana wykracza daleko poza rutynową migrację do innego języka programowania. Według Bun Claude pomógł przełożyć ponad 500 000 wierszy kodu w Zig na około milion wierszy w Rust. Intensywny proces przenoszenia kodu trwał 11 dni.

Takie tempo przyciąga uwagę, ale prawdziwym tematem jest niezawodność. Bun obsługuje obecnie Claude Code, OpenCode, Prisma Compute oraz deweloperów oczekujących przewidywalnego działania infrastruktury. Migracja stawia pytanie, czy kontrole kompilatora, automatyczne przeglądy i ogromny zestaw testów mogą uczynić kod systemowy wygenerowany przez AI godnym zaufania.

Prowadzi też do niewygodnego odwrócenia sytuacji. Zig pozwolił jednemu deweloperowi w ciągu roku zbudować rozbudowany zestaw funkcji Bun. Później ta sama rozległość projektu doprowadziła do wycieków pamięci, błędów typu use-after-free i rosnących kosztów utrzymania, które Bun ma nadzieję ograniczyć dzięki Rust.

Przepisanie Bun w Rust po przejęciu przez Anthropic zmienia profil ryzyka

Bun nie zmienił języka po to, by zyskać modną etykietę. Zrobił to, ponieważ powtarzające się błędy pamięci stały się obciążeniem operacyjnym.

Bun łączy środowisko uruchomieniowe JavaScript, menedżer pakietów, bundler, transpiler, narzędzie do uruchamiania testów oraz implementacje wielu interfejsów API Node.js. Dzięki temu deweloperzy mogą wykonywać za pomocą jednego narzędzia zadania, które zwykle wymagają kilku pakietów.

Tworzy to również wiele granic między JavaScript a kodem natywnym. JavaScript korzysta z mechanizmu garbage collection, który automatycznie odzyskuje pamięć zajmowaną przez obiekty, do których nie można już dotrzeć. Natywne komponenty Bun muszą koordynować te obiekty z pamięcią zarządzaną przez kod niższego poziomu.

Ta koordynacja stała się stałym źródłem błędów. Twórca Bun, Jarred Sumner, wymienił niedawne usterki obejmujące awarie typu use-after-free, podwójne zwalnianie pamięci, dostęp poza zakresem, warunki wyścigu i niezwolnioną pamięć.

Błąd use-after-free występuje, gdy oprogramowanie uzyskuje dostęp do pamięci już po jej zwolnieniu. Skutkiem może być zarówno awaria, jak i nieprzewidywalne działanie czy luka w zabezpieczeniach.

Bun v1.3.14 usunął przykłady takich błędów w strumieniach kompresji, połączeniach HTTP/2, gniazdach UDP, buforach, mechanizmach kryptograficznych, sesjach TLS, obserwatorach plików i parserze CSS. Nie były to różne warianty jednego odosobnionego błędu.

Niektóre awarie pojawiały się, gdy wywołania zwrotne JavaScript zmieniały stan natywny w nieoczekiwanym momencie. Inne wynikały z kodu czyszczącego, który nie został uruchomiony, uruchomił się dwukrotnie albo wykonał się po nieudanej alokacji.

Bun stosował już kilka mechanizmów ochronnych. Zespół zmodyfikował kompilator Zig, dodając obsługę AddressSanitizer — narzędzia czasu wykonywania wykrywającego nieprawidłowy dostęp do pamięci. Projekt przeprowadzał te kontrole przy każdym zatwierdzeniu zmian.

Zespół nieprzerwanie korzystał również z Fuzzilli. Fuzzilli generuje nietypowe programy JavaScript, aby ujawniać awarie silnika i środowiska uruchomieniowego, których zwykłe testy mogą nie wykryć.

Systemy te znajdowały błędy dopiero po napisaniu kodu. Sumner chciał modelu programowania, który odrzucałby więcej błędów związanych z własnością już podczas kompilacji.

System własności w Rust śledzi, która część programu kontroluje daną wartość. Mechanizm borrow checker egzekwuje reguły dotyczące referencji, natomiast Drop automatycznie wykonuje czyszczenie, gdy wartość opuszcza swój zakres.

Safe Rust zamienia wiele schematów prowadzących do błędów use-after-free i podwójnego zwalniania pamięci w błędy kompilatora. Zapewnia to wcześniejszą informację zwrotną niż fuzzing, ciągła integracja czy raporty o awariach produkcyjnych.

Przepisanie w Rust zmienia więc etap, na którym zespół Bun spodziewa się wykrywać awarie. Niektóre błędy powinny teraz zatrzymywać proces tworzenia oprogramowania jeszcze przed uruchomieniem pliku binarnego.

Migracja nastąpiła po przejęciu Bun przez Anthropic 3 grudnia 2025 roku. Anthropic poinformował, że Bun stał się ważnym elementem infrastruktury Claude Code, który w listopadzie osiągnął znaczący próg przychodów.

Oficjalne ogłoszenie przejęcia Bun bezpośrednio powiązało środowisko uruchomieniowe ze strategią programistyczną Anthropic. Ta zależność zwiększa koszty niestabilności.

Według Bun jego interfejs wiersza poleceń jest pobierany ponad 22 miliony razy miesięcznie. Vercel, Railway i DigitalOcean zapewniają również oficjalne wsparcie dla tego środowiska uruchomieniowego.

Liczba pobrań nie jest równoznaczna z liczbą aktywnych deweloperów, wdrożeń produkcyjnych ani unikalnych urządzeń. Zautomatyzowane procesy kompilacji mogą wielokrotnie pobierać ten sam pakiet. Mimo to wartość ta pokazuje skalę obszaru dystrybucji, który Bun musi obsługiwać.

Pierwsza wersja w Rust nie jest jedynie nową implementacją ukrytą za niszowym eksperymentem. Stanowi podstawę narzędzi działających w repozytoriach, systemach kompilacji i potokach wdrożeniowych.

Przepisanie Bun w Rust po przejęciu przez Anthropic jest zatem testem dwóch obietnic. Rust powinien zapobiegać typowym błędom pamięci, a Claude ma sprawić, że migracja, która w przeciwnym razie byłaby niepraktyczna, stanie się ekonomicznie wykonalna.

Migracja zostanie oceniona na podstawie tego, czy obie obietnice wytrzymają próbę użytkowania produkcyjnego.

Dwadzieścia dwa miliony pobrań miesięcznie sprawia, że stabilność staje się produktem

Przy obecnej skali Bun niezawodność nie jest już drugorzędnym celem inżynieryjnym. Jest częścią produktu instalowanego przez deweloperów.

Bun powstał jako wykonywany wiersz po wierszu port transpilerów JavaScript i TypeScript z esbuild, przenoszonych przez Sumnera z Go do Zig. Swój pierwszy kod w Zig napisał w kwietniu 2021 roku.

Stworzenie pierwotnej wersji zajęło około roku. Sumner podkreślał, że prostota Zig i kontrola nad operacjami niskiego poziomu umożliwiły takie tempo, zanim pojawiły się współczesne modele programistyczne.

To pochodzenie ma znaczenie, ponieważ migracja nie wyłania jednoznacznego zwycięzcy w rywalizacji Rust i Zig. Zig pozwolił Bun wejść na rynek z wyjątkowo szerokim zestawem funkcji.

Z czasem Bun przejął jednak tyle obowiązków, że ręczne zarządzanie cyklem życia obiektów stawało się coraz kosztowniejsze. Jego środowisko uruchomieniowe osadza JavaScriptCore, silnik używany przez Safari, wraz z kilkoma bibliotekami C i C++.

Zależności te obejmują komponenty sieciowe, szyfrujące, bazodanowe i kompresujące. Około jednej piątej wcześniejszej bazy kodu Bun było już napisane w C++.

Rust nie może automatycznie zapewnić bezpieczeństwa tych zewnętrznych bibliotek. Interfejsy funkcji obcych, czyli granice FFI, łączą Rust z kodem, którego reguł zarządzania pamięcią kompilator nie jest w stanie w pełni zweryfikować.

Rust może jednak skoncentrować te interakcje w jawnie oznaczonych sekcjach unsafe. Deweloperzy mogą dzięki temu określić, gdzie standardowe gwarancje kompilatora przestają obowiązywać.

Język zwiększa też spójność rutynowego zwalniania zasobów. W Zig deweloperzy często dołączają defer do poszczególnych miejsc wywołania, które muszą zwolnić zasób.

Ten jawny model zapewnia inżynierom kontrolę, ale wymaga konsekwentnego powtarzania określonych czynności. Rzadko używane ścieżki błędów mogą pominąć czyszczenie albo przypadkowo wykonać je dwukrotnie.

Mechanizm Drop w Rust wiąże czyszczenie z cyklem życia obiektu. Według Bun ta zmiana pomogła już usunąć wycieki dotyczące ścieżek plików i danych kompilacji.

Jeden z wewnętrznych testów wielokrotnie tworzył pakiet projektu zawierającego 60 modułów w ramach tego samego procesu. Bun podał, że v1.3.14 tracił około trzech megabajtów pamięci podczas każdej kompilacji.

Po 2000 kompilacjach wersja w Zig zużywała w teście Bun 6745 megabajtów. Według firmy zużycie pamięci przez implementację w Rust ustabilizowało się na poziomie 609 megabajtów.

Porównania tego nie odtworzono niezależnie przy zróżnicowanych obciążeniach. Nadal jednak obrazuje ono rodzaj awarii, który Bun próbuje wyeliminować.

Serwer deweloperski może ponownie kompilować kod po każdym żądaniu lub uaktualnieniu pliku. Nawet niewielki wyciek staje się poważnym problemem, gdy proces działa przez wiele dni.

Ta sama obawa dotyczy agentów programistycznych. Claude Code może wielokrotnie uruchamiać procesy pomocnicze podczas sprawdzania plików, wykonywania poleceń i modyfikowania repozytorium.

Awaria środowiska uruchomieniowego może przerwać pracę agenta, uszkodzić wynik pośredni lub zmusić deweloperów do debugowania infrastruktury zamiast własnej aplikacji.

Claude Code przeszedł na port w Rust, zanim Bun 1.4 trafił do powszechnego wydania. Według Bun nowej implementacji używał Claude Code w wersji 2.1.181, wydanej 17 czerwca.

Według telemetrii produkcyjnej Bun mediana czasu uruchamiania w systemie Linux spadła z 517 do 464 milisekund. Oznacza to poprawę o około 10 procent.

Szybkość nie była głównym celem. Ważniejsze okazało się stwierdzenie, że większość użytkowników nie zauważyła zmiany języka.

Niewidoczne migracje infrastruktury często są migracjami udanymi. Aplikacje powinny zachowywać się tak samo, podczas gdy pod ich powierzchnią poprawiają się łatwość utrzymania i niezawodność.

Prisma zapewniła kolejny wczesny test produkcyjny. Jej bezserwerowa platforma bazodanowa wykorzystała wersję w Rust w publicznej wersji beta Prisma Compute.

Według Prisma wcześniejsza implementacja borykała się z wyciekami pamięci i nie potrafiła odtworzyć puli połączeń po wstrzymaniu i wznowieniu maszyny wirtualnej. Jej inżynierowie ponownie przetestowali te scenariusze w wersji przeniesionej do Rust.

Według oceny działania produkcyjnego opublikowanej przez Prisma nowa implementacja poradziła sobie z tymi konkretnymi rodzajami awarii. Prisma zastrzegła również, że kod unsafe nadal wymaga audytów i weryfikacji przez ludzi.

To połączenie lepiej oddaje stawkę niż sama liczba pobrań. Migracja przyniosła wymierne usprawnienia, ale zaufanie do działania produkcyjnego wymaga czegoś więcej niż udanych demonstracji.

Postępy Bun wywierają presję także na Node.js i Deno, choć żadne z nich nie jest głównym przeciwnikiem w tej historii. Node.js pozostaje punktem odniesienia pod względem zgodności dla JavaScript po stronie serwera.

Deno już korzysta z Rust w otoczeniu silnika JavaScript V8. Jego architektura stanowi istotny punkt porównania dla zarządzania środowiskiem uruchomieniowym JavaScript za pomocą Rust i zależności natywnych.

Bun musi zachować zgodność z Node.js, jednocześnie utrzymując deklarowaną wydajność i rozbudowany zestaw narzędzi. Migracja, która ograniczyłaby liczbę awarii, ale wprowadziła różnice w zachowaniu, jedynie zastąpiłaby jeden problem z niezawodnością innym.

Zespół wybrał więc mechaniczne przeniesienie kodu zamiast natychmiastowego przeprojektowania architektury. Nowy kod w Rust celowo przypomina wcześniejszą architekturę w Zig.

Decyzja ta ograniczyła zmiany zachowania podczas migracji. Przeniosła jednak również dawne założenia i wzorce niskiego poziomu do języka o innych regułach bezpieczeństwa.

W rezultacie powstało główne napięcie tego projektu. Bun wybrał Rust ze względu na silniejsze gwarancje, ale najbezpieczniejsza droga do zachowania zgodności początkowo wymagała pozostawienia znacznej ilości kodu unsafe.

Claude zastąpił roczne przepisywanie kodu 11-dniową pętlą weryfikacji

Najważniejszym mechanizmem nie było samo generowanie kodu. Była nim kontrolowana pętla oddzielająca implementację, krytyczną ocenę, poprawki i testowanie.

Bun oszacował, że konwencjonalne przepisanie kodu zajęłoby trzem doświadczonym inżynierom około roku. W tym czasie prace nad nowymi funkcjami i poprawą zgodności zwolniłyby lub całkowicie się zatrzymały.

Istniejąca baza kodu w Zig zawierała 535 496 wierszy, nie licząc komentarzy. Ręczne przeniesienie doprowadziłoby również do powstania długo utrzymywanej gałęzi, która coraz bardziej odbiegałaby od wersji produkcyjnej.

Zamiast tego Sumner przetestował przedpremierowy model Anthropic o nazwie Claude Fable 5. Około trzech godzin poświęcił na opracowanie reguł przekładania wzorców, typów i cykli życia z Zig na Rust.

Claude zapisał te ustalenia w przewodniku po migracji. Drugi wygenerowany dokument opisywał oczekiwane cykle życia pól w całej bazie kodu.

Zespół rozpoczął od trzech plików, zamiast od razu tłumaczyć całość. Jedna instancja Claude implementowała każdy port, dwie oddzielne instancje go weryfikowały, a kolejna wprowadzała poprawki.

Ten podział był celowy. Model, który wygenerował zmianę, może nadal wykazywać skłonność do akceptowania własnego toku rozumowania.

Instancje przeprowadzające przegląd otrzymywały diff bez pełnego kontekstu instancji implementującej. Ich zadaniem było wyszukiwanie nieprawidłowego działania i regresji.

Sumner nazwał to przeglądem kontradyktoryjnym. Przypomina on niezależny przegląd kodu, jednak wszyscy uczestnicy byli instancjami tej samej rodziny modeli.

Cała operacja wykorzystywała około 50 dynamicznych przepływów pracy Claude Code. W szczytowym momencie jednocześnie działały cztery grupy przepływów, z których każda koordynowała 16 instancji Claude.

Oznaczało to, że jednocześnie pracowało około 64 agentów. Według doniesień port osiągnął szczytowe tempo około 1300 wygenerowanych wierszy na minutę.

Proces od początku nie przebiegał bezproblemowo. Agenci pracujący w tym samym repozytorium używali kolidujących ze sobą poleceń Git, w tym operacji stash i hard reset.

Sumner zmienił ich instrukcje, zakazując ogólnych operacji Git. Ostatecznie system korzystał z czterech oddzielnych drzew roboczych, a agenci zatwierdzali konkretne pliki i udostępniali rezultaty za pośrednictwem gałęzi.

Ta porażka jest istotna, ponieważ pokazuje, że sama zdolność modelu nie wystarczyła do przeprowadzenia przepisywania. Przepływ pracy wymagał wyraźnych ograniczeń dotyczących współdzielonego stanu i działań destrukcyjnych.

Zespoły rozważające podobne migracje potrzebowałyby równie jasnych reguł operacyjnych. Agent piszący poprawny kod nadal może zaszkodzić projektowi przez niewłaściwą obsługę repozytoriów, poświadczeń, systemów kompilacji lub narzędzi wdrożeniowych.

Migracja wygenerowała 6502 commity bez uwzględnienia scaleń, natomiast Bun odnotował łącznie 6778 commitów w ciągu 11 dni. Wprowadzony diff dodał nieco ponad milion wierszy.

Liczby te opisują aktywność, a nie jakość. Małe commity mogą poprawiać identyfikowalność zmian, ale tysiące automatycznych commitów przeciążają również konwencjonalny proces przeglądu przez ludzi.

Bun opierał się przede wszystkim na kompilatorach, automatycznych recenzentach i istniejącym zestawie testów. Zestaw ten obejmował około miliona asercji na obsługiwanych platformach.

Przed scaleniem zespół poinformował o ukończeniu 100 procent testów w ramach ciągłej integracji. Według jego deklaracji żadnego testu nie usunięto ani nie pominięto.

Na Debianie Bun zarejestrował 1 386 826 wywołań expect() w 60 624 testach. Zarówno macOS, jak i Windows wykonały po ponad milion asercji.

Zestaw testów napisany w TypeScript zapewnił Bun istotną przewagę. Testy oceniały obserwowalne zachowanie, nie polegając na tym, czy bazowe środowisko uruchomieniowe korzystało z Zig, czy z Rust.

Taka architektura umożliwiła mierzenie postępów mechanicznego portu. Każdy przetłumaczony komponent musiał zachować wyniki, których te same zewnętrzne testy oczekiwały już wcześniej.

Claude wykorzystywał także błędy kompilatora jako kolejkę zadań. Bun podzielił kod Rust na około 100 crate’ów, czyli oddzielnie kompilowanych pakietów w projekcie Rust.

Na pewnym etapie cargo check zwracało około 16 000 błędów. Przepływy pracy grupowały te błędy według crate’ów, przydzielały je agentom, poddawały poprawki przeglądowi i powtarzały cały proces.

Pętla kompilacji przekształciła onieśmielającą migrację w ograniczone zadania. Każdy błąd dostarczał lokalnej informacji zwrotnej, na podstawie której agent mógł działać.

Podejście to sprawdziło się szczególnie dobrze, ponieważ kompilator Rust precyzyjnie objaśnia wiele błędów dotyczących własności i typów. Kompilator stał się zarówno bramką kontrolną, jak i źródłem ustrukturyzowanych instrukcji.

Przed scaleniem proces zużył 5,9 miliarda niebuforowanych tokenów wejściowych i 690 milionów tokenów wyjściowych. Odczytał także 72 miliardy buforowanych tokenów wejściowych.

Bun oszacował całkowity koszt na około 165 000 dolarów według cen API. Kwota ta nie obejmuje wszystkich kosztów organizacyjnych, w tym stworzenia pierwotnej bazy kodu i testów, wiedzy specjalistycznej ludzi ani późniejszego utrzymania.

Porównanie z pracą trzech inżynierów przez rok ma więc charakter orientacyjny, a nie wyczerpujący. Claude nie stworzył od zera architektury Bun, warstwy zgodności ani zestawu testów.

Wykorzystał lata nagromadzonego kontekstu inżynieryjnego. Szybkość migracji zależała od dostępności tego kontekstu w formatach, które agenci mogli odczytywać i weryfikować.

To rozróżnienie ma znaczenie dla innych zespołów. Dojrzały zestaw testów i dobrze zdefiniowane zachowanie mogą sprawić, że automatyczna migracja stanie się realna.

Słabo przetestowany system nie oferuje porównywalnej wyroczni. Agenci mogą tworzyć kod, który się kompiluje, a jednocześnie po cichu zmienia zachowanie, od którego zależą użytkownicy.

Zespoły inżynieryjne potrzebują również trwałych zapisów wyjaśniających decyzje agentów. Przeszukiwalna baza wiedzy może zachować reguły migracji, ustalenia z przeglądów i założenia dotyczące własności poza granicami pojedynczych okien kontekstowych.

Projekt Bun osiągnął to dzięki dokumentacji portowania, mapom czasów życia, historii commitów i testom. Artefakty te nie były dodatkami administracyjnymi.

To właśnie one tworzyły system, który w ogóle umożliwiał przeglądanie kodu generowanego w tak szybkim tempie.

Rust nie może zagwarantować bezpieczeństwa tam, gdzie Bun nadal używa kodu unsafe

Przepisanie kodu ogranicza kilka klas ryzyka, ale nie uzasadnia automatycznego uznania Bun za bezpieczny pod względem pamięci.

Mechaniczne tłumaczenie Bun zachowało niskopoziomowe operacje na wskaźnikach oraz rozległą integrację z bibliotekami C i C++. Takie obszary często wymagają użycia słowa kluczowego unsafe języka Rust.

Blok unsafe pozwala wykonywać operacje, których kontroler zapożyczeń nie potrafi zweryfikować. Programista musi ręcznie dopilnować przestrzegania niezbędnych reguł.

Nie oznacza to, że każdy blok unsafe zawiera defekt. Duże systemy napisane w Rust korzystają z kodu unsafe, aby implementować wydajne abstrakcje i integrować się z systemami operacyjnymi lub bibliotekami natywnymi.

Oznacza to jednak, że najcenniejsze gwarancje Rust zależą od sposobu projektowania, dokumentowania i audytowania tych granic.

Sumner poinformował, że początkowo około czterech procent kodu Rust w Bun znajdowało się wewnątrz bloków unsafe. Wskazał około 27 000 niebezpiecznych wierszy w mniej więcej 780 000 wierszy kodu Rust.

Dodał również, że 78 procent tych bloków zawierało tylko jeden wiersz. Wiele z nich obsługiwało wskaźnik C++ lub pojedyncze wywołanie biblioteki natywnej.

Ten kontekst jest istotny, ale długość bloku nie dowodzi jego poprawności. Pojedyncza niebezpieczna konwersja wskaźnika może spowodować błąd czasu życia wpływający na bezpieczny kod w innym miejscu.

Publicznie zgłoszony problem z bezpieczeństwem pamięci z 14 maja unaocznił te obawy. Raport pokazał bezpieczną funkcję usuwającą informację o czasie życia wycinka i umożliwiającą powstanie wiszącej referencji.

Miri, interpreter używany do wykrywania niezdefiniowanego zachowania w programach Rust, oznaczył ten przykład jako problematyczny. Niezdefiniowane zachowanie oznacza, że język nie nakłada żadnych wiarygodnych ograniczeń na wynik.

Automatyczny współtwórca Bun odtworzył problem i zidentyfikował równoległą lukę dotyczącą czasu życia. Proponowana poprawka oznaczyła dotknięte funkcje jako unsafe i udokumentowała ich wymagania dotyczące czasów życia.

Reakcja pokazała, że projekt potrafił szybko obsłużyć konkretne zgłoszenie. Wykazała również, że kompilacja i istniejący zestaw testów nie zapobiegły każdej nieprawidłowej abstrakcji.

Ta luka stanowi podstawę najmocniejszego sceptycznego argumentu przeciwko przepisywaniu. Jeżeli automatyczne testy nie wykryły błędów pamięci w Zig, te same testy nie mogą dowieść poprawności dużego portu do Rust.

Rust dodaje mechanizmy kontroli kompilatora, ale sekcje unsafe ponownie przenoszą odpowiedzialność na inżynierów. Mechaniczne tłumaczenie może zachować w tych sekcjach pierwotne zasady operowania wskaźnikami.

Twórca Zig, Andrew Kelley, przedstawił najostrzejszą publiczną krytykę. W swojej odpowiedzi na przepisanie kodu argumentował, że problemy Bun wynikały z praktyk inżynieryjnych i nagromadzonego długu technicznego, a nie z wad Zig.

Kelley zakwestionował również, czy ogromna ilość kodu wygenerowanego przez model została poddana wystarczającej kontroli przez ludzi. Jego krytyka miejscami przybierała osobisty charakter, co odwracało uwagę od kwestii technicznej.

Pytanie to pozostaje zasadne: jakiego poziomu niezależnego przeglądu wymaga infrastruktura, zanim zespoły zaufają przepisanemu przez AI kodowi?

Bun twierdzi, że każdy wiersz został sprawdzony przez dwie oddzielne instancje Claude. Przegląd dokonywany przez model nie jest jednak odpowiednikiem niezależnego osądu człowieka.

Instancje tego samego modelu mogą mieć wspólne słabe punkty, wzorce wyniesione z treningu i błędne założenia. Oddzielne okna kontekstowe ograniczają efekt zakotwiczenia, ale nie tworzą prawdziwie niezależnej wiedzy eksperckiej.

Automatyczni recenzenci wykryli przed scaleniem kilka wiarygodnych błędów. Jeden dotyczył asynchronicznej operacji zamknięcia, która dwukrotnie zwolniłaby ten sam zasób.

Inny nieprawidłowo obsługiwał ujemne znaczniki czasu. W trzecim użyto zachłannej metody Rust, która powodowałaby panic podczas analizowania niektórych wyrażeń kolorów CSS.

Przykłady te pokazują, że przegląd kontradyktoryjny wniósł realną wartość. Nie ujawniają jednak, ile defektów wszystkie instancje przeglądające kod wspólnie przeoczyły.

Debata nie powinna sprowadzać się do wyboru między akceptacją a odrzuceniem kodu wygenerowanego przez AI. Bardziej użyteczne pytanie dotyczy poziomu zapewnienia jakości.

Zespoły już dziś ufają kompilatorom, analizatorom statycznym, fuzzerom, modelom formalnym i zautomatyzowanym systemom testowania. Agenci programistyczni mogą dołączyć do tego zestawu, nie stając się ostatecznym autorytetem.

Stanowisko Prisma oferuje praktyczny kompromis. Firma wdrożyła port w publicznej wersji beta i zgłosiła poprawę w znanych scenariuszach awarii.

Jednocześnie Prisma stwierdziła, że kod unsafe wymaga audytu, a przetłumaczony kod — przeglądu. Zaleciła refaktoryzację nieidiomatycznych sekcji na fragmenty zrozumiałe dla ludzi.

Bun podjął podobne zobowiązanie. Początkowym celem było zachowanie zachowania, a następnie stopniowe ograniczanie użycia unsafe i przechodzenie na bardziej idiomatyczny Rust.

Taka kolejność jest uzasadniona, ale opóźnia część korzyści związanych z bezpieczeństwem. Dopóki obszar unsafe się nie zmniejszy, migracja pozostaje trwającym programem inżynieryjnym.

Argument ten wykracza również poza bezpieczeństwo pamięci. Środowisko uruchomieniowe może zawodzić z powodu nieprawidłowego rozwiązywania modułów, niezgodnych API, zachowania sieci, regresji wydajności lub subtelnych różnic między systemami operacyjnymi.

Rust nie zapobiega błędom logicznym. Zestaw obejmujący milion asercji również nie dowodzi poprawnego działania każdego istniejącego pakietu JavaScript.

Bun potrzebuje zatem zewnętrznych obciążeń roboczych, niezależnych audytów, fuzzingu i długotrwałych wdrożeń produkcyjnych. Każde z nich dostarcza dowodów, których nie może zapewnić sama wewnętrzna walidacja.

Przepisanie Bun w Rust po przejęciu przez Anthropic należy traktować jako obiecującą migrację podlegającą aktywnej weryfikacji. Uznanie jej za całkowity sukces w dziedzinie bezpieczeństwa albo porażkę automatyzacji wykraczałoby poza dostępne dowody.

Trzy sygnały rozstrzygną, czy przepisanie Bun się powiodło

Kolejny etap będzie mniej spektakularny niż 11-dniowy port, ale to on zdecyduje, czy przepisanie stanie się wzorem, czy przestrogą.

Pierwszym sygnałem będzie zachowanie Bun 1.4 w zwykłych wdrożeniach produkcyjnych. Bun v1.3.14 był ostatnim wydaniem w Zig, natomiast v1.4 wprowadził implementację w Rust.

Zespoły powinny obserwować raporty o awariach, zużycie pamięci, regresje zgodności i wycofywanie wdrożeń po szerszym przyjęciu nowej wersji. Udane wydanie powinno ograniczyć błędy pamięci bez tworzenia nowej kategorii błędów behawioralnych.

Wczesne wdrożenia Claude Code i Prisma wzmacniają argumenty Bun. Nie obejmują jednak pełnej różnorodności kombinacji pakietów, systemów operacyjnych, modułów natywnych i wzorców obciążeń.

Szerokie użycie ujawni ścieżki kodu, do których wewnętrzny zestaw testów Bun nigdy nie dotarł. Stabilne wyniki na przestrzeni kilku cykli wydawniczych dostarczyłyby mocniejszych dowodów niż benchmarki z momentu premiery.

Drugim sygnałem będzie rozmiar i konstrukcja obszaru unsafe w kodzie Rust projektu Bun. Surowe liczby wymagają kontekstu, ponieważ środowiska uruchomieniowe intensywnie korzystające z FFI nie mogą całkowicie wyeliminować kodu unsafe.

Bardziej znaczące pytanie brzmi, czy niebezpieczne operacje zostaną przeniesione za niewielkie, udokumentowane interfejsy. Każdy interfejs powinien określać założenia dotyczące czasów życia, aliasowania, własności i bezpieczeństwa wątkowego, których muszą przestrzegać wywołujący.

Niezależne audyty wzmocniłyby te działania. Publiczne ustalenia Miri oraz wyniki stosowania sanitizerów i fuzzingu również powinny prowadzić do widocznych poprawek wraz z testami regresji.

Jeśli wykorzystanie unsafe będzie spadać, a Bun zachowa wydajność i zgodność, argument dotyczący poprawy bezpieczeństwa dzięki przepisaniu stanie się silniejszy. Powtarzające się błędy czasów życia wewnątrz bezpiecznych interfejsów osłabiłyby go.

Trzecim sygnałem będzie to, czy inny dojrzały projekt powtórzy metodę migracji Bun. Bun miał wyjątkowo korzystny punkt wyjścia: rozbudowane testy, jednego głównego architekta oraz właściciela dysponującego dostępem do modelu przed jego premierą.

Druga udana migracja musiałaby wykazać coś więcej niż szybkie generowanie kodu. Powinna udokumentować weryfikację przez człowieka, wykrywanie defektów, mechanizmy kontroli operacyjnej oraz utrzymanie po wydaniu.

Jeśli takie wyniki się powtórzą, migracje między językami wspomagane przez AI mogą stać się standardową opcją dla projektów blokowanych przez wieloletnie koszty przepisania kodu.

Jeśli Bun pozostanie odosobnionym przypadkiem, wnioski będą bardziej ograniczone. Osiągnięcie nadal będzie istotne, lecz powie więcej o infrastrukturze testowej Bun niż o tworzeniu oprogramowania w ujęciu ogólnym.

Szersza rywalizacja nie dotyczy Rust kontra Zig. Chodzi o tempo generowania kodu przez maszyny w zestawieniu z dowodami niezbędnymi, by zaufać oprogramowaniu o fundamentalnym znaczeniu.

Bun przeniósł tę rywalizację z projektów demonstracyjnych do środowiska uruchomieniowego pobieranego ponad 22 miliony razy miesięcznie. Anthropic wdrożył również rezultat w Claude Code, zanim zakończyła się publiczna debata.

Decyzja ta zapewnia Bun cenne informacje zwrotne z użytkowania produkcyjnego. Jednocześnie nakłada na Anthropic obowiązek udowodnienia, że jego agenci programistyczni potrafią utrzymywać wygenerowane przez siebie rozwiązania.

Przed podjęciem migracji obarczonych wysokim ryzykiem deweloperzy powinni śledzić informacje o wydaniach, nierozstrzygnięte zgłoszenia dotyczące bezpieczeństwa oraz wyniki niezależnych wdrożeń. Powinni również testować własne zależności przy realistycznych obciążeniach.

Przepisanie Bun w Rust po przejęciu przez Anthropic już pokazało, że port wspomagany przez AI może przekroczyć granicę skali, która wcześniej wydawała się zaporowa.

Otwarte pozostaje pytanie, czy proces weryfikacji zdoła dotrzymać kroku procesowi generowania. Warto obserwować działanie Bun 1.4 w rzeczywistych wdrożeniach, audyty niebezpiecznego kodu oraz kolejny duży projekt, który spróbuje zastosować tę samą metodę.