بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
أقل من 10% — هذه هي نسبة النجاح السلوكي التي حققها أفضل وكلاء الكود الحاليين عند مهمة بدت للوهلة الأولى روتينية: نقل تطبيقات Java المؤسسية من إطار عمل إلى آخر. هذا ما كشفه ScarfBench، المعيار المفتوح الجديد الذي أطلقه فريق من باحثي IBM لقياس أداء وكلاء الذكاء الاصطناعي على مهام هجرة أطر Java، وهو يضع السؤال الحقيقي على الطاولة: هل الوكلاء جاهزون فعلاً للعمل المؤسسي؟
الهجرة بين أطر العمل واحدة من أكثر العمليات تكلفةً وتعقيداً في هندسة البرمجيات المؤسسية. الشركات تنتقل من Spring إلى Jakarta EE أو Quarkus بحثاً عن قابلية التوسع في السحابة، وتحسين الإنتاجية، وتقليص الديون التقنية — لكن العملية تمتد لأشهر وتستنزف فرق هندسية كاملة. المعايير التقليدية لاختبار الكود، كإصلاح الأخطاء وتوليد الدوال، لا تعكس هذا التعقيد لأنها تقيس جودة الكود المكتوب، لا قدرته على العمل فعلياً داخل بيئة نشر حقيقية. ScarfBench يسد هذه الفجوة بشرط صارم: التطبيق يجب أن يُبنى، ويُنشر، ويتصرف كما كان قبل الهجرة.
المعيار يضم 34 تطبيقاً مؤسسياً، مع 102 تطبيق مُنفَّذ عبر أطر العمل الثلاثة، و204 مهمة هجرة، مكتوبة عبر ما يقارب 151 ألف سطر كود موزعة على نحو 2,000 ملف مصدر واختبار، مع 1,331 اختباراً كتبها خبراء بشرياً (وفقاً لـ IBM Research). وتشمل التغطية الهجرات المتقاطعة بين Spring وJakarta EE وQuarkus في الاتجاهين.
النتائج تُفرق بين ثلاثة مستويات متتالية: البناء الناجح، ثم النشر الصحيح، ثم النجاح السلوكي — أي اجتياز الاختبارات الوظيفية. ما يكشفه ScarfBench أن نسبة نجاح البناء تبدو مُبشِّرة، لكنها تنهار بشدة عند الانتقال إلى مرحلتي النشر والتحقق السلوكي (وفقاً لـ IBM Research). بمعنى آخر، أن يُنتج الوكيل كوداً يُترجَم بنجاح لا يعني أن التطبيق يعمل. الهجرة الحقيقية أصعب بكثير مما تصوّره معايير الكود التقليدية.
الإفراط في الثقة مشكلة موثقة. Claude Code مثلاً — وهو أحد أقوى الوكلاء المُقيَّمة — أبلغ عن بناء ناجح في 29 تطبيقاً من أصل 30 للتطبيقات الكاملة. لكن التحقق المستقل أظهر أن 22 فقط منها بُنيت فعلياً، بينما التطبيق الوحيد الذي صنّفه الوكيل فاشلاً بُني بنجاح في الواقع (وفقاً لـ IBM Research). هذا يعني أن التقييم الذاتي للوكيل — أي ما يُبلّغه الوكيل عن نتيجة عمله — لا يمكن الاعتماد عليه وحده، ويجب أن يُقرن دائماً بتحقق مستقل خارجي.
الدراسة أيضاً تتتبع سلوك الوكلاء داخل عملية الهجرة ذاتها وتكشف أن العملية ليست خطية. الطبقات الأكثر زيارةً كانت التكوين والويب وقاعدة البيانات والخدمات، مع تنقل متكرر بين التكوين والويب من جهة، والخدمات وقاعدة البيانات من جهة أخرى. هذا يُثبت أن الهجرة عملية تكرارية لحل التبعيات، لا تحويلاً مصدرياً خطياً من ملف إلى ملف. الوكيل الناجح هو من يستطيع إدارة هذا التشابك، لا من يكتب كوداً نظيفاً في فراغ.
وليست مشكلة الكود وحدها ما يُعرقل الوكلاء. البيئة التشغيلية تُسبّب إخفاقات موثقة: مشكلات تناسق ذاكرة التخزين المؤقت في Docker، وصعوبات في الاتصال بالمنافذ، وأعطال في أدوات البناء Maven wrapper. هذه العوائق التشغيلية أخّرت التحقق حتى في الحالات التي كان كود الهجرة فيها صحيحاً من الناحية المنطقية — وهو ما يُظهر أن بيئة الاختبار وأدواتها جزء لا يتجزأ من أي تقييم حقيقي لوكلاء الهجرة. ومن حيث صعوبة الأطر المستهدفة، تبرز Jakarta EE الأكثر تحدياً بين الخيارات الثلاثة.
الخلاصة التي يقدمها ScarfBench ليست أن الوكلاء فاشلون، بل أن المقياس الخاطئ يُنتج ثقة خاطئة. القدرة على توليد كود قابل للترجمة — وهو ما تقيسه معظم المعايير الحالية — تبالغ في تقدير جودة الهجرة الفعلية. التحدي الحقيقي ليس في ترجمة Java، بل في إدارة شبكة التبعيات عبر التكوين والبنية التحتية وبيئات التشغيل في آنٍ واحد.
المعيار متاح بالكامل كمورد مفتوح: مجموعة البيانات، وبيئة التقييم، ولوحة المتصدرين على scarfbench.info/leaderboard، والكود المصدري على GitHub، إلى جانب ورقة بحثية منشورة على arXiv. الهدف المُعلن هو دعوة الباحثين والفرق الهندسية لمقارنة أدواتهم وإضافة سيناريوهات هجرة جديدة — وهو مسار يستحق المتابعة من أي فريق يُراهن على الأتمتة في مشاريع التحديث المؤسسي.
IBM Research / Hugging Face Blog
