Bun wypuścił niebezpieczny kod AI
Bun niedawno wydał masową wersję napisaną w Rust. Zespół użył Claude AI do napisania większości kodu. Ta przebudowa dodała do bazy kodu ponad 13 000 bloków kodu unsafe.
W programowaniu systemowym kod unsafe omija reguły bezpieczeństwa pamięci. Jeden blok unsafe to ryzyko. Trzynaście tysięcy bloków w kodzie wygenerowanym przez AI to kryzys.
Zespół wydał to również bez współbieżnego mechanizmu garbage collector. Utrudnia to zarządzanie pamięcią w obciążeniach wielowątkowych.
Rozumiem potrzebę szybkości. Małe zespoły muszą działać szybko, aby konkurować z Node.js i Deno. Jednak szybkość nie powinna zastępować staranności.
Blok kodu unsafe to obietnica, że dostęp do pamięci jest prawidłowy. Jeśli kod pisze AI, żaden człowiek nie podpisał tej obietnicy.
Kod z AI nie jest zły. Jednak używanie AI do generowania kodu unsafe na taką skalę jest niebezpieczne.
Runtime to nie jest zwykła biblioteka. To fundament całej Twojej aplikacji. Wybierając runtime, decydujesz się mu zaufać.
Niektórzy programiści wracają do Node.js ze względu na obawy o stabilność. Jest to wynik wydawania eksperymentalnej infrastruktury.
Korzystam z narzędzi AI każdego dnia. Traktuję kod z AI tak, jak kod od młodszego inżyniera. Wymaga on przeglądu adekwatnego do ryzyka.
Ryzyko związane z wielowątkowością w środowisku JavaScript runtime jest ogromne. Tych 13 000 bloków wymaga 13 000 dobrych powodów, by istnieć. Nie potrzebują one 13 000 bezrefleksyjnych zatwierdzeń.
Szybka generacja przez AI wymaga równie szybkiej weryfikacji.
Bun ma ogromny potencjał. Zespół wykonał imponującą pracę. Jednak bycie ambitnym bez zachowania ostrożności tworzy ryzyko.
Nie powinniśmy przestać używać AI. Musimy jednak zapewnić, aby poziom weryfikacji odpowiadał skali ewentualnych szkód. AI nie potrafi zrozumieć kosztów popełnienia błędu.
Czy uruchomilibyście 13 000 bloków unsafe wygenerowanych przez AI w swojej aplikacji produkcyjnej? Jaka jest Wasza granica zaufania do AI w kwestii infrastruktury?