Bun أطلقت كود AI غير آمن
أصدرت Bun مؤخرًا إعادة كتابة ضخمة بلغة Rust. استخدم الفريق Claude AI لكتابة جزء كبير منها. أضافت إعادة الكتابة هذه أكثر من 13,000 كتلة كود unsafe إلى قاعدة الكود.
في برمجة الأنظمة، يتجاوز الكود الـ unsafe قواعد سلامة الذاكرة. كتلة واحدة unsafe تمثل خطرًا، أما ثلاثة عشر ألف كتلة في كود تم إنشاؤه بواسطة الذكاء الاصطناعي فهي أزمة.
كما أصدر الفريق هذا التحديث بدون جامع قمامة متزامن (concurrent garbage collector)، مما يجعل إدارة الذاكرة صعبة في أعباء العمل متعددة الخيوط (multithreaded workloads).
أنا أتفهم الحاجة إلى السرعة. يجب على الفرق الصغيرة التحرك بسرعة لمنافسة Node.js و Deno. ولكن لا ينبغي للسرعة أن تحل محل الدقة.
كتلة الكود الـ unsafe هي بمثابة وعد بأن الوصول إلى الذاكرة صالح. إذا كتب الذكاء الاصطناعي الكود، فلا يوجد إنسان وقع على هذا الوعد.
كود الذكاء الاصطناعي ليس سيئًا. ومع ذلك، فإن استخدام الذكاء الاصطناعي لإنشاء كود unsafe بهذا النطاق هو أمر خطير.
بيئة التشغيل (runtime) ليست مجرد مكتبة بسيطة، بل هي أساس تطبيقك بالكامل. عندما تختار بيئة تشغيل، فأنت تختار الوثوق بها.
يعود بعض المطورين إلى Node.js بسبب مخاوف تتعلق بالاستقرار. هذه هي نتيجة إطلاق بنية تحتية تجريبية.
أنا أستخدم أدوات الذكاء الاصطناعي كل يوم، وأتعامل مع كود الذكاء الاصطناعي كما أتعامل مع كود مهندس مبتدئ؛ فهو يحتاج إلى مراجعة تتناسب مع حجم المخاطر.
إن مخاطر تعدد الخيوط (multithreading) في بيئة تشغيل JavaScript هائلة. تلك الـ 13,000 كتلة تحتاج إلى 13,000 سبب وجيه لوجودها، ولا تحتاج إلى 13,000 ختم موافقة عشوائي.
يتطلب التوليد السريع بواسطة الذكاء الاصطناعي مراجعة سريعة الوتيرة أيضًا.
تمتلك Bun إمكانات كبيرة، وقد قام الفريق بعمل مثير للإعجاب. لكن الطموح دون حذر يخلق مخاطر ومسؤوليات.
لا ينبغي لنا التوقف عن استخدام الذكاء الاصطناعي، ولكن يجب أن نضمن أن مستوى المراجعة يتناسب مع نطاق التأثير المحتمل. لا يمكن للذكاء الاصطناعي أن يدرك تكلفة الخطأ.
هل ستشغل 13,000 كتلة unsafe تم إنشاؤها بواسطة الذكاء الاصطناعي في تطبيق الإنتاج (production app) الخاص بك؟ ما هو حدك في الوثوق بالذكاء الاصطناعي في إدارة البنية التحتية؟