SWE-NFI: Studying and Benchmarking Coding Agents for Non-Functional Improvements
تقدم هذه الورقة SWE-NFI، وهو معيار مرجعي يتكون من 188 مهمة من واقع الحياة و92 قاعدة قابلة للتنفيذ صُممت لتقييم وكلاء البرمجة في التحسينات غير الوظيفية، مما يكشف أنه بينما يحقق الوكلاء صحة وظيفية عالية، إلا أنهم يتخلفون بشكل كبير عن المطورين البشر في تنفيذ تحسينات الكود التي تحافظ على السلوك.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تعلم روبوتاً كيفية كتابة الكود البرمجي. لفترة طويلة، كانت الطريقة الوحيدة لاختبار ما إذا كان الروبوت يقوم بعمل جيد هي السؤال: "هل يعمل البرنامج؟". إذا بنى الروبوت آلة حاسبة تجمع الأرقام بشكل صحيح، فإنه يحصل على نجمة ذهبية. ولكن في العالم الحقيقي، تشبه كتابة البرمجيات بناء منزل؛ فمجرد كون السقف لا يسرب والمنازل تفتح أبوابها لا يعني بالضرورة أن المنزل مريح للعيش فيه. ربما تكون الأسلاك متشابكة في فوضى خلف الجدران، أو أن الطلاء يتقشر، أو أن تعليمات كيفية استخدام مفتاح الضوء مكتوبة بحبر غير مرئي. هذه هي الأجزاء "غير الوظيفية" للمنزل: مدى سهولة إصلاحه، ومدى أمانه، ومدى جمال مظهره.
مؤخراً، أصبحت برامج الكمبيوتر الذكية التي تسمى "وكلاء البرمجة" (coding agents) جيدة جداً في بناء الهيكل الأساسي للبرمجيات. يمكنهم إصلاح الأخطاء وإضافة ميزات جديدة. لكن لم يكن أحد يعرف حقاً ما إذا كان بإمكان هؤلاء الوكلاء أيضاً القيام بالعمل الفوضوي والممل، ولكن المهم للغاية، المتمثل في تنظيف الكود، وتنظيم الأسلاك، وكتابة تعليمات واضحة دون كسر أي شيء كان يعمل بالفعل. هذا هو السؤال الذي قرر فريق من الباحثين من جامعات في كندا والصين وسنغافورة الإجاء عنه. لقد أرادوا معرفة ما إذا كان بإمكان هؤلاء المساعدين الرقميين أن يكونوا أكثر من مجرد بنائين وظيفيين، وأن يصبحوا مربي برمجيات حقيقيين.
ولمعرفة ذلك، أنشأ الباحثون اختباراً جديداً يسمى SWE-NFI. فكر في هذا الاختبار كقائمة مراجعة ضخمة ومؤتمتة للمفتش. فبدلاً من مجرد التحقق مما إذا كان البرنامج يعمل، تحتوي قائمة المراجعة هذه على 92 قاعدة محددة حول مدى "جودة" شكل الكود وشعوره. وتتحقق هذه القواعد من أشياء مثل: "هل كتبت شرحاً واضحاً لما تفعله هذه الدالة؟" (التوثيق)، و"هل تعاملت مع الأخطاء بأمان حتى لا يتوقف البرنامج عن العمل؟" (معالجة الأخطاء)، و"هل استخدمت أدوات حديثة بدلاً من الأدوات القديمة والصدئة؟" (قيود المكتبات).
بنى الباحثون هذا الاختبار باستخدام 188 مثالاً من الواقع مأخوذة من مشاريع برمجية حقيقية قام البشر بإصلاحها بالفعل. لقد أخذوا نسخة "ما قبل" الكود، وأعطوها لمختلف وكلاء البرمجة، وطلبوا منهم تحسينه دون تغيير ما يفعله فعلياً. ثم استخدموا قائمة المراجعة المكونة من 92 قاعدة لتقييم الوكلاء. كما كان لديهم "مرجع بشري" للدرجات، وهو مدى جودة مطور بشري حقيقي قام بتحسين نفس قطعة الكود في العالم الحقيقي.
كانت النتائج بمثابة مواجهة مع الواقع. فقد كان أفضل وكلاء البرمجة جيدين حقاً في التأكد من أن الكود لا يزال يعمل (بنسبة نجاح بلغت 70.0% في الصحة الوظيفية). ومع ذلك، عندما تعلق الأمر بجعل الكود أفضل بالطرق التي يهتم بها البشر، فقد عانى الوكلاء. لقد أخفقوا في الوصول إلى مستوى المطورين البشر في كل فئة تقريباً.
كانت الفجوة الأكبر في "أنماط المنطق" (Logic Patterns)، وهو ما يشبه السلامة الهيكلية للكود. قام البشر بتحسين هذا المجال بمتوسط درجة قدره 1.5، بينما تمكن أفضل وكلاء البرمجة فقط من تحقيق ما بين 0.0 و1.3. الأمر كما لو أن الروبوتات استطاعت بناء جدار متين، لكنها لم تستطع معرفة كيفية جعل الطوب يصطف بشكل مثالي أو كيفية إضافة قوس جميل.
كما وجدت الدراسة بعض الخصائص المثيرة للاهتمام:
- ملف واحد مقابل ملفات متعددة: كان الوكلاء جيدين في إصلاح ملف واحد، ولكن عندما كان عليهم تنسيق التغييرات عبر ملفات متعددة في وقت واحد (مثل إصلاح الأسلاك في المطبخ و غرفة المعيشة في آن واحد)، أصبحوا أسوأ بكثير.
- التكلفة مقابل الجودة: تحقق الباحثون من مقدار "الوقود" (وقت الكمبيوتر ورموز البيانات/tokens) الذي استهلكه الوكلاء. ووجدوا أن إنفاق المزيد من المال أو الوقت لم يؤدِ دائماً إلى نتائج أفضل. فقد استهلك أحد الوكلاء 100 ضعف الموارد التي استهلكها وكيل آخر، ومع ذلك لم ينتج تحسينات أفضل بشكل ملحوظ في الكود.
- الاتساق: بمجرد أن يتمكن وكيل ما من كتابة كود يعمل بالفعل، فقد كان متسقاً جداً في إجراء تلك التحسينات الصغيرة. المشكلة الحقيقية كانت في جعل الكود يعمل في المقام الأول.
باختصار، تشير الورقة البحثية إلى أنه بينما أصبح ريبوتات البرمجة لدينا جيدين جداً في "ماذا" (جعل الأشياء تعمل)، إلا أنه لا يزال أمامهم طريق طويل في "كيف" (جعل البرمجيات قابلة للصيانة، وآمنة، ونظيفة). إنهم متدربون رائعون يمكنهم اتباع التعليمات، لكنهم لم يتعلموا بعد فن كونهم حرفيين مهرة يعرفون كيفية ترتيب الورشة. ويأمل الباحثون أن توفر لهم قائمة المراجعة الصارمة الجديدة هذه، القدرة على تعليم الجيل القادم من وكلاء البرمجة ليس فقط بناء البرمجيات، بل العناية بها أيضاً.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.