المراجعة البشرية هي عنق الزجاجة: تصميم المراجعة للوكلاء المتوازين

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

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

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

لماذا ينقل الوكلاء المتوازون عنق الزجاجة إلى المراجعة

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

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

نموذج التشغيل: من يُسنِد، ومن يُشغّل، ومن يراجع، ومن يقبل

قبل أن تمسّ الحالات، سمِّ المهام الأربع بأسمائها. فهي مهام مختلفة، والخلط بينها هو ما يجعل المراجعة تبدو فوضوية.

شخص ما يُسنِد العمل: يحوّل نيّة إلى مهمة محددة النطاق لها معايير قبول. وشيء ما يشغّله: وكيل (Agent) على حاسوب (Computer) ينفّذ داخل بيئة تشغيل (Runtime)، فيُنتج تغييرًا وسجلًا لما فعله. وشخص ما يراجع النتيجة: يقرأ الـ diff والأدلة، ويقرر ما إذا كانت تستوفي المعايير. وشخص ما يقبلها: يتخذ قرار الدمج والإصدار، وهو قرار مختلف عن «الشيفرة تبدو جيدة».

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

وثمة حد فاصل مفيد: طلب سحب مدموج ليس النتيجة المقبولة. فالدمج عملية في git، أما القبول فهو أن يقرر إنسان أن التغيير يفعل ما طلبته المهمة. وعندما ينطبق الاثنان في نقرة واحدة، تهبط جودة المراجعة إلى مستوى الطاقة التي كان يملكها المراجع في تلك اللحظة.

الأدوار والحالات وبوابات المراجعة

أعطِ الطابور شكلًا بمنح المهام مجموعة صغيرة من الحالات يتنقل بينها الوكلاء والبشر. المهمة (Task) هي وحدة العمل الأساسية: فهي تحمل الهدف والمحادثة والتشغيل. والفكرة من الحالات أن الوكلاء يستطيعون دفع المهمة حتى بوابة المراجعة، ولا يستطيع تجاوزها إلا إنسان.

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

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

صمّم المراجعة بحيث تتوسّع

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

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

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

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

مثال تطبيقي واحد، من التذكرة إلى طلب سحب مدموج

خُذ مهمة تبدو واقعية، SH-312: «حدّد معدل الطلبات على نقطة نهاية البحث العامة». يصوغها شخص في قائمة الانتظار مع معايير القبول (رمز 429 بعد N طلب في الدقيقة لكل مفتاح، وترويسة موثّقة، واختبار) ثم ينقلها إلى Ready.

ثلاثة وكلاء يعملون في المساحة (Space) على التوازي. يتولى أحدهم SH-312، ويستنسخ المستودع المُهيَّأ على حاسوب، ويعمل داخل worktree معزولة بحيث لا يتصادم فرعه مع التشغيلين الآخرين الجاريين. يكتب محدّد المعدل، ويضيف اختبارًا، ويشغّل فحص الأنواع ومجموعة الاختبارات، ويفتح طلب سحب يحمل عنوانه معرّف المهمة، وينقل SH-312 إلى Ready for review مرفقًا ملخص التغيير ومخرجات اختبارات ناجحة، مع الإشارة إلى حدّ معروف واحد: العدّاد داخل العملية، وغير مشترك بين النسخ.

تفتح أنت المهمة، لا خمسة عشر تبويبًا. الأدلة أمامك مباشرة، وملاحظة الحد المعروف هي الجزء المفيد: الاختبارات تنجح، لكن الحالة المشتركة بين النسخ قرار تصميمي عليك أن تتخذه. تترك تعليقًا وتنقلها إلى Changes requested. ويبدأ ذلك التعليق تشغيلًا لاحقًا على المهمة نفسها؛ فينقل الوكيل العدّاد إلى مخزن مشترك ويعيد أدلة محدَّثة. هذه المرة تقبل. ونقل SH-312 إلى Done قرارك أنت، مسجّل كتغيير حالة يحمل اسمك، لا كأثر جانبي صامت لعملية دمج في git.

وفي الأثناء، ينتظر الوكيلان الآخران في Ready for review. ولأن الطابور عمود وليس صندوق واردك، تفرّغهما بعد ذلك بالترتيب، دون أن تفقد الخيط.

الخط الفاصل الذي تحتفظ به للبشر

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

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

الأسئلة الشائعة

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

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

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