يقوم اختبار CodeVetter الإصدار الأول (v1) بتشغيل 27 حالة اصطناعية عبر مسار مراجعة برمجية مدعوم بالذكاء الاصطناعي، ويسجل ما إذا كانت الأداة تكتشف الأخطاء المزروعة. ثم يقوم بحساب النجاح أو الفشل لكل حالة.
لماذا يكتسب هذا الاختبار أهمية
يطرح الاختبار سؤالاً ضيق النطاق: هل يمكن لمراجع معين التعرف على العيوب الدقيقة التي زرعها مصممو الاختبار في هذه المجموعة الثابتة من مقتطفات الكود؟ يمكن للمطورين استخدام النتيجة كفحص سريع لتغطية المشكلات. وبما أن المستودع (repository) يوفر حزم المهام ونص التقييم، يمكن لأي شخص إعادة تشغيل الاختبار والحصول على نفس الأرقام.
ما لا يثبته هذا الاختبار
إن مجموعة اختبار اصطناعية مكونة من 27 حالة ليست بديلاً عن آلاف طلبات السحب (pull requests) التي يتعامل معها الفريق يومياً. لا يقول الاختبار شيئاً عن:
- التنوع في العالم الحقيقي – فهو يغطي لغات قليلة ونطاقاً محدوداً من فئات الأخطاء.
- الأداء – فهو لا يوفر أي قياسات للوقت أو تكلفة الحوسبة.
- الموثوقية عبر قواعد الكود المختلفة – فبدون اختبار على مستودعات حية، لا يمكننا معرفة ما إذا كانت الأداة ستغفل عن عيوب دقيقة أو ستنتج نتائج إيجابية خاطئة (false positives) في بيئة الإنتاج.
إن خلط النتائج المنشورة مع ملفات البنية التحتية والوعود بـ "بيانات واسعة وواقعية" في المستقبل يخلق رواية تسويقية مفادها أن الدرجة الواحدة تمثل قدرة جاهزة للإنتاج، وهو أمر لا تدعمه البيانات.
كيف يتناسب هذا الاختبار مع منظومة الاختبار الأوسع
ترسم الاختبارات القائمة على "التعرف" (Recognition-style)، مثل اختبار CodeVetter، مساحة السطح التي يمكن للأداة التعامل معها. وهي تكمل الاختبارات الوظيفية مثل SWE-bench، التي تتحقق مما إذا كان التصحيح (patch) الذي تم إنشاؤه بواسطة الذكاء الاصطناعي يحل بالفعل مشكلة حقيقية في قاعدة كود موجودة. معاً، يقدمان صورة أشمل: التغطية مقابل الفعالية.
يجب أن يكشف اختبار الوكيل (agent benchmark) الجيد عن كامل المكونات (full stack):
- مجموعة البيانات – المدخلات الخام والمخرجات المتوقعة.
- توثيق لكل حالة – صفحة لكل اختبار توضح الخطأ، والإصلاح الصحيح، واستجابة الأداة.
- مخرجات المراجع – التعليقات أو الاقتراحات الدقيقة التي أنتجها الذكاء الاصطناعي.
- منهجية التقييم – كيفية الحكم على المطابقات، بما في ذلك التسامح مع الدرجات الجزئية.
- تعليمات إعادة الإنتاج – تثبيت الإصدارات، وتفاصيل الأجهزة، والسكربتات لإعادة تشغيل الاختبار.
لا يمكننا الوثوق بدرجة إجمالية واحدة إلا عندما تكون كل هذه الأجزاء شفافة.
القيود التي يدرجها الاختبار نفسه
- حالات اصطناعية، لم تُسحب من مستودعات حية.
- اختيار ضيق للغات وأنواع الأخطاء.
- لا توجد بيانات عن الوقت أو التكلفة، لذا فإن الكفاءة غير معروفة.
- قيود الدقة التي قد تخفي حالات الفشل الحدية.
ما الذي يجب مراقبته لاحقاً
الخطوة التالية لـ CodeVetter — ولأي شخص يستخدم مراجعي الذكاء الاصطناعي — هي تقديم أدلة متكررة على مجموعات بيانات (corpora) أكبر وأكثر تنوعاً. وهذا يعني نشر النتائج على تدفقات طلبات السحب الحقيقية، والإبلاغ عن زمن الاستجابة واستهلاك الحوسبة، وتصنيف أنماط الفشل حسب الفئة. وإلى أن تظهر مثل هذه البيانات، تعامل مع نتيجة الـ 27 حالة كمؤشر أولي، وليس كضمان للجاهزية.
الخلاصة: إن الاختبار الذي يخبرك فقط ما إذا كانت الأداة قادرة على اكتشاف حفنة من الأخطاء المكتوبة مسبقاً مفيد للتحقق الأولي (sanity-checking)، لكنه لا يضمن صمود الأداة في واقع مراجعة الكود في بيئة الإنتاج الأكثر تعقيداً وحساسية للتكلفة.