Bun випустив небезпечний AI-код
Нещодавно Bun випустив масштабне переписування на Rust. Команда використала Claude AI для написання значної його частини. Це переписування додало понад 13 000 блоків unsafe коду до кодової бази.
У системному програмуванні unsafe код обходить правила безпеки пам'яті. Один такий блок — це ризик. Тринадцять тисяч блоків у коді, згенерованому ШІ, — це криза.
Команда також випустила це без конкурентного збирача сміття (garbage collector). Це ускладнює керування пам'яттю в багатопотокових навантаженнях.
Я розумію потребу в швидкості. Малі команди мають рухатися швидко, щоб конкурувати з Node.js та Deno. Але швидкість не повинна замінювати ретельність.
Блок unsafe коду — це обіцянка того, що доступ до пам'яті є коректним. Якщо код пише ШІ, жодна людина не підписувала цю обіцянку.
Код від ШІ не є поганим. Однак використання ШІ для генерації unsafe коду в таких масштабах є небезпечним.
Runtime — це не просто бібліотека. Це фундамент усього вашого додатка. Обираючи runtime, ви вирішуєте йому довіряти.
Деякі розробники повертаються до Node.js через побоювання щодо стабільності. Це результат випуску експериментальної інфраструктури.
Я щодня використовую інструменти ШІ. Я ставлюся до коду від ШІ як до коду від молодшого інженера. Він потребує перевірки, яка відповідає рівню ризику.
Ризик багатопотоковості в JavaScript runtime є величезним. Ці 13 000 блоків потребують 13 000 вагомих причин для існування. Їм не потрібні 13 000 формальних схвалень.
Висока швидкість генерації ШІ потребує такої ж високої швидкості перевірки.
Bun має великий потенціал. Команда виконала вражаючу роботу. Але амбітність без обережності створює ризики.
Нам не слід припиняти використовувати ШІ. Ми повинні забезпечити, щоб рівень перевірки відповідав масштабу можливих наслідків. ШІ не може усвідомити ціну помилки.
Чи запустили б ви 13 000 згенерованих ШІ unsafe блоків у своєму production-додатку? Яка ваша межа довіри до ШІ в питаннях інфраструктури?