كيف يُجري فريق Claude Code مراجعة الأكواد

لقد قلنا سابقًا إن كلود يكتب حوالي 90 بالمئة من كود Claude Code نفسه. إذن كيف نراجع الأكواد بالحجم الذي ننتجها؟ هل يقرأ أحد الأكواد بعد الآن؟ وإذا تعطل شيء ما، فمن يكتشفه؟

تتناول هذه المقالة مسار مراجعة الأكواد في فريق Claude Code وكيف تطوّر. من يونيو إلى سبتمبر، تضاعفت طلبات الدمج (pull requests) المدمجة في قاعدة كود Claude Code بأكثر من الضعف، بينما انخفضت نسبة ما كان يجب التراجع عنه بأكثر من 40 بالمئة.

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

إعادة التفكير في الغرض من مراجعة الأكواد

عندما تكتب الوكلاء الأكواد، يرتفع عدد التغييرات بسرعة. في المستودع الأحادي (monorepo) الخاص بـ Anthropic، ارتفعت التغييرات الواردة يوميًا من نحو 2,500 في مايو إلى أكثر من 30,000 في سبتمبر من هذا العام.

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

تؤدي مراجعة الأكواد وظيفتين:

1. العثور على المشكلات وإصلاحها قبل إطلاقها
2. بناء سياق مشترك وفهم لقاعدة الكود عبر الفريق

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

نعتقد أن سؤال "هل قرأ إنسان الكود؟" هو مؤشر غير دقيق للسؤال "ما الذي قد يحدث خطأً مع هذا التغيير، وأي فحص—آلي أو بشري—هو الأنسب لاكتشافه؟"

طرح هذا السؤال غيّر أيضًا وقت حدوث المراجعة. سابقًا، كانت المراجعة بوابة في نهاية الطريق: اكتب الكود، افتح طلب دمج (PR)، وانتظر زميلك.

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

المورد النادر: الوقت والانتباه البشريان

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

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

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

حياة التغيير

يمر التغيير النموذجي، من حاسوب المهندس المحمول (أو من جلسة كلود في Slack)، عبر طبقات متعددة من مراجعة الأكواد.

طبقة بطبقة

1. يُتحقق من العمل قبل أن يطّلع عليه أي شخص آخر

معظم المراجعة يحدث الآن قبل وجود طلب سحب (PR) أصلًا. نمنح كلود (Claude) شيئًا يمكنه تشغيله—مثل الاختبارات أو عملية بناء أو لقطة شاشة للمقارنة مع التصميم—ونطلب منه عرض المخرجات بدلًا من الإفادة بأنه انتهى. ثم يراجع وكيل فرعي (subagent) الفرق (diff) بسياق جديد. كلا العادتين مستمدتان من دليل أفضل الممارسات لدينا.

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

بوريس تشيرني (Boris Cherny)، مبتكر Claude Code، وصف منح كلود وسيلة للتحقق من عمله بأنها على الأرجح أهم شيء للحصول على نتائج جيدة. ويقدّر أن ذلك يحسّن النتيجة النهائية بنحو ضعفين إلى ثلاثة أضعاف، ويكتب: "يبدو التحقق بشكل مختلف في كل مجال. قد يكون ببساطة تشغيل أمر bash، أو تشغيل مجموعة اختبارات، أو تجربة التطبيق في متصفح أو محاكي هاتف."

عندما يستمر المراجع الآلي في الإشارة إلى الأمر نفسه، نعالج المشكلة عند المصدر: في المهارة نفسها، أو عبر قاعدة lint، أو بتحديثات للملفات الإرشادية مثل:

• CLAUDE.md يُخبر Claude بماهية المشروع: حزمة التقنيات، الاتفاقيات، الأهداف وغير الأهداف. كل مراجعة تحمّله، لذا في قاعدة برمجية كبيرة نُبقيه قصيرًا ونحيل منه إلى مستندات أخرى. كما يُشير المراجع أيضًا إلى الكود الذي يخرق اتفاقية فيه، وإلى التغييرات التي تجعل سطرًا فيه متقادمًا.
• REVIEW.mdالذي يكتبه مالكو الكود، يُخبر المراجع بما يهم في جزئه من الكود. نتحقق على حدة مما إذا كان المراجع يتبعه فعلًا. الجيد منها قصير. يقول كيف يبدو الفشل في ذلك المستودع (للمستندات هو "يقع في الكذب"، وللإعدادات هو "يوجّه خطأً")، ويحدّ سقف الملاحظات الصغيرة، ويسرد المسارات التي يجب تخطّيها، ويطلب ملفًا وسطرًا كدليل بدلًا من تخمين مبني على اسم. كما يطلب ملخصًا يبدأ بعدد ويصرّح بوضوح عندما لا يوجد ما يُصلَح.

2. مراجعة بالذكاء الاصطناعي على كل طلب دمج

كل طلب دمج يحصل على مراجعة من Claude قبل أن ينظر إليه إنسان. يقرأ الفرق (diff) مقارنة بالمستودع كاملًا وبالغرض المعلن لطلب الدمج، ويسأل: هل يحل التغيير مشكلته، ويتوافق مع النظام، أم يكسر شيئًا آخر؟

في إصلاح خلل، يبحث عن السبب الجذري. النسخة العامة، Code Review for Claude Codeمتاحة الآن عمومًا على خطتي Team وEnterprise، بينما /code-review يشغّل نسخة أخف محليًا.

عندما أطلقنا المعاينة البحثية، ارتفعت نسبة طلبات الدمج الداخلية التي تحصل على تعليقات مراجعة جوهرية من 16% إلى 54%. معظم طلبات الدمج التي تتجاوز 1,000 سطر تحصل على نتائج، ومعظم الطلبات الصغيرة تعود نظيفة. يضبط المسؤولون كل مستودع على Quick أو Standard أو Deep. تستحق Deep العناء حيث تكون تكلفة خلل واحد فائت أكبر من وقت المراجعة الإضافي.

يتم التحقق من النتائج بواسطة وكلاء آخرين قبل أن يراجعها البشر. عدة وكلاء يبحثون عن الأخطاء في الوقت نفسه. ثم تصوّت مجموعة منفصلة على كل نتيجة، ولا تُنشر إلا إذا اتُّفق بين عدد كافٍ منها على أنها حقيقية. النتائج المتعلقة بالأسلوب أو التشخيصات أو التنظيف فقط تُستبعد. اختبرنا هذه المرشحات بطريقة A/B على طلبات الدمج الخاصة بنا قبل الإبقاء عليها. ما تبقى يظهر كتعليقات داخلية مرتبة حسب الخطورة. كل واحدة مُوسومة بـ Important أو Nit أو Pre-existing، حتى لا يبدو خطأ لم يُدخله طلب الدمج وكأنه ذنب المؤلف.

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

3. مراجعة أمنية قادرة على الإيقاف

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

إذا أصلح التزام لاحق المشكلة، تُزال النتيجة تلقائيًا. يمكنك إعداد الشيء نفسه باستخدام GitHub Action مفتوحة المصدر للمراجعة الأمنية أو /security-review الأمر. الإعداد مشروح في المراجعات الأمنية الآلية في Claude Code.

4. فحوصات آلية تمنع الدمج

المعتادة: lint، وفحوصات الأنواع، والاختبارات على كل منصة، وبناء. (كتبنا عن توسيع نطاق CI لهذا الحجم هنا.) قد يُشغّل طلب دمج نموذجي لواجهة سطر الأوامر عشرات الفحوصات قبل أن ينظر إليه أحد. يطلب قالب طلب الدمج بيان كيفية اختبار التغيير وكيفية التراجع عنه. يمكن لـ Claude تعبئة ذلك، لكن الشخص الذي طلب التغيير هو من يصادق عليه.

5. موافقة بشرية بحسب المخاطر

إصلاح مستندات وتغيير في مُحدِّث تلقائي يحملان مخاطر مختلفة، فيحصلان على مراجعة مختلفة.

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

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

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

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

6. قائمة انتظار الدمج والعلامات والإطلاق التدريجي

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

7. كشف سريع، وتراجع سريع

ستتسرب بعض الأخطاء رغم ذلك، لذا تتمثل الطبقة الأخيرة في اكتشافها بسرعة. يمكن إيقاف الـ flags دون نشر deploy. لدى Claude Code دورية تمساناح أسبوعية، وتسأل مراجعات الحوادث أي طبقة كان ينبغي لها اكتشاف المشكلة.

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

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

كيف نجعل المراجع أفضل

عملية مراجعة الكود لدينا تتحسن باستمرار في حلقة متواصلة.

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

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

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

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

عندما شغّلنا git blame على ما ظل المراجع يبلّغ عنه، كان نحو 59% منه كوداً كان موجوداً منذ المرور الأول للمراجع. نادراً ما كان المراجع يجد أخطاء جديدة؛ كان يجد في كل جولة أخطاءً قديمة إضافية قليلة.

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

• حد أقصى للجولات. بعد ثلاث جولات، يطلب المراجع من المؤلف أن يتراجع خطوة ويعيد النظر في النهج المتبع.
• إعادة مراجعة الفروق فقط (diff-only) بعد المرور الأولى القليلة.
• الإبلاغ عن فئة الخطأ، حيث يصلح المؤلف كل الحالات، لا سطراً واحداً.
• لا تكرار للنتائج المنشورة سابقاً.

كما تعمل وكلاء المراجعة ليلاً على الكود الموجود، مما يساعدنا على اكتشاف الأخطاء القديمة قبل ظهورها في مكان آخر.

حيث يبقى البشر في حلقة القرار

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

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

مشاركة السياق عبر الفريق

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

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

ويتقدم بعضنا خطوة أبعد بجعل Claude يبني أثرًا صغيرًا (artifact) يصوّر ذلك الجزء من الشيفرة ويعلّمه بالطريقة التي يفضل ذلك الشخص في التعلم بها.

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

"من يُنزلها يملكها"

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

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

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

عندما نغيّر الاتجاه

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

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

كيف يمكنك تبنّي هذه العملية

معظم القطع اللازمة للقيام بذلك مع فريقك موجودة اليوم.

قبل طلب السحب

• امنح وكيلك فحوصًا يمكنه تشغيلها، مدرجة في CLAUDE.mdقصير، إضافة إلى hooks تشغّل أدوات التنسيق وأدوات الفحص (linters).
• شغّل /code-review و /security-review محليًا، أو مراجعة بواسطة وكيل فرعي بسياق جديد.
• أضف REVIEW.md، وانقل تعليقات المراجعة المتكررة إليه.

على كل طلب دمج

• اطلب التكامل المستمر (CI)، وأضف "الاختبار" و"المخاطر" و"كيفية التراجع" إلى قالب طلب الدمج الخاص بك.
• أضف مراجعًا ذكيًا يعمل بالذكاء الاصطناعي (Code Review for Claude Code، أو Claude Code GitHub Action) على مستودع واحد، واضبط REVIEW.md لأسابيع قليلة، ثم وسّع النطاق.
• أضف مراجعة أمنية مؤتمتة، واطلب حل كل سلسلة مراجعة قبل الدمج.
• طابق جهد المراجعة مع المخاطر: مراجعة سريعة للتغييرات الروتينية، ومراجعة عميقة حيث يكون تفويت خطأ مكلفًا (Quick أو Standard أو Deep في Code Review).
• ضع حدًا أقصى لجولات المراجعة؛ بعد الجولات القليلة الأولى، أعد مراجعة الفرق الجديد فقط.

الموافقة

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

الدمج وما بعده

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

إلى أين يتجه الأمر

مراجعة الكود الخاصة بـ إعلان قال إن الموافقة على طلب سحب (pull request) ما تزال قرارًا بشريًا؛ فالمنتج ينشر النتائج، لا الموافقات. أما مستودعاتنا فتتقدم خطوة أبعد، إذ تتيح لأصحابها تحديد التغييرات منخفضة المخاطر التي تُدمج بناءً على الفحوصات الآلية وحدها، وهذا الحد يستمر في التغير.

عندما يغفل تحدٍث شيء ما، نسأل عما لم يكن أمام النموذج ونضع الإصلاح في CLAUDE.mdأو مهارة أو فحصًا جديدًا. لم يتغير الهدف: وقت بشري أقل لكل تغيير، ولا تراجعات أكثر مما كان من قبل.

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

مع الشكر لإيما ويب ومايكل سيغنر وإيمي روثرام على مراجعاتهما.