لقد ذكرنا من قبل أن Claude يكتب نحو 90 في المئة من الشيفرة البرمجية الخاصة بـ Claude Code نفسه. فكيف نراجع الشيفرة بالحجم الذي ننتجه به؟ هل ما زال أحد يقرأ الشيفرة؟ وإذا تعطّل شيء، فمن يكتشفه؟ يتناول هذا المنشور سير عملية مراجعة الشيفرة في فريق Claude Code وكيف تطوّر. من يونيو إلى سبتمبر، تضاعفت طلبات السحب المدمجة في قاعدة شيفرة Claude Code أكثر من مرة، بينما انخفضت نسبة الطلبات التي احتاجت إلى التراجع عنها بأكثر من 40 في المئة. لم نلغِ المراجعة، لكننا نقلنا معظم القراءة إلى الآلات، مع تحسينها لتوفير وقت الإنسان وانتباهه، واستثمرنا بكثافة في جعل التراجع عن الأخطاء سريعاً وسهلاً.
عندما تكتب الوكلاء الشيفرة، يرتفع عدد التغييرات بسرعة. ففي المستودع الأحادي الخاص بـ Anthropic، ارتفع عدد التغييرات المدمجة يومياً من نحو 2,500 تغيير في مايو إلى أكثر من 30,000 تغيير في سبتمبر من هذا العام. يعيش Claude Code في مستودع مستقل عن المستودع الأحادي، لكنه يشهد ضغطاً كبيراً أيضاً. وعندما تشحن بهذه السرعة، تصبح المراجعة اليدوية سطراً بسطر صعبة للغاية إن لم تكن مستحيلة. وللمراجعة مهمتان: إيجاد المشكلات وإصلاحها قبل النشر، وبناء سياق مشترك وفهم لقاعدة الشيفرة عبر الفريق. يركز هذا المقال أساساً على إيجاد المشكلات وإصلاحها، وسنعود إلى المهمة الثانية في الختام.
نرى أن سؤال "هل قرأ إنسان الشيفرة؟" مقياس غير دقيق للسؤال الأهم: "ما الذي قد يسوء في هذا التغيير، وأي فحص، آلي أم بشري، هو المناسب لاكتشافه؟" وقد غيّر طرح هذا السؤال أيضاً توقيت المراجعة. فقديماً كانت المراجعة بوابة في نهاية الطريق: تكتب الشيفرة، وتفتح طلب سحب، وتنتظر زميلك. أما الآن فتعمل المراجعة باستمرار، أشبه بالتدقيق الإملائي أثناء الكتابة. تكون معظم التغييرات قد راجعها Claude وأصلحها مرة واحدة على الأقل قبل أن يُطلب من إنسان النظر فيها. وهذا يلتقط معظم الأخطاء الروتينية، ويوفر انتباه الفريق للأسئلة الأعلى مستوى والتدقيق المعمّق.
المورد النادر هو الوقت والانتباه البشري. نريد الحفاظ على وقت الإنسان وانتباهه للمشكلات التي لا يحلّها إلا الإنسان، والتأكد من أن الفحوص الآلية تلتقط ما تبقى. وبمعدل التغيير الحالي، ما زال أمام البشر قدر هائل من العمل، ويواجه فريقنا تحديات جديدة وغير مسبوقة تقريباً كل يوم. ويشمل الوقت البشري جانبي تكلفة المراجعة: الوقت الذي يقضيه الناس في المراجعة، والوقت الذي يقضونه في إصلاح ما يكسره الكود الرديء. ولا يفيد تقليص الأول إذا ظهر الوقت نفسه في الثاني. لذلك فالهدف أن تُدمج معظم طلبات السحب في مستودعات Claude Code (واجهة سطر الأوامر وتطبيقات سطح المكتب والويب والتطبيقات المحمولة) مع إنسان واحد على الأكثر في الحلقة، وقد يكون المؤلف نفسه، دون زيادة في حالات التراجع أو الحوادث. ولقياس الوقت البشري نتتبع عدد الموافقات البشرية لكل طلب سحب (الوسيط والمئين 95)، والتعليقات البشرية، ومدة انتظار الطلب لشخص ما. ومعدلات التراجع والحوادث هي الضمانة: فإن ارتفعت، فلم نوفّر وقت الإنسان، بل نقلناه فحسب.
حياة التغيير. يمر التغيير النموذجي، من حاسوب المهندس المحمول (أو جلسة Claude في Slack)، بعدة طبقات من مراجعة الشيفرة. وأغلب المسار آلي؛ فينصبّ انتباه الإنسان حيث توجد المخاطر. طبقات لا بوابة واحدة: ست طبقات من الفحوص، مع التراجع أسفلها. تلتقط كل طبقة بعض المشكلات وتفوتها أخرى، ويمر القليل منها عبر الطبقات كلها، ويتولى التراجع معالجة الباقي.
1. يُتحقق من العمل قبل أن ينظر فيه أحد. يجري معظم التدقيق الآن قبل وجود طلب السحب. نزوّد Claude بشيء يمكنه تشغيله، كالاختبارات أو البناء أو لقطة شاشة للمقارنة مع التصميم، ونطلب منه إظهار المخرجات بدلاً من القول إنه انتهى. ثم يراجع وكيل فرعي الفرق بسياق جديد. وكلتا العادتين مستمدة من دليل أفضل الممارسات لدينا. وقبل فتح طلب السحب، يشغّل كثير منا بعض المهارات الداخلية: واحدة تبحث عن الأخطاء، وأخرى تبسّط الفرق، وثالثة تتحقق من السلوك من البداية إلى النهاية. كما تُفحص تغييرات واجهة المستخدم وفق إرشادات التصميم لدينا.
المصدر: Hacker News · لخّصه HeadlinesBriefing