الوكيل يكتب الكود أسرع مما تستطيعون قراءته، فتصبح المراجعة هي عنق الزجاجة. في هذا الفيديو، سنعطي وكيلًا مهمة مراجعة منفصلة، ونجمع الملاحظات من مراجعات بسياق جديد، ونقرّر أي الملاحظات تستحق الإصلاح.
في فيديو سابق، جعلنا نجاح فحوصات الـ CI شرطًا للدمج. الاختبارات وفحص الأنواع والـ lint هي أدوات صورية، وهي تتحقق من شروط كتبناها بشكل صريح.
ومراجعة الوكيل تضيف أداة ضبابية إلى جانب الـ CI. يبحث المراجِع عن مشكلات لا تغطيها فحوصاتنا، مثل كود يختلف عن المواصفات، أو مسار خطأ مفقود، أو اسم مضلِّل.
من يكتب الكود لا يُحسن مراجعة عمله، وهذا يشمل جلسة الوكيل التي كتبت الكود. فسياقها يحتوي أصلًا على الأسباب التي جعلت الكود يبدو صحيحًا، لذا تميل إلى الموافقة على اختياراتها.
ابدؤوا جلسة جديدة أو وكيلًا فرعيًا لا يرى إلا الـ diff والمواصفات، دون محادثة كاتب الكود. واستخدام نموذج مختلف يغيّر أيضًا نوع الأخطاء التي يقع فيها المراجِع، كأن يراجع Codex كودًا كتبه Claude Code.
أعطوا المراجِع الـ diff، والمواصفات أو الـ issue، وما يجب أن يبحث عنه. مثلًا، اطلبوا منه أن يتحقق من أن التنفيذ يلبّي المتطلبات ويتعامل مع حالات الفشل.
أرفقوا قائمة تحقق المراجعة في مشروعكم، المحفوظة في المستودع، أو اجمعوا هذه التعليمات في skill للمراجعة. قواعد مثل «لا تستخدموا mock لقاعدة البيانات أبدًا» و«كل نقطة نهاية تتحقق من التخويل» هي قرارات خاصة بالمشروع لا يعرفها مراجِع عام. اطلبوا من المراجِع صراحةً أن يقرأ هذه القواعد.
ولأن المراجعة أداة ضبابية، فقد يعطي تشغيل آخر ملاحظات مختلفة على الكود نفسه. ومن المفيد تشغيل عدة مراجعات، بوكلاء فرعيين يبدأ كل منهم بسياق جديد وبموجز المراجعة نفسه.
اجمعوا ملاحظاتهم، ووحّدوا المكرّر منها. اتفاق المراجعين دليل مفيد، لكنه لا يثبت أن الملاحظة صحيحة.
اطلبوا من المراجِع ترتيب الملاحظات حسب أهميتها وحسب صعوبة إصلاحها أو كلفته. واشترطوا سيناريو فشل ملموسًا لكل ملاحظة، لتتمكنوا من تقدير العاقبة والعمل المقترح معًا.
مثلًا، يكتب المراجِع: «إذا فشل الحفظ، يُبلغ التطبيق عن النجاح رغم ذلك، وعند إعادة التحميل تضيع التعديلات». هذه عاقبة خطيرة، حتى لو كان إصلاحها صغيرًا: معالجة الخطأ وإضافة اختبار. الأهمية والجهد يجيبان عن سؤالين مختلفين.
في Claude Code أمر مدمج هو /code-review، لمراجعة الـ diff الحالي، أو pull request أو فرع تحدّدونه. ويمكنكم اختيار مستوى الجهد، من low إلى max. الخيار --comment ينشر الملاحظات تعليقاتٍ على أسطر الـ pull request. والخيار --fix يطلب من Claude Code أن يطبّق الملاحظات على شجرة العمل بعد المراجعة.
وفي Claude Code أيضًا الأمر /security-review لفحص تغييرات الفرع بحثًا عن ثغرات أمنية. وفي Codex CLI، يبدأ الأمر /review مراجعة للكود. اطّلعوا على المساعدة في النسخة المثبّتة لمعرفة الخيارات، فهذه الأوامر تتغيّر.
حين تطلبون من المراجِع ملاحظات، فأنتم تدفعونه إلى أن يجد شيئًا ما، بما في ذلك مشكلات غير حقيقية. تحقّقوا من كل ملاحظة قبل التصرّف، والأفضل أن تحوّلوا سيناريو الفشل فيها إلى اختبار فاشل.
في مثال الحفظ، اجعلوا الحفظ يفشل، وتحقّقوا من أن التطبيق يُبلغ عن الفشل لا عن النجاح. إذا كشف الاختبار الخطأ البرمجي، فلديكم دليل ملموس يبرّر الإصلاح، واختبار تراجع تحتفظون به.
افصلوا بين المراجعة والإصلاح: المراجِع يكتب تقريره، وأنتم تقرّرون ما تقبلونه. المراجِع الذي يطبّق إصلاحاته بنفسه يصبح كاتبًا ثانيًا تحتاج تغييراته أيضًا إلى فحص.
تفيد مراجعة الوكيل في الأخطاء البرمجية الموضعية، والحالات الحدّية المنسية، ومخالفة المواصفات، ونقص معالجة الأخطاء، والتناقضات. لكنها أقل موثوقية في الحكم على صواب اختياركم للميزة، وعلى ملاءمة التغيير للبنية المعمارية.
وهي تغفل أيضًا الثوابت (invariants) في ملفات لم تقرأها، وقراءة الكود لا تثبت سلوكه وقت التشغيل. تغييرات الأمان، وترحيل البيانات، والـ APIs العامة ما زالت تحتاج إلى أن يقرأها إنسان.
مراجعة الوكيل تساعدكم على التعامل مع كود يصل أسرع من أن تقرؤوه كله. المراجعات بسياق جديد تعطيكم ملاحظات ملموسة للتحقق منها، بينما يبقى لكم القرار في ما يُغيَّر وما يُدمج.
نراكم في الفيديو التالي.