ReviewBench من GitHub: حين يتصدّر Copilot اختباراً صمّمه بنفسه، كيف تقرأ أرقام مراجعة الكود؟

حين تعلن شركة أن منتجها جاء أولاً في اختبار أعدّته بنفسها، فالسؤال الصحيح ليس «هل هذا صحيح؟» بل «ماذا قاس الاختبار بالضبط، ومن شغّله، ومتى؟». هذا بالضبط ما يحدث هذا الأسبوع مع ReviewBench، المعيار المفتوح الذي كشفت عنه GitHub بالتعاون مع Microsoft لقياس قدرة وكلاء مراجعة الكود بالذكاء الاصطناعي على اكتشاف مشكلات مفيدة في طلبات الدمج (Pull Requests). وقد وضعت قائمته الأولى مراجعَ Copilot في الصدارة، بينما يعطي معيار مستقل ترتيباً مختلفاً. في هذا المقال نفكّك الأرقام ونعطيك طريقة عملية لتقرأ أي معيار مشابه.

ما هو ReviewBench وماذا يقيس؟

ReviewBench مجموعة اختبار عامة تضع عدة مراجعين آليين أمام التغييرات نفسها، ثم تقيس قدرة كل منهم على إيجاد مشكلات حقيقية ومفيدة، لا مجرد إنتاج تعليقات كثيرة. بحسب ما نُشر، تتكوّن المجموعة من:

• 219 طلب دمج عام.
• مأخوذة من 187 مستودعاً عاماً.
• بـ19 لغة برمجة مختلفة.
• اختيرت بعد تحليل 103.9 مليون طلب دمج، مع ترجيح متعمّد بعيداً عن التغييرات الصغيرة ذات الملف الواحد.

هذه الأخيرة نقطة قوة: كثير من الاختبارات القديمة تمتلئ بتعديلات تافهة تُسهّل على أي أداة أن تبدو بارعة. أما هنا فالتغييرات أكبر وأقرب إلى ما يراه الفريق فعلاً في العمل اليومي.

ماذا قالت النتائج؟

جاء Copilot code review بإعداد Balanced في المركز الأول بدرجة F1 «مؤسَّسة» (grounded) بلغت 40.1%. لكن الصورة تتغيّر حين ننظر إلى معيار مستقل آخر هو Code Review Bench من Martian:

المعيار	ترتيب Copilot	ما يتقدّم عليه
ReviewBench (من GitHub)	الأول، 40.1%	لا أحد في القائمة الأولى
Code Review Bench، الاختبار المباشر	الرابع، 60.9% F1	Cubic وGreptile وCodeRabbit
Code Review Bench، الاختبار غير المتصل	الخامس، 58% F2	Qodo Deep وCubic وAugment

لاحظ أن الأرقام المطلقة غير قابلة للمقارنة بين المعيارين، فكل معيار يعرّف «مشكلة مفيدة» بطريقته ويستخدم مقياساً مختلفاً. المقارنة المفيدة هي الترتيب لا النسبة، والترتيب يختلف فعلاً.

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

لماذا يجب أن تتوخى الحذر؟

ثمة ثلاثة تفاصيل في طريقة التشغيل تستحق التوقف عندها:

1. من شغّل الاختبار؟

فريق GitHub نفسه هو من أنتج مدخلات القائمة الأولى، فشغّل النسخ العامة المتاحة من المنتجات المنافسة دون مشاركة من الشركات المصنِّعة ودون أن تتحقق من النتائج. هذا لا يعني تلاعباً، لكنه يعني أن إعدادات المنافسين قد لا تكون الأمثل. وقد أشارت تغطية الموقع الألماني Heise إلى النقطة ذاتها: لم تُجرِ الشركات الأخرى هذه الاختبارات ولم تتحقق منها.

2. متى شُغّل الاختبار؟

اختُبر Copilot في الأول من أكتوبر، في حين اختُبر Cubic وGreptile في يونيو. في سوق تتغيّر فيه النماذج كل بضعة أسابيع، فرق أربعة أشهر كفيل بقلب الترتيب بالكامل، فقد تكون بعض نتائج المنافسين قديمة.

3. ماذا يعني «Balanced»؟

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

كيف تقيّم أداة مراجعة الكود لفريقك؟

بدلاً من الاعتماد على لوحة صدارة، جرّب هذه الخطوات البسيطة:

1. اختر من مستودعك 20 إلى 30 طلب دمج قديماً معروفة عيوبه، منها ما تسبّب في أعطال لاحقاً.
2. شغّل كل أداة مرشّحة على الطلبات نفسها بإعداداتها الافتراضية ثم بالإعداد الأكثر صرامة.
3. سجّل عدد المشكلات الحقيقية التي وجدتها، وعدد التعليقات الضجيجية التي أضاعت وقت المراجِع البشري.
4. قس الوقت الذي يحتاجه المطوّر لفرز التعليقات، فهذا هو الثمن الخفي.
5. أعد الاختبار كل ربع سنة، لأن النماذج تحت الأدوات تتغيّر.

قيمة هذا الاختبار المحلي أنه يقيس ما يهمّك: لغتك وبنية مشروعك وتقاليد فريقك، وهو ما لا يستطيع أي معيار عام أن يمثّله.

ما الذي يدلّ عليه هذا كله للسوق؟

ظهور معيار مفتوح خطوة إيجابية في ذاتها، لأن نشر المنهجية والبيانات يتيح للآخرين إعادة التشغيل والاعتراض. المطلوب الآن أن تشارك الشركات المنافِسة وجهات مستقلة في تحديث القائمة وتوثيق تواريخ التشغيل وإصدارات المنتجات. حتى ذلك الحين، تعامل مع ReviewBench كواحد من عدة مؤشرات، لا كحكم نهائي.

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

أخطاء شائعة عند الاعتماد على المعايير

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

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

أسئلة شائعة

هل يعني تصدّر Copilot أنه الأفضل لمشروعي؟

لا بالضرورة. التصدّر في معيار واحد صممته الجهة المصنِّعة لا يضمن التفوق على مستودعك ولغتك وأسلوب فريقك. الأفضل أن تجرّب بنفسك على طلبات دمج حقيقية.

ما الفرق بين F1 وF2 في هذه المعايير؟

كلاهما يجمع بين الدقة والاستدعاء. F1 يعطي الوزن نفسه للاثنين، بينما يعطي F2 وزناً أكبر للاستدعاء، أي لإيجاد أكبر عدد ممكن من المشكلات الحقيقية حتى لو ارتفع الضجيج قليلاً.

هل أثق بالمعايير المفتوحة أكثر من المغلقة؟

الانفتاح يزيد قابلية التحقق، لكنه لا يلغي الحاجة إلى معرفة من شغّل الاختبار وبأي إعدادات وفي أي تاريخ.

الخلاصة

أعطانا ReviewBench مادة مفيدة للنقاش، لكنه يذكّرنا بقاعدة قديمة: لا تقرأ لوحة الصدارة قبل أن تقرأ من أعدّها. ترتيب Copilot يتغيّر بين معيار وآخر، وتواريخ التشغيل مختلفة، والمنافسون لم يشاركوا في التحقق. اجعل قرارك مبنياً على تجربة قصيرة ومنضبطة على كودك أنت، وراجع النتيجة بانتظام.

المصادر: The New Stack، Heise