Bun أطلقت كود AI غير آمن
قامت Bun مؤخراً بإعادة كتابة نواتها بلغة Rust. كما أضافت ميزة تعدد الخيوط (multithreading) التجريبية. هذه خطوات كبيرة، ولكن الطريقة المستخدمة لتحقيق هذه الأهداف تثير القلق.
اعترف فريق Bun أن Claude AI كتب جزءاً كبيراً من إعادة الكتابة بلغة Rust. أضاف هذا التغيير أكثر من 13,000 كتلة غير آمنة (unsafe blocks) إلى قاعدة الكود. كما تم إطلاقها بدون جامع قمامة متزامن (concurrent garbage collector).
في برمجة الأنظمة، يتجاوز الكود غير الآمن (unsafe code) معايير سلامة الذاكرة. كتلة غير آمنة واحدة تمثل مخاطرة، أما ثلاثة عشر ألف كتلة من إنتاج ذكاء اصطناعي فهي عبء ومخاطرة جسيمة.
أتفهم الحاجة إلى السرعة؛ فالفرق الصغيرة يجب أن تتحرك بسرعة لتنافس Node.js و Deno. لكن السرعة دون حذر أمر خطير.
كل كتلة غير آمنة هي بمثابة وعد بالوصول الصحيح إلى الذاكرة. وعندما يكتب الذكاء الاصطناعي الكود، فمن الذي يضمن هذا الوعد؟
المخاطر واضحة:
- يفتقر كود الذكاء الاصطناعي إلى المنطق البشري في إدارة الذاكرة.
- التوليد عالي السرعة يتطلب مراجعة عالية السرعة.
- غياب جامع القمامة المتزامن يجعل أعباء العمل متعددة الخيوط غير مستقرة.
بيئة التشغيل (runtime) ليست مجرد مكتبة بسيطة، بل هي الأساس لتطبيقك بالكامل. أنت تختار بيئة التشغيل بناءً على الثقة، وعندما تبدو البنية التحتية تجريبية، يعود المطورون إلى الأدوات المستقرة مثل Node.js.
أنا أستخدم أدوات الذكاء الاصطناعي يومياً، وأتعامل مع كود الذكاء الاصطناعي بنفس الطريقة التي أتعامل بها مع كود مهندس مبتدئ؛ فهو يحتاج إلى مراجعة تتناسب مع حجم تأثيره.
إن تأثير تعدد الخيوط داخل بيئة التشغيل هائل. ثلاثة عشر ألف كتلة غير آمنة تحتاج إلى ثلاثة عشر ألف سبب وجيه، ولا تحتاج إلى ثلاثة عشر ألف ختم موافقة صوري.
الطموح أمر جيد، لكن الإهمال في كود الأنظمة يمثل مخاطرة.
هل ستشغل 13,000 كتلة غير آمنة مولدة بواسطة الذكاء الاصطناعي في تطبيقك في بيئة الإنتاج (production)؟ وما هو حدك في الوثوق بالذكاء الاصطناعي لإدارة البنية التحتية؟
Optional learning community: https://t.me/GyaanSetuAi