كيفية مراجعة الكود المولّد بالذكاء الاصطناعي باستخدام أدلة على مستوى المهمة

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

مراجعة الكود المولّد بالذكاء الاصطناعي جيداً مهمة مختلفة عن مراجعة طلب سحب لزميل، لأن المؤلف لا يستطيع أن يجلس بجانبك ويشرح منطقه. الحل هو مراجعة الفرق مع أدلته: الهدف، والفحوصات التي جُريت، والحدود التي أشار إليها الوكيل مسبقاً. وهذا ما بُني عليه Sharkly. يقف Sharkly فوق وكلاء البرمجة لديك (Claude Code وCodex وGemini وغيرها) ويحفظ الهدف والتغيير ونتائج التحقق والمراجعة البشرية لكل تشغيل في مهمة واحدة بدلاً من تشتيتها بين الطرفيات ووصف طلبات السحب.

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

إجابة سريعة

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

لماذا تفشل مراجعة الفرق وحده

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

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

ما الذي تعنيه أدلة مستوى المهمة فعلاً

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

عملياً، تتكوّن حزمة الأدلة من أربعة عناصر:

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

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

نموذج التشغيل: من يوزّع، ومن ينفّذ، ومن يراجع، ومن يقبل

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

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

الحالات وبوابات المراجعة: الوكلاء ينقلون إلى "جاهز للمراجعة"، والبشر ينقلون إلى "منتهٍ"

بوابة المراجعة حدٌّ بين الحالات. في Sharkly، تنتمي كل حالة مهمة إلى فئة ثابتة تحمل معنى نظامياً: Backlog (مُعلّقة)، وUnstarted (جاهزة، لم تبدأ)، وStarted (قيد التنفيذ)، وCompleted (نهائية). ويمكن أن تتشارك عدة حالات ظاهرة الفئة نفسها، لذا يمكن لسير عمل نوع مهمة أن يُشغّل Development وReady for review كحالتين متميزتين ضمن Started قبل أن يصل أي شيء إلى Completed.

هذا البناء هو ما يجعل البوابة حقيقية. فيمكن للوكيل أن ينقل مهمة من Development إلى Ready for review، وأن يتركها في انتظار المراجعة البشرية. لكنه لا يستطيع أن ينقل المهمة بنفسه إلى حالة Completed. فالقبول انتقال بشري، بحكم التصميم.

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

مثال عملي: من التذكرة إلى دمج طلب السحب

خذ SH-312: "أضف تحديد معدّل إلى نقطة نهاية البحث العامة، 60 طلباً في الدقيقة لكل مفتاح API."

1. يفتح شخص SH-312 بهذا الهدف ومعياري قبول: الطلبات التي تتجاوز الحد تُرجع HTTP 429، والحد لكل مفتاح لا لكل IP. تبدأ المهمة في Todo.
2. يطالب بها وكيل، وينقلها إلى Development، ويعمل في شجرة عمل معزولة بحيث لا يتعارض تسجيل خروجه (checkout) أبداً مع وكلاء آخرين يعملون على المستودع نفسه. (أشجار العمل هي السبب في بقاء التشغيلات المتوازية نظيفة؛ راجع تسجيل خروج واحد لكل مهمة.)
3. ينفّذ الوكيل محدّداً بنمط دلو الرموز (token-bucket)، ويفتح طلب سحب، ويرفق أدلته بـ SH-312: ملخص تغيير، وفحص الأنواع واختبارات الوحدة الناجحة، ونتيجة البناء، وحداً معروفاً واحداً: "الدلو يعيش في ذاكرة العملية، لذا تُعاد ضبط الحدود عند النشر ولا تُشارَك بين النسخ."
4. ينقل الوكيل SH-312 إلى Ready for review. فتصل إلى قائمة إنسان مع الفرق والأدلة معاً.
5. يقرأ المراجع ملاحظة الحد المعروف أولاً، ويقرر أن الدلو الموجود في الذاكرة كافٍ في الوقت الحالي، ويطلب تغييراً واحداً: إرجاع ترويسة Retry-After مع استجابة 429. فيجري الوكيل التغيير ويعيد إرفاق مخرجات الاختبار المحدّثة.
6. يقبل المراجع، ويدمج طلب السحب، وينقل SH-312 إلى Done، مع ربط تذكرة متابعة لمحدّد مشترك مسبقاً.

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

كيف تراجع الأدلة بسرعة، ومتى تخفف المراجعة

لا يحتاج كل تغيير إلى المعالجة الكاملة. استخدم قاعدة قرار.

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

قائمة تحقق سريعة للمراجعة المكثفة:

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

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

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

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

هل يمكن لوكيل ذكاء اصطناعي أن يوافق على كوده بنفسه؟ لا، وهذا هو جوهر بوابة المراجعة. يمكن للوكيل أن ينقل مهمة إلى Ready for review، لكن الانتقال إلى حالة Completed قرار بشري. الوكلاء ينتجون ويتحققون؛ والبشر يقبلون.

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

هل ما زلت أستخدم طلبات السحب؟ نعم. يفتح الوكلاء طلبات سحب حقيقية على GitHub؛ وتضيف طبقة المهمة الأدلة والبوابة حولها بحيث لا يكون طلب السحب المكان الوحيد الذي يعيش فيه السياق.