Jarred Sumner, czyli twórca narzędzia Bun, w ciekawy sposób przedstawił historię przepisania tego projektu z języka Zig na dość ceniony współcześnie język Rust. Polecam zapoznać się z oryginalnym opracowaniem, bo zawiera różne techniczne niuanse, natomiast całość historii sprowadza się w zasadzie do tego, że trzy agenty modelu Fable 5 (jeden w roli „programisty” piszącego kod, a dwa pozostałe działające jako „programiści” przeglądający zmiany) sprostały wyzwaniu przepisania zaawansowanego oprogramowania w 11 dni – jednocześnie usuwając często występujące problemy oraz zwiększając wydajność.
Bun można określić jako bardziej rozbudowaną alternatywę dla Node.js, chociaż pod względem popularności w stosunku do Node.js wydaje się niszowym rozwiązaniem. We wspomnianym wpisie blogowym wymieniono realne problemy, które napotykali użytkownicy podczas pracy z Bun – wycieki pamięci, race conditions i zwyczajne awarie działania. Powodem tak kiepskiej jakości w ocenie autorów Bun nie jest brak przestrzegania dobrych praktyk w kodzie, a zastosowany język programowania – Zig.
Zig jest niskopoziomowym językiem, który można określić jako prostszy zamiennik C i C++. Jak czytamy Zig nie potrafi samodzielnie zarządzać pamięcią (w tym przypadku analogicznie do języka C) czy nie posiada obsługi konstruktorów i destruktorów, co według twórcy Bun w tym projekcie jest absolutnie kluczowe. Z tego powodu przepisanie całego kodu na inny język uznano za rozsądne.
Technicznie jest to oczywiście wyzwanie, a przy tak dużej ilości kodu w standardowym podejściu do pracy zajęłoby to pewnie znaczną ilość czasu. Pamiętajmy, że nie jest możliwe, aby każdy członek zespołu programistów pracował wyłącznie przy przepisywaniu kodu, bo trzeba obsługiwać bieżące zgłoszenia użytkowników. Nikt też nie jest w stanie pracować bez przerwy. Z racji, że Bun został przejęty przez Anthropic – przedsiębiorstwo odpowiedzialne za modele Claude – decyzja mogła być jedna.
Nie zaczęło się jednak od prompta „Przepisz Bun z języka Zig na Rust”, a od przemyślanego workflow. W skrócie: model otrzymał zadanie przepisania każdego pliku ZIG na plik RS, naprawę ewentualnych błędów kompilacji i doprowadzenie do prawidłowego wykonywania poleceń bun test lub bun build w połączeniu z testami automatycznymi.
Napotkano pewne problemy w działaniu modeli, ale ostatecznie ich pracę udało się skutecznie zoptymalizować. Kiedy wszystkie testy zakończyły się sukcesem wystawiono pull request.
Praca wykonana przez AI rozwiązała wymienione wcześniej problemy użytkowników, a oprócz tego zwiększyła wydajność środowiska Bun.
Dla porównania warto przeczytać opinię głównego programisty Zig dotyczącą przedstawianych wydarzeń. Oprócz kilku, jak wydaje się osobistych, odniesień w stosunku do Jarreda Sumnera, pojawia się stwierdzenie, że Bun stał się głównym przykładem, jak nie należy pisać kodu w języku Zig. Poddano też w wątpliwość metodę wykonywania porównawczych testów wydajnościowych.
W tym wszystkim jest na pewno sporo marketingu, bo przypomnijmy, że właścicielem Bun jest Anthropic. Jednak skupiając się na samej treści technicznej nie możemy nie zauważyć, że obecne modele AI stały się rzeczywistym wsparciem w pracy zespołów IT. W tym konkretnym przypadku zdecydowanie pomocne okazało się doświadczenie programisty, który przykładał wiele uwagi do testów tak wytwarzanego kodu. Natomiast dla małych projektów, a szczególnie tych pisanych „od zera”, sztuczna inteligencja jest w stanie skutecznie dostarczyć działające oprogramowanie.
Co więcej, kod opracowany przez AI pod kątem bezpieczeństwa, wydajności czy też jakości z całą pewnością okaże się lepszy, niż kod pisany przez osoby uczące się programowania samodzielnie. O ile poznawanie różnych aspektów IT jest wartością, to jednak początkujące osoby nie mają pełnej świadomości, w jaki sposób budowane są profesjonalne środowiska – począwszy od jakości kodu, poprzez CI/CD czy testy automatyczne, a kończąc na zapewnieniu odpowiedniej infrastruktury. Swoją drogą „włączenie” AI w proces nauki może okazać się dobrym podejściem, jednak nic nie zastąpi doświadczenia zdobytego w projektach komercyjnych.
Czas pokaże, czy rzeczywiście Bun w wersji Rust zostanie pozytywnie odebrany przez użytkowników. Jeśli w praktycznym zastosowaniu wprowadzone zmiany okażą się poprawne, a błędy faktycznie zostaną wyeliminowane, to możemy mówić o pierwszym tak dużym projekcie, który wykorzystał AI do wykonania zaawansowanej technicznie pracy programistycznej. W przeciwnym wypadku spodziewam się, że Bun zacznie być określany jako „AI slop”, co może oznaczać trwałą degradację jego znaczenia.
W temacie używania AI w znanych projektach mocno sugeruję lekturę tego issue w projekcie rsync, gdzie okazało się, że wadliwa zmiana jest „autorstwa” sztucznej inteligencji.
