كيف يُجري فريق Claude Code مراجعة الشيفرة: سبع خطوات ودون قواطع دوائر

في 15 أكتوبر 2026، نشر فريق Claude Code روايته الخاصة عن كيفية مراجعته للشيفرة، وهي مقالة هندسية مدتها أربع عشرة دقيقة منسوبة إلى Addy Osmani وMorgan Westlee Lunt وQing Wang. والجملة التي تفسّر سبب بحث أي أحد عن هذا تأتي مبكرًا: يكتب Claude نحو 90 في المئة من شيفرة Claude Code نفسه. والمقالة ليست دفاعًا عن ذلك الرقم، بل وصفٌ للآلية التي كان لا بد أن توجد تحته قبل أن يصبح أمرًا ممكنًا، والجزء الذي يستحق القراءة المتأنية هو ما لا يزال ناقصًا.

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

لماذا أصبحت المراجعة عنق الزجاجة في المقام الأول

لم يأتِ الضغط من قرار سياسي. بل جاء من الحجم. ففي المستودع الأحادي (monorepo) الخاص بـ Anthropic، وفقًا لما يذكره المنشور، ارتفع عدد التغييرات التي تصل يوميًا من نحو 2,500 في مايو إلى أكثر من 30,000 في سبتمبر 2026. ويوجد Claude Code في مستودعه الخاص، منفصلًا عن ذلك المستودع الأحادي، لكنه يخضع للضغط نفسه على نطاق أصغر.

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

بمجرد صياغة الأمر بهذه الطريقة، تتحرك البوابة. لم تعد المراجعة بابًا عند نهاية الطريق، بل أصبحت مستمرة، أقرب إلى التدقيق الإملائي أثناء الكتابة. معظم التغييرات قرأها {{1}}Claude{{/1}} وأصلحها قبل أن ينظر إليها أحد.

ما الذي حسَّنوا من أجله، وما يُعدّ فشلًا

الهدف المعلن هو أن معظم طلبات السحب في مستودعات Claude Code، التي يصفها المنشور بأنها واجهة سطر الأوامر، وتطبيقات سطح المكتب والويب، وتطبيقات الجوال، تُدمج بمشاركة إنسان واحد على الأكثر في العملية، وقد يكون هو المؤلف، دون أي زيادة في عمليات التراجع أو الحوادث. والبند الثالث هو ما يجعله هدفًا حقيقيًا لا مجرد تمرين لخفض التكاليف.

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

من السهل التلاعب بمقاييس تكلفة المراجعة عند النظر إليها بمعزل عن غيرها؛ فالمراجع الذي يوافق على كل شيء ينتج مخططات جميلة لأوقات الموافقة. أما الضابط الوقائي فهو ما يمنع المخطط من الكذب.

سبع خطوات، لا بوابة واحدة

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

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

• مراجعة بالذكاء الاصطناعي على كل طلب سحب. تقرأ مراجعة Claude الفروقات مقابل المستودع بأكمله والنية المُعلنة لطلب السحب. تبحث عدة وكلاء عن الأخطاء على التوازي، ثم تصوّت مجموعة منفصلة على كل نتيجة، ولا تُنشر النتيجة إلا إذا اتفق عدد كافٍ على أنها حقيقية. تُستبعد النتائج المتعلقة بالأسلوب أو التشخيصات أو التنظيف. وما يبقى يظهر كتعليقات مضمنة موسومة بـ Important أو Nit أو Pre-existing. عند إطلاق المعاينة البحثية، ارتفعت نسبة طلبات السحب الداخلية التي تتلقى تعليقات مراجعة جوهرية من 16 بالمئة إلى 54 بالمئة. ويضبط المسؤولون كل مستودع على Quick أو Standard أو Deep.

• مراجعة الأمان. تمريرة آلية منفصلة. لا يمكن دمج طلب سحب ما دامت هناك ملاحظة مفتوحة من أي من المراجعتين؛ فعليك إصلاحها أو إغلاق سلسلة النقاش مع ذكر سبب موجز. الفحص نفسه متاح للعموم بصيغة إجراء GitHub لمراجعة الأمان مفتوح المصدر أو أمر /security-review.

• فحوصات آلية حاجزة. Lint، وفحوصات الأنواع، واختبارات على كل منصة، وعملية بناء.

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

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

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

التغيير يحدد المستوى، وليس المؤلف

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

منخفض يغطي التوثيق والنصوص التحريرية والميزات الداخلية فقط والتغييرات الإضافية خلف علم ميزة؛ وبمجرد أن تصبح المراجعة الآلية والفحوص الأمنية ناجحة، لا يُشترط وجود أي شخص. متوسط يغطي تغييرات المنتج العادية بالإضافة إلى المجالات الحساسة مثل التخزين المؤقت والمحدّث التلقائي ومطالبات النظام، ويتطلب شخصًا واحدًا. مرتفع يغطي الشيفرة الأعلى خطورة ومجموعة صغيرة من المسارات التي تتطلب دائمًا شخصين.

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

ثمة تفصيلان يستحقّان أن تُسرقهما حتى لو لم تبنِ مصنِّفًا قط. فالطبقة تأتي من التغيير لا من المؤلف، والثقة بوابة منفصلة وأضيق تُضاف فوقها. والموافقة تُربَط بإيداعٍ (commit) لا بطلب سحب (pull request)، وهو ما يسدّ الثغرة الأكثر شيوعًا في أنظمة المراجعة: علامة صحٍّ خضراء تُكتسب في وقتٍ مبكر من الفرع، ثم تُصرَف على شيفرة لم ينظر إليها أحد.

يُدرَّب المراجع على مواجهة حوادثه الخاصة.

هذا هو الجزء الذي تتخطّاه معظم الكتابات، وهو يفسّر لماذا يستمرّ هذا الترتيب في العمل بدلًا من أن ينحرف.

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

هذا توجه مختلف عن ضبط أداة تدقيق تُقيَّم وفق مجموعة قواعد ثابتة. يُقيَّم هذا المراجع وفق الطرق المحددة التي سبق أن تعطَّلت بها قاعدة الشيفرة هذه، لذا يتسع التقييم في كل مرة يحدث فيها خطأ. لا تظهر له أي درجة في أي شيء نشرته Anthropic مما قرأناه، ولا يزعم المنشور أن المراجع قد اكتمل.

الطبقة التي لم تُبنَ بعد

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

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

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

الوظيفة الثانية للمراجعة، التي يتجاهلها المنشور في الغالب

يوضح المنشور صراحةً أن مراجعة الشيفرة تؤدي وظيفتين: اكتشاف المشكلات وإصلاحها قبل إطلاقها، وبناء سياق مشترك عبر الفريق. وهو يركز على الأولى، ثم يعود إلى الثانية بإجابة صادقة على نحو غير معتاد: لا توجد عملية رسمية لذلك، ولا يحتفظ أحد بنموذج ذهني كامل لـ Claude Code في رأسه، ولا يعتقدون أن أحدًا يحتاج إلى ذلك. هل تريد فهم جزء من قاعدة الشيفرة؟ اطلب من Claude شرحًا لتلك الشريحة بالتحديد.

يحمل ملفّا تعليمات السياقَ الذي كان يقيم سابقًا في أذهان المراجعين. يخبر {{CLAUDE.md}} كلود بما هو المشروع، وحزمة التقنيات، والأعراف، والأهداف وغير الأهداف، ويُبقى قصيرًا عن قصد. يكتب {{REVIEW.md}} مالكو الشيفرة، ويوضح كيف يبدو الفشل في جزءهم من الشيفرة، وأي المسارات يجب تخطيها، ويطلب اسم ملف ورقم سطر بدلًا من التخمين.

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

أين يتناسب جهاز التوجيه، وأين لا يتناسب

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

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

الحدود مهمة. نحن نستضيف النماذج. لا نستضيف Claude Code، ولا نشغّل Code Review الخاص بـ Claude Code، وليس لدينا وصول إلى خط المعالجة الذي تتناوله هذه المقالة. Code Review الخاص بـ Claude Code هو منتج من Anthropic، متاح عمومًا في خططي Team وEnterprise، مع نسخة أخف متاحة محليًا باسم /code-review. إذا كان ما تريده هو خط المعالجة ذلك، فهو موجود هناك؛ وفي النسخة الخاصة بفريقك منه، فإن الراوتر قرارٌ يتعلق بالبنية التحتية وليس قرارًا خاصًا بالمراجعة.

ما يمكن لفريق أصغر أن ينسخه فعليًا

دوّن قواعد المراجعة حيث يستطيع المراجع قراءتها: ملف CLAUDE.md قصير للمشروع، وملف REVIEW.md لكل مجال يسمّي كيف يبدو الفشل ويطالب بملف ورقم سطر بدلًا من التخمين. ضع طبقات المخاطر كتابةً، واجعلها خاصيةً بالتغيير لا بالكاتب، وابدأ صارمًا ولا ترخِ إلا بدليل. حدّد سقفًا لما يمكن للمراجعة الآلية اعتماده، ولا تدع اعتماد وكيل يُحتسب اعتماد شخص. اربط الاعتمادات بالـ commits. شغّل طابور الدمج. حوّل الحوادث والتراجعات إلى حالات اختبار، وأعد تقييم المراجع كلما غيّرته، لأن المراجع غير المقاس هو مدقّق ساكن بتسويق أفضل.

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