هل يمكن للذكاء الاصطناعي أن يحل محل مديري الحزم؟ من npm إلى سجل الطلبات

حلل مؤلف تكنولوجي روسي على Habr فكرة اقترحها المطور Marcelo Emmerich في منشور على منصة Medium: استبدال مديري الحزم التقليديين مثل npm بـ "سجل المحفزات" — نظام حيث يقوم مؤلفو المكتبات بنشر ليس الكود الجاهز، بل المحفزات للذكاء الاصطناعي لإنشاء تطبيق مكتفٍ بذاته مباشرة على جانب المطور.

ما هي فكرة "سجل المحفزات"؟

وفقاً لمفهوم إيميريش، بدلاً من تثبيت مكتبة جاهزة عبر npm install، يقوم المطور بإدراج المحفز من مؤلف المكتبة في أداة الذكاء الاصطناعي الخاصة به، وتقوم بإنشاء تطبيق مخصص للغة البرمجة المحددة وميزات المشروع. كما يلاحظ مؤلف Habr، فإن هذا النهج له منطق جذاب: إذا تم إنشاء الكود من جديد في كل مرة لمهمة محددة، فإن الاعتماديات المتسلسلة تختفي (المكتبات التي تجلبها مكتبة أخرى)، والهجمات على سلسلة التوريد من خلال الحزم المخترقة، وتضاربات الإصدارات من الاعتماديات المختلفة في مشروع واحد — نقاط الألم الكلاسيكية للتطوير الحديث.

لماذا هذه الفكرة ساذجة لكن ليست بدون جدوى

يسمي مؤلف Habr الفكرة ساذجة لكنه يعترف بأنها تشير إلى مشاكل حقيقية. الهجمات على سلسلة التوريد — حقن كود خبيث من خلال اعتماد مخترق في عمق شجرة الحزم — هي بالفعل تهديد جدي وصعب السيطرة عليه: فهم ما يحتويه بالضبط جميع الاعتماديات المتسلسلة لمشروع كبير يكاد يكون مستحيلاً يدوياً. فكرة "إنشاء بالضبط ما تحتاجه ولا شيء أكثر" هي أيضاً جذابة بطريقتها الخاصة — تعد بالتحرر من تضخم التطبيقات الحديثة، التي تسحب عشرات ميجابايتات من الكود غير المستخدم عبر سلاسل الاعتماديات.

النقاط الرئيسية للتحليل:

• مؤلف الفكرة الأصلية — Marcelo Emmerich، تم نشر المنشور على منصة Medium.
• الاستبدال المقترح لمديري الحزم — "سجل المحفزات" لإنشاء الكود على الفور.
• المزايا المعلنة للفكرة — غياب الاعتماديات المتسلسلة، الحماية من هجمات سلسلة التوريد، غياب تضاربات الإصدارات.
• الحجة المضادة لمؤلف Habr — التعقيد (تحليل TLS وJSON وUnicode) لا يختفي، إنه فقط يتوقف عن أن يُطلق عليه "اعتمادية".

ما الذي لا تأخذه هذه الفكرة في الاعتبار

الحجة المضادة الرئيسية التي يقدمها مؤلف Habr تتعلق بطبيعة تعقيد البرمجيات: حتى لو قام كل مطور بإنشاء تطبيق جديد للوظائف الأساسية — تشفير TLS وتحليل صيغة JSON والتعامل الصحيح مع Unicode — فإن هذا التعقيد لا يختفي. إنه ببساطة ينتقل من مكتبة متاحة علناً وتم كتابتها مرة واحدة وتم التحقق منها بشكل متكرر من قبل المجتمع إلى آلاف التطبيقات المتوازية والمستقلة، كل منها قد يحتوي على أخطاء وثغرات أمنية خاصة به. بعبارة أخرى، رفض مفهوم "الاعتمادية" بحد ذاته لا يلغي المهمة نفسها — تطبيق منطق معقد وعرضة للأخطاء — بل يغير فقط من يحلها ومتى.

هذا يعود إلى حل وسط أساسي في أنظمة المصدر المفتوح: المكتبات المركزية والمستخدمة على نطاق واسع، رغم جميع مخاطر سلسلة التوريد، تستفيد من تأثير الحجم — يراجع الآلاف من الأشخاص نفس الكود، يتم العثور على الأخطاء وإصلاحها مرة واحدة للجميع. نموذج "الإنشاء من جديد لكل مشروع" من جهة أخرى يفقد هذا الاختبار الجماعي مقابل التخصيص وغياب الاعتماديات الخارجية — ومن غير الواضح ما إذا كان هذا التبادل يستحق العناء، خاصة للمنطق الحرج للبنية التحتية مثل التشفير أو تحليل بروتوكول الشبكة، حيث تكون تكلفة الخطأ عالية والحالات الحدية النادرة يصعب توقعها من إنشاء كود واحد.

توحد النظام البيئي npm، الذي يشير إليه Marcelo Emmerich في تحليله، ملايين الحزم وتبقى أكبر سجل في العالم لتطوير JavaScript — وفي نفس الوقت أحد أكثر الأهداف تكراراً للهجمات على سلسلة التوريد، عندما ينشر المهاجمون إصدارات خبيثة من الحزم الشهيرة أو ذات الأسماء المتشابهة على أمل تثبيتها عن طريق الخطأ من قبل المطورين أو أنظمة البناء الآلية. إن هذه التجربة التي دامت سنوات في محاربة مثل هذه الحوادث بالذات هي التي تفسر لماذا تبدو فكرة رفض الكود المشترك تماماً لصالح الإنشاء "من الصفر" جذابة لجزء من المجتمع، حتى وإن كانت، كما يظهر تحليل Habr، تنقل مشكلة التعقيد إلى مكان جديد وأقل اختباراً بدلاً من حلها.