Anthropic تكشف كيف تراجع الكود الذي يكتب Claude 90% منه

عرضت Anthropic كيف تبدو مراجعة الكود (code review) حين يكتب النموذج الكود بالكامل تقريبًا. يكتب Claude نفسه نحو 90% من الكود في Claude Code، وأصبح الانتباه البشري المورد الأندر. وصاغ الفريق هدفه على النحو التالي: أقل وقت بشري ممكن في المراجعة مع بقاء مستوى التراجعات والحوادث كما هو. من يونيو إلى سبتمبر زاد عدد عمليات الدمج بأكثر من الضعف، وانخفضت نسبة التراجعات بأكثر من 40%.

اختيرت المقاييس بذكاء هندسي. يعمل الفريق على تحسين عدد الموافقات لكل PR، وعدد التعليقات، ووقت انتظار الإنسان. أما التراجعات والحوادث فتعمل كقيد: إذا ارتفعت، لا يُحتسب المكسب في السرعة.

خط من سبع طبقات لا يتدخل فيه الإنسان إلا متأخرًا

يتألف النظام من مرشِّحات متتابعة. يخفف كل منها جزءًا من العبء عن المراجع البشري:

• قبل PR. يشغّل Claude بنفسه الاختبارات والبناء (build) وأداة الـ linter. ثم يفحص وكيل فرعي (subagent) بسياق جديد الفرق (diff). وتتوفر مهارات (skills) داخلية: البحث عن الأخطاء، وتبسيط الـ diff، والتحقق الشامل e2e.
• مراجعة AI لكل PR. يبحث عدة وكلاء عن الأخطاء بالتوازي، وتصوّت مجموعة منفصلة على كل ملاحظة، وتُستبعد الملاحظات الأسلوبية البحتة. تُصنَّف الملاحظات إلى Important وNit وPre-existing حتى لا يُحمَّل المؤلف وزر خطأ قديم. ويجب الرد على كل ملاحظة. بعد إطلاق النسخة التجريبية ارتفعت نسبة الـ PR التي تتضمن تعليقات جوهرية من 16% إلى 54%.
• مراجعة الأمان (Security). تمنع هذه المراجعة الدمج.
• CI المعتاد. فحص الـ lint والأنواع والاختبارات على جميع المنصات.
• الموافقة حسب المخاطر. يحدد المصنِّف عدد الأشخاص المطلوبين. لا تتطلب الوثائق والنصوص والميزات الموضوعة خلف علم تفعيل (flag) أي مراجع بشري، وتتطلب التغييرات العادية مراجعًا واحدًا، وأكثرها حساسية اثنين. أما الفوترة (billing) والمحدِّث التلقائي (autoupdater) وسير عمل CI فتتطلب دائمًا مراجعًا بشريًا.
• الإطلاق. طابور الدمج (merge queue) والأعلام (flags). يرى التغيير أولًا المستخدمون الداخليون، ثم قناة latest، ثم stable.
• التراجع السريع.

المنطق هنا أن الفحوص الآلية الرخيصة تستبعد الأخطاء الواضحة، فيُنفق الوقت البشري المكلف حيث يكون ثمن الخطأ مرتفعًا.

حين يتجادل وكيل المؤلف ووكيل المراجع طوال الليل

أبرز ما في التحليل قصة الحلقات اللانهائية. يمكن لوكيل المؤلف ووكيل المراجع أن يتبادلا التعديلات بلا نهاية. اجتاز أحد الـ PR خلال ليلة واحدة أكثر من 50 جولة، إلى أن أوقف المؤلف العملية. وأظهر التحليل أن نحو 59% من الملاحظات تتعلق بكود قديم. فقد كان المراجع يجد في كل جولة بضعة أخطاء موروثة أخرى، لا أخطاء جديدة في التغيير نفسه.

من زاوية الـ tokens، هذه خسارة صافية: تُدفع تكلفة كل جولة مقابل سياق الـ diff، وتشغيل عدة وكلاء، والتصويت. فرض الفريق حدًّا أقصى قدره ثلاث جولات، وصارت المراجعة المتكررة تفحص الـ diff الجديد فقط. ويعالج التصنيف Pre-existing النصف الثاني من المشكلة: الدين القديم ظاهر، لكنه لا يعرقل PR غيره.

وهناك آلية مستقلة لضبط جودة المراجع نفسه. يُحوَّل كل حادث سابق إلى eval، ويُشغَّل المراجع على هذه الحالات يوميًا. وأي تغيير في الـ prompt أو النموذج يخفض النتيجة يُتراجع عنه. أي أن وكيل المراجعة يُختبر مثل أي مكوّن إنتاجي (production) عادي.

أربع قواعد تصلح لأي فريق

يتضمن التحليل مجموعة مبادئ غير مرتبطة ببنية Anthropic التحتية:

• مستوى المخاطر يحدده التغيير، لا المؤلف.
• المسار المخفف متاح للمؤلفين الموثوقين فقط.
• لا تُحتسب موافقة الوكيل أبدًا بديلًا عن موافقة بشرية.
• من كلّف الوكيل بالمهمة يتحمل مسؤولية الكود كأنه كتبه بنفسه.

وبالنسبة إلى الفرق التي يكتب فيها الوكلاء حصة ملحوظة من الكود، يترتب على ذلك خطة عملية. يُستحسن أن تبدأ بتصنيف مسارات المستودع حسب المخاطر: ما يمكن دمجه دون تدخل بشري، وما يتطلب دائمًا مراجعة، مثل الفوترة وCI لدى Anthropic. بعد ذلك ينبغي إعداد مراجعة متعددة الوكلاء مع تصويت وتصنيف للملاحظات، وتحديد عدد الجولات، وبناء eval خاصة بالفريق من حوادث حقيقية. أما من لا يريد بناء كل شيء بنفسه، فقد أصبحت خدمة Code Review لـ Claude Code متاحة عمومًا (GA) على خطتي Team وEnterprise. نُشر المقال الأصلي على claude.dev.