كشف فريق البحث في شركة "جيت برينز" (JetBrains Research) عن فجوة جوهرية في كيفية تقييم وكلاء البرمجة المعتمدين على الذكاء الاصطناعي، مؤكدين أن المعايير الحالية لا تعكس بدقة الطريقة التي يتفاعل بها المطورون مع هذه الأدوات في بيئات العمل الحقيقية. ومن خلال تحليل 4,782 جلسة عمل لمطورين يستخدمون بيئات التطوير المتكاملة (IDEs)، وجد الباحثون أن النماذج الحالية تُختبر في ظروف مثالية لا تشبه الواقع المعقد للبرمجة اليومية.
الفجوة بين معايير التقييم والواقع العملي
أظهرت الدراسة أن المعايير الشهيرة مثل (SWE-Bench Pro) تعتمد بشكل شبه كامل (بنسبة 93.8%) على مهام إصلاح الأخطاء أو إضافة ميزات جديدة يتم تقديمها في رسالة واحدة مكتملة التفاصيل. ومع ذلك، كشف تحليل جلسات الإنتاج الحقيقية أن أقل من نصف ما يطلبه المطورون من وكلاء البرمجة يتعلق فعلياً بإصلاح الأخطاء أو إضافة الميزات.
تتوزع بقية طلبات المطورين في الواقع على مهام متنوعة تشمل:
- الاستفسار عن بنية الكود وفهم كيفية عمل أجزاء معينة من المشروع.
- التخطيط للخطوات القادمة في عملية التطوير.
- مراجعة الكود (Code Review) وإعادة الهيكلة (Refactoring).
- تنفيذ الأوامر البرمجية واستكشاف الأخطاء وإصلاحها.
بالإضافة إلى ذلك، وجد البحث أن نصف الجلسات الحقيقية تتكون من رسالة واحدة، بينما تمتد الجلسات المتبقية لتشمل تفاعلات متعددة، حيث تصل المتطلبات إلى الوكيل بشكل تدريجي ومجزأ، وهو ما يفتقر إليه معيار (SWE-Bench) التقليدي الذي يقدم المهمة كاملة في رسالة واحدة مصقولة.
إطار SWE-TaskFlow: نحو محاكاة أدق لسلوك المستخدم
لمعالجة هذا القصور، قدمت "جيت برينز" إطار عمل جديد يسمى (SWE-TaskFlow). لا يهدف هذا الإطار إلى استبدال المعايير الحالية، بل إلى تحويلها لتصبح أكثر واقعية عبر ثلاث آليات رئيسية:
- تقسيم المهام (Task Splitting): يتم تقسيم المهمة البرمجية الواحدة إلى ثلاث طلبات متتالية، بحيث لا يرى الوكيل الطلب الثاني إلا بعد إنجاز الأول، مما يختبر قدرته على التعامل مع المتطلبات المتدرجة.
- إضافة أسئلة المستودع (Repository Questions): يتم توليد أسئلة تتطلب من الوكيل شرح أجزاء من الكود الحالي قبل أو أثناء تنفيذ المهمة، وهو سلوك شائع جداً لدى المطورين الحقيقيين.
- مواءمة تدفق المهام (Task Flow Alignment): استخدام خوارزميات لتحسين تسلسل الرسائل وأنواعها لتطابق توزيع الجلسات الحقيقية بناءً على مقياس (TFAS) الذي ابتكره الفريق.
نتائج التجارب: التكلفة مقابل الدقة
اختبر الباحثون الإطار الجديد على عدة نماذج متقدمة، بما في ذلك (GPT-5.6 Luna) و(GPT-5.6 Terra) و(Gemini 3.7 Flash). وأظهرت النتائج أن تقسيم المهام إلى رسائل متعددة أدى إلى زيادة تكلفة التشغيل بمعدل يتراوح بين 2.0 إلى 2.6 ضعفاً لكل مهمة. تعكس هذه الزيادة الجهد الإضافي الذي يبذله الوكيل عندما تصل المتطلبات بشكل مجزأ.
من الناحية التقنية، لم تتأثر معدلات نجاح النماذج في حل المهام (Resolve Rates) بشكل كبير عند تقسيم المهام، حيث انخفضت بنسبة طفيفة تتراوح بين 4 إلى 5 نقاط مئوية، مما يشير إلى أن التحدي الأكبر يكمن في زيادة استهلاك الموارد والوقت وليس في صعوبة المهمة ذاتها.
ما الذي يتغير عملياً للمطورين والشركات؟
تكمن أهمية هذا البحث في تحويل تركيز صناعة الذكاء الاصطناعي من مجرد "حل المشكلات البرمجية" في خطوة واحدة، إلى بناء "مساعدين تفاعليين" قادرين على إدارة الحوار الطويل وفهم السياق المتغير. بالنسبة للشركات المطورة للنماذج، يعني هذا ضرورة تحسين قدرات الذاكرة طويلة المدى للوكلاء وقدرتهم على معالجة المعلومات التي ترد تباعاً دون فقدان الهدف النهائي للمهمة.
كما يفتح (SWE-TaskFlow) الباب أمام إمكانية التحقق المرحلي من جودة عمل الوكيل؛ فبدلاً من تقييم النتيجة النهائية فقط، يمكن للمطورين الآن تقييم أداء الوكيل بعد كل رسالة، مما يساعد في اكتشاف الانحرافات عن المسار الصحيح في وقت مبكر من عملية البرمجة المدعومة بالذكاء الاصطناعي.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.