FrontierCode Diamond: تصحيحات قابلة للدمج بنسبة 13.4% في 50 مهمة صعبة (يونيو 2026)

تتوفر مواد إضافية حول إعداد الأدوات في وثائق Ailoot.

ما هو FrontierCode، ولماذا هو مهم؟#

Cognition هي الشركة التي تقف وراء Devin (أول مهندس ذكاء اصطناعي مستقل، في مارس 2024) وWindsurf (التي استحوذت عليها الشركة في يوليو 2025). كما تطوّر الشركة سلسلة نماذجها الخاصة SWE-1.x. نُشر الاختبار على المدونة العامة في cognition.com/blog/frontier-code.

التحول الأساسي لا يتعلق بأرقام جديدة، بل بالمقياس الذي تُقاس به الأشياء الآن.

للاختبار ثلاثة مستويات من الصعوبة: Extended (150 مهمة، المجموعة كاملة)، وMain (أصعب 100 مهمة، بما فيها Diamond)، وDiamond (50 مهمة شديدة الصعوبة). تعمّدت Cognition إبقاء Diamond «غير مشبع إلى حد كبير»؛ فحتى أفضل نموذج يحل أقل من 15%. والهدف هو منح الاختبار مساحة تكفي لعام كامل، ومنع تشبعه خلال شهر كما حدث مع HumanEval.

ما الذي يقيسه FrontierCode: «هل سيدمج مسؤول الصيانة هذا الطلب؟»#

محاور التقييم الستة (وفق مدونة Cognition الرسمية):

1. الصحة السلوكية — هل يحل التصحيح المهمة؟
2. السلامة من التراجعات — هل يتجنب كسر الشيفرة الموجودة؟
3. النظافة الميكانيكية — هل يجتاز فحوص البناء وlint والأسلوب؟
4. صحة الاختبارات — هل الاختبارات التي كتبها الوكيل صالحة (الاختبارات التي تنجح مع أي شيفرة لا تُحتسب)؟
5. النطاق — هل يتجنب التصحيح تعديل الملفات التي لم يُطلب تعديلها؟
6. جودة الشيفرة — هل تتبع الشيفرة أعراف المشروع وهل هي مقروءة؟

لكي يُعدّ التصحيح قابلًا للدمج، يجب أن يجتاز المحاور الستة كلها. وإذا أخفق في محور واحد، فلن يُدمج.

هذا هو التحول الرئيسي في المنظور. وكما تقول Cognition: «أصبحت الصحة الآن شرطًا أساسيًا». في السابق، كانت الاختبارات تسأل: «هل اجتازت الشيفرة الاختبارات؟». أما الآن فتسأل: «هل سيقبل قائد تقني حقيقي إدخالها في المشروع؟».

قدّمت Cognition ثلاث تقنيات جديدة للتقييم:

• Reverse-Classical: يجب أن يفشل الاختبار الذي يكتبه الوكيل على نسخة معطوبة من الشيفرة. وإلا فالاختبار زائف.
• Code Scope: يتحقق فاحص آلي من التزام التصحيح بالملفات وعدد الأسطر المتفق عليهما للمهمة.
• Adaptive Classical Grading: تكيّف أداة LLM «mutagent» الاختبارات الصارمة مع صيغ الحلول الصحيحة.

لماذا لم تعد الاختبارات القديمة صالحة؟#

كان وكلاء الذكاء الاصطناعي قد أتقنوا HumanEval بحلول 2024. وSWE-bench Verified لا يختلف كثيرًا: ففي أغسطس 2025، أقرت OpenAI علنًا بمشكلة تلوث البيانات (أي إن النماذج «رأت» مجموعة البيانات أثناء التدريب). وفقدت الاختبارات قدرتها على التمييز بين أفضل النماذج.

صدرت الدراسة الأساسية التي قوّضت المعيار القديم في مارس 2026.

ما فعلوه:

• اختاروا 4 مسؤولين صيانة نشطين من 3 مستودعات (scikit-learn وSphinx وpytest).
• طلبوا منهم تقييم 296 طلب دمج مولّدًا بالذكاء الاصطناعي من SWE-bench Verified؛ وكانت جميع هذه الطلبات قد اجتازت الاختبارات الآلية.
• قارنوا قرارات مسؤولي الصيانة بقرارات أداة التقييم الآلية.

بعبارة أخرى، يقول الاختبار «اجتاز»، بينما يقول مسؤول الصيانة «لن أدمجه»؛ ويحدث ذلك في المتوسط في ربع الحالات. وأهم 3 أسباب للرفض، من الأقل إلى الأكثر خطورة:

1. جودة الشيفرة — لا تتوافق مع أسلوب المستودع.
2. كسر شيفرة أخرى — تضر بالشيفرة المجاورة.
3. إخفاق الوظيفة الأساسية — لا تحل المهمة بالكامل رغم نجاح الاختبار.

يحوّل FrontierCode هذه المشكلة تحديدًا إلى معيار رسمي. أخذت Cognition هذه الفكرة ووسّعتها إلى اختبار كامل يضم أكثر من 20 مسؤول صيانة بدلًا من 4.

وثمة ضربة أخرى تأتي من دراسة صدرت في ديسمبر 2025 حول أمان التصحيحات التي يولّدها الذكاء الاصطناعي.

وفيها، كانت 61% من حلول SWE-Agent باستخدام Claude 4 Sonnet صحيحة وظيفيًا، لكن 10.5% منها فقط كانت آمنة.

تجتاز الشيفرة الاختبار، ومع ذلك يتسبب كل تصحيح آخر في ثغرة أمنية. لا يمكنك رؤية ذلك إطلاقًا في اختبارات SWE-bench؛ فهي لا تقيس الأمان. يحاول FrontierCode على الأقل رصد المشكلة من خلال محوري «النظافة الميكانيكية» وجودة الشيفرة.

ترتيب النماذج: Opus 4.8 بنسبة 13.4%، وGPT-5.5 بنسبة 6.3%#

ما يلفت الانتباه في الجدول:

• متصدر واضح. يتقدم Opus 4.8 من Anthropic بنحو الضعف على أقرب منافس. والفجوة التي كان من الصعب ملاحظتها في SWE-bench تظهر بوضوح في FrontierCode.
• النماذج المفتوحة لم تلحق بالركب بعد. يحرز Kimi K2.6، أفضل نموذج مفتوح المصدر للبرمجة، 3.8% في Diamond. وهذا أقل من نتيجة Opus 4.8 بثلاث إلى أربع مرات. لم تنشر Cognition نتائج كاملة لـKimi K2.6 في Main وExtended، لذا لا تتوفر بعد مقارنة على المجموعة كاملة.
• أدرجت Cognition نموذجها الخاص بصدق في الجزء الأدنى من الجدول.

تُركت المجموعة الفرعية Diamond «غير مشبعة» عمدًا. وأدرجت Cognition هامش أمان للسنوات القادمة. فإذا كانت الاختبارات السابقة تتشبع خلال 12–18 شهرًا، صُمم FrontierCode ليكون ذا سقف أعلى.

ماذا تعني نسبة «13% قابلة للدمج» لمن يمارس vibe coding باستخدام Claude Code؟#

أولًا، من المهم إعادة صياغة المسألة: مجموعة Diamond في FrontierCode صعبة عمدًا. في المهام العادية ضمن مشروع شركة ناشئة جديد، ومن دون أربعين وحدة مترابطة، يحقق وكيل الذكاء الاصطناعي أداء أفضل بوضوح. يسجل Opus 4.8 نفسه 51.8% من التصحيحات القابلة للدمج في Extended (150 مهمة، المجموعة كاملة). وهذه صورة مختلفة تمامًا.

تنطبق نتيجة 51.8% على مجموعة Extended ذات 150 مهمة في الاختبار. هي أعلى من نتيجة Diamond، لكن لا تقدر أي من النسبتين قابلية دمج تصحيحات كل نموذج في مهامك. ولا يبرر غياب درجات Main أو Extended للنماذج الأخرى افتراض أدائها.

ما يعنيه ذلك لمن يمارس vibe coding ويدفع الشيفرة إلى الإنتاج:

• لم يعد الاختبار الناجح يعني «جاهز للدمج». قد تكون الاختبارات التي يكتبها الذكاء الاصطناعي نفسه عديمة الفائدة؛ إذ تنجح مع أي شيفرة. يقيس FrontierCode ذلك مباشرة عبر Reverse-Classical: إذا لم يفشل الاختبار على نسخة معطوبة، فلا يُحتسب.
• أسلوب المستودع وأعرافه مهمان. إذا كان للمشروع نمط راسخ ولم يتبعه الذكاء الاصطناعي، فلن يقبل متعاون حقيقي التغيير. لا يمثل ذلك مشكلة كبيرة في المشروعات الفردية التي لا قواعد لها. أما في فريق، فهو المشكلة الأولى.
• الاختبارات لا تحل مشكلات الأمان. تذكّر الرقم أعلاه: 10.5% فقط من التصحيحات آمنة رغم أن 61% منها صحيحة. يجب التحقق من هذا الأمر منفصلًا باستخدام أدوات ترصد الرموز السرية وملفات .env وكلمات المرور الافتراضية.
• تجاوز نطاق المهمة خطأ شائع للذكاء الاصطناعي. تطلب منه إصلاح دالة تفويض، فتحصل على تصحيح أعاد أيضًا كتابة الطبقة الداخلية والتسجيل. وهذا أحد محاور FrontierCode الستة.

ما فئات الأخطاء الست التي يرتكبها الذكاء الاصطناعي في المهام الصعبة؟#

لنستعرض كل محور بلغة بسيطة:

1. الصحة السلوكية — هل يحل التصحيح المهمة؟

هذا هو المحور الأساسي. كثيرًا ما يكتب الذكاء الاصطناعي شيفرة تبدو كأنها حل، لكنها تحل المشكلة الخطأ. أطلب منه «إضافة إيصال قراءة إلى الرسالة»، فينتج دالة markAsRead، لكنه لا يربطها بمكوّن الدردشة نفسه. ينجح اختبار الدالة، لكن مهمة العمل لم تُحل.

2. السلامة من التراجعات — هل يتجنب كسر الشيفرة المجاورة؟

يغيّر الذكاء الاصطناعي وحدةً ما، فتتعطل وحدة أخرى. والحالة الأشيع أن يغيّر وكيل الذكاء الاصطناعي توقيع دالة وينسى أنها تُستدعى من 17 موضعًا آخر. لا يمكن اكتشاف ذلك في SWE-bench؛ إذ تُشغّل الاختبارات لملف واحد فقط. أما FrontierCode فيشغّل مجموعة الاختبارات الكاملة للمستودع.

3. النظافة الميكانيكية — هل يجتاز فحوص البناء وlint والأسلوب؟

قد ينتج الذكاء الاصطناعي شيفرة تُجمّع محليًا لكنها تفشل في CI: import مفقود، أو علامات تبويب بدل المسافات، أو مسافتان في نهاية السطر، أو خطأ في eslint.config.js. في مشروع فعلي، الأسلوب ليس نزوة؛ بل قاعدة للفريق.

4. صحة الاختبارات — هل الاختبارات التي كتبها الذكاء الاصطناعي صالحة؟

هذا أصعب المحاور. يكتب الذكاء الاصطناعي اختبارًا وينجح الاختبار، لكنه ينجح مع أي شيفرة، حتى الشيفرة المعطوبة. رأيت ذلك مرات عديدة: يتحقق الاختبار مما إذا كان «النص البرمجي قد تعطل؟» بدلًا من «هل أعاد النتيجة الصحيحة؟». تلتقط Reverse-Classical في FrontierCode هذه الحالة تحديدًا.

5. النطاق — هل يتجنب التصحيح تعديل الملفات غير ذات الصلة؟

أطلب إصلاح دالة واحدة، فأحصل على تصحيح يمس 12 ملفًا، بما فيها ملفات لا علاقة لها بالمهمة. هذه هي «المبادرة» نفسها من الذكاء الاصطناعي التي تضر بمشروع الإنتاج عندما تغيّر أشياء لم أطلب منه تغييرها. وهذا المحور مانع قاطع في FrontierCode.

6. جودة الشيفرة — هل تتبع الشيفرة أعراف المستودع؟

يكتب الذكاء الاصطناعي دالة من «الصفر» بدل استخدام المساعدات الموجودة في lib/. أو يختار أسماء متغيرات لا تتوافق مع أسلوب المشروع. أو يضع المنطق في طبقة معمارية خاطئة. من منظور الاختبار، كل شيء يعمل. أما من منظور قائد تقني، فلن تُدمج الشيفرة.

كيفية التحقق من شيفرة الذكاء الاصطناعي قبل إجراء push: 5 خطوات#

1. شغّل مجموعة الاختبارات كاملة، وليس الاختبارات المرتبطة بالتغيير فقط

   كثيرًا ما يغيّر الذكاء الاصطناعي شيفرة تتجاوز المهمة. وستظهر المشكلة في اختبارات الوحدات المجاورة. أشغّل مجموعة الاختبارات كاملة بالأمر الوحيد npm test، من دون تحديد مسار، بدلًا من تشغيل اختبارات ملف بعينه فقط. وفي المشروعات الكبيرة، من الملائم تشغيل ذلك بالتوازي باستخدام git worktree (راجع Git worktree في Claude Code).

2. شغّل فحوص lint والأسلوب والأنواع

   ثلاثة أوامر بالترتيب: eslint .، وprettier --check .، وtsc --noEmit. قد لا ينتبه وكيل الذكاء الاصطناعي إلى علامات التبويب أو إلى مسافة زائدة في نهاية السطر. إذا كان المشروع يفرض فحوصًا صارمة، فشغّلها محليًا قبل الإصدار.

3. اختبر الاختبار نفسه

   هذه أهم خطوة من بين الفحوص الخمسة. أُحدث «عطلًا» صغيرًا في الشيفرة (أغيّر return true إلى return false). يجب أن يفشل الاختبار. إذا لم يفشل، فقد كتبه الذكاء الاصطناعي لمجرد الاستعراض، وهو عديم الفائدة. أحذف الاختبار وأطلب من الذكاء الاصطناعي إعادة كتابته مع شرط إلزامي: يجب أن يفشل الاختبار على النسخة المعطوبة.

4. تحقّق من الملفات التي عدّلها الذكاء الاصطناعي

   يعرض الأمر git diff --stat الملفات التي تغيّرت وعدد الأسطر. إذا عدّل الذكاء الاصطناعي 12 ملفًا استجابةً لطلب «إصلاح نموذج التواصل»، فقد تجاوز نطاق المهمة. أتراجع عن التغييرات الإضافية بأمر واحد لكل ملف.

5. أجرِ فحصًا أمنيًا باستخدام مهارة جاهزة

   لا تكشف الاختبارات حقن SQL أو كلمات المرور المضمنة في الشيفرة. أستخدم مهارة أمنية جاهزة لـClaude Code (راجع 754 مهارة أمنية جاهزة). وعلى الأقل، أبحث يدويًا في المشروع عن الكلمات «password» و«secret» و«key»، وأتحقق من اكتمال .env.example.

تغطي الخطوات الخمس 5 من محاور FrontierCode الستة (1–5). ويُفحص المحور السادس، جودة الشيفرة، آليًا بواسطة lint وبمراجعة بشرية.

ما الذي يحسّن فعلًا فرص الحصول على شيفرة قابلة للدمج؟#

في مشروع غير مُعدّ، لا يرى وكيل الذكاء الاصطناعي إلا الملف الذي فتحته له. ليست لديه سجلات قراراتك أو أعرافك أو خريطة وحداتك. لا يمثل ذلك مشكلة كبيرة مع التغييرات البسيطة، لكن غياب سياق المشروع خطر يستحق المعالجة في التغييرات الصعبة. لا تعزل نسبة 13.4% في الاختبار جودة السياق باعتبارها السبب.

ما يلزمك لتحويل هذه النسبة البالغة 13% إلى شيء يمكنك دفعه فعليًا إلى الإنتاج:

1. قواعد المشروع — لكي يعيد الذكاء الاصطناعي إنتاج طريقة تفكيرك بدلًا من متوسط ما على الإنترنت.

هذه مجموعة من حلولك الجاهزة وعاداتك وقواعدك المستفادة، بصيغة يقرأها وكيل الذكاء الاصطناعي مع كل طلب. عندما يصبح لديك أكثر من 30 قاعدة، يتوقف الذكاء الاصطناعي عن اختراع «متوسط الصناعة» ويبدأ بتقديم اقتراحات بأسلوبك. ويمكن معالجة تجاوز نطاق المهمة بسطر واحد في القواعد: «لا تلمس الملفات خارج تلك المذكورة صراحةً في الطلب».

2. خريطة المشروع — مجلد يصف المشروع.

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

3. Context Engineering — إدارة ما يراه الذكاء الاصطناعي قبل الطلب.

لا يتعلق الأمر بـ«كيفية صياغة prompt»، بل بـ«ما الذي يجب وضعه في نافذة السياق قبل prompt». يتضمن ذلك CLAUDE.md والمتطلبات المسبقة وروابط مستهدفة للملفات. وهذا يعالج إخفاقات الصحة السلوكية وجودة الشيفرة.

استخدم هذا المزيج تحضيرًا للفحوص، وليس دليلًا على اجتياز خمسة محاور بالفعل. تحقق من السلوك وعدم التراجع والاختبارات والنطاق وجودة الشيفرة في التصحيح الفعلي قبل قبوله.

وهناك طبقة إضافية هي وكلاء المراجعة:

• Cursor Bugbot — يراجع كل PR. ووفقًا لـCursor، تعالج الأداة نحو 2 مليون PR شهريًا.
• الوكلاء الفرعيون المتداخلون في Claude Code v2.1.172 — يكتب وكيل الشيفرة، ويراجعها وكيل ثانٍ، ويشغّل الاختبارات وكيل ثالث. إنها الفكرة نفسها التي يقوم عليها FrontierCode: الفصل بين دوري «الكاتب» و«القائد التقني».

راجع أيضًا: أمان Vibe Coding، وكيفية إعداد Claude Code كي لا يكسر مشروعك ليلًا، ومفهوم Context Engineering.

للاطلاع على مواد إضافية حول العمل مع الأدوات، راجع وثائق Ailoot.