Cognition تطلق FrontierCode 2.0: أفضل نتيجة لا تتجاوز 45,5%

نشرت Cognition، الشركة التي تقف وراء الوكيل Devin، مقياس FrontierCode 2.0، وهو الجيل الثاني من مقياس لا يقيّم اجتياز الاختبارات، بل «قابلية الدمج» (mergeability) للكود: أي هل كان مسؤول صيانة (maintainer) في مشروع حقيقي سيقبل طلب السحب (pull request) هذا. وكانت أفضل نتيجة من نصيب Claude Opus 5.5 بنسبة 45,5%، بينما بلغت نتيجته 54,6% في الإصدار السابق FrontierCode 1.1. اتسعت الفجوة بين النماذج، وسقف المقياس بعيد: فهو غير مشبع.

لماذا شدّدت Cognition المعيار

وفق تجربة Devin، لا يزال تطوير البرمجيات بالوكلاء بعيدًا عن كونه مشكلة محلولة. فالنماذج تُخطئ في تخمين نية المستخدم، وتنتهك قيودًا غير بديهية، ولا تتوقع العواقب بعيدة المدى للتعديلات، ولذلك يضطر الإنسان إلى التدخل. ولا تلتقط معظم مقاييس البرمجة هذه المشكلة، لأنها تقدّم مواصفات مفصّلة وتصل سريعًا إلى حدّ التشبع. ومثال ذلك المهمة vf2-speedup-networkx من Terminal-Bench 4.0، إذ يُوصف فيها المنهج والصيغة وشروط التحقق بالكامل، بما في ذلك تحقيق تسريع لا يقل عن 5000 مرة.

أما FrontierCode فمبنيّ على نحو مختلف. فقد أمضى أكثر من 20 من مسؤولي صيانة المشاريع المفتوحة أكثر من 40 ساعة على كل مهمة، وأعدّوها انطلاقًا من مستودعاتهم الخاصة. وفي الإصدار 2.0 استُمدّت المهام من مستودعات يزيد عددها بنسبة 55%، وهي تشمل رقعات أمنية وتحسينات في الأداء. وأصبح عدد المعايير الحاجبة أكبر بنسبة 43%. وتعدّل الحلول المرجعية في المتوسط ملفات أكثر بنسبة 67% وأسطرًا أكثر بنسبة 89%، وقواعد الكود أكبر بنسبة 25%. وعززت Cognition التدقيق على نحو منفصل: ففي 80% من المهام يختلف الحل المرجعي عن طلب السحب الأصلي في upstream (كانت النسبة 60% في الإصدار 1.0). بل إن أحد عمليات التدقيق الآلي عثر على ثغرة أمنية في تنفيذ upstream، وأُبلغ مسؤولو الصيانة بها.

الجدول: من خسر كم

فيما يلي التقييمات بصيغة «FrontierCode 1.1 ← FrontierCode 2.0»:

• Claude Opus 5.5 — 54,6% ← 45,5%. المتصدر، ويقع على الحد الباريتي (Pareto frontier) من جهة الكلفة المرتفعة.
• GPT-6 Astra — 53,3% ← 42,8%.
• Grok 4.7 — 47,6% ← 28,6%.
• Gemini 4 Argon — 47,5% ← 26,3%.
• Muse Wonder 1.0 — 47,0% ← 24,3%.
• SWE-2 — 50,0% ← 23,9%.
• DeepSeek V4.1 Flash — 43,9% ← 19,3%.
• Kimi K3 — 44,2% ← 17,7%.

وعلى الحد الباريتي «الكلفة مقابل الجودة» يقف مع Opus 5.5 كلٌّ من Luna وHaiku وSol عند الطرف الأرخص. وتُبرز Cognition بصورة منفصلة GPT-6.1 Sol لنتيجته القوية قياسًا إلى كلفته. والخلاصة بشأن النماذج المفتوحة قاسية: فهامش التحسن كبير، ولا سيما لدى نماذج OSS الغربية.

الإتقان بدل الطاعة

التغيير الرئيس هو ارتفاع حصة معايير «thoroughness» (الإتقان): فقد ارتفع عدد المعايير الحاجبة من هذا النوع من 168 إلى 501، أي إلى ثلاثة أضعاف. وتتحقق هذه المعايير مما ينبغي للوكيل أن يستنتجه من التعليمات والكود، مع أن ذلك لم يُذكر صراحةً. فعلى سبيل المثال: إصلاح الخلل في جميع المواضع لا في الموضع المذكور وحده، أو دعم أنواع بيانات الإدخال المجاورة إذا كان كود مشابه يعالجها بالفعل. وارتفعت نسبة الفحوص الفاشلة هنا من 11,7% إلى 19,2%، وهذا أعلى معدل فشل بين الفئات. أما في فئة core behavior فبلغت 14,9% مقابل 9,5%، وفي التوافق العكسي 5,9% مقابل 2,9%.

وتغيّرت فئات المعايير الحاجبة الأخرى على النحو التالي: core behavior من 399 إلى 353، وتجنّب الانحدارات (regressions) من 174 إلى 259، وجودة الاختبارات من 202 إلى 213، وlint/format/typecheck من 112 إلى 183، وscope من 56 إلى 123، والتوافق العكسي من 85 إلى 76، والترجمة البرمجية (compilation) من 86 إلى 69، وسلامة الاختبارات من 48 إلى 48.

بذل جهد أكبر ليس دائمًا أفضل

لا يكافئ FrontierCode على حجم الكود المكتوب، ولذلك قد ينخفض التقييم مع ارتفاع مستوى الاستدلال. والسبب هو معايير scope. فعند Claude Opus 5 تنخفض نسبة معايير scope المجتازة من 69,2% عند المستوى low إلى 51,1% عند المستوى max، وعند Opus 4.8 من 81,9% إلى 70,9%، وعند Claude Fable 5 من 79,1% إلى 63,4%، وعند GPT-5.6 Sol من 79,7% إلى 68,3%. وفي المقابل ترتفع معايير التنفيذ: عند Opus 5 من 79,3% إلى 83,0%. أي إن النماذج تعدّل ملفات أكثر عند «بذل جهد» أكبر، وأحيانًا تعدّل ما لا لزوم له. وتذكر Cognition من الأسباب الأقل أهمية تزايدَ حالات الغش (مثل التحميل العرضي لـ commit يتضمن الحل)، و«فرط التفكير» الذي يقنع فيه النموذج نفسه بقراءة خاطئة للمهمة.

وفي الإصدار 2.0 خُفّفت متطلبات scope كي لا تُفرض عقوبة على سلوك غير متوقع لكنه مقبول: فانخفض متوسط نسبة الفشل من 9,0% إلى 3,8%. وعلى مجموعة تضم Claude Opus 5.5 وClaude Fable 5.1 وGPT-6.1 Sol وGPT-6 Astra، يفشل معيار الإتقان في 26,0% من الفحوص عند المستوى low، وفي 15,3% عند المستوى max.

ويُعدّ مثال Mock Service Worker دالًّا: المهمة هي إصلاح خلل لا تعيد فيه الدالة resetHandlers() تشغيل المحلِّلات المولِّدة (generator resolvers). ولم يجتز Opus 5.5 أيًّا من التشغيلات الخمسة، عند أي مستوى من الجهد من low إلى max: فقد عمل الإصلاح كما هو مُعلن، لكن المُقيِّم (grader) سجّل ملاحظة على منهج التعديل نفسه.

ما ينبغي أن تراعيه الفرق

إذا كنتم تختارون نموذجًا للبرمجة المستقلة، فلا تنظروا إلى pass@1 في المهام الموصوفة بدقة، بل إلى السلوك عند نقص المعلومات في الـ prompt. وعمليًا: خصّصوا مراجعة للكود بحثًا عن التعديلات الجانبية والحالات «المجاورة» الفائتة، ولا تضبطوا أقصى مستوى من reasoning effort افتراضيًا دون قياسه على مستودعاتكم، وقارنوا النماذج بكلفة التشغيل لا بالدرجة وحدها. وبالنسبة إلى حزمة المصادر المفتوحة، فإن نتائج 2.0 سبب لتخصيص هامش للتعديل اليدوي في المرحلة الأخيرة.