كيف تراجع طلب سحب (pull request) كتبه وكيل الذكاء الاصطناعي الخاص بك

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

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

تحقّق من تغييرات الـ CI أولًا

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

• اختبارات مُزالة أو معاد تسميتها أو مُتخطّاة
• خفض عتبات التغطية
• خطوة فحص نمط (lint) أو فحص أنواع مُقيَّدة بصمت خلف شرط جديد
• إلحاق || true بأمر اختبار أو بناء بحيث "ينجح" دائمًا
• سير عمل مُعطَّل في طلبات السحب أو في النُّسخ المتفرّعة (forks)

أي تغيير يُضعف الـ CI هو عائق حاجب حتى يُبرَّر صراحةً. عامِل العلامات الخضراء على أنها ذات معنى فقط إذا لم تُضعَّف الفحوص نفسها في طلب السحب ذاته.

تتبّع الشِفرة المكرَّرة

لدى الوكلاء عمى تجاه إعادة الاستخدام: فهم يكتبون عن طيب خاطر دالة مساعِدة جديدة تمامًا باسم formatCurrency دون أن يلاحظوا أن واحدة موجودة بالفعل على بُعد ثلاثة مجلدات. انتبه للدوال المساعِدة الجديدة التي تكرّر دوالًا قائمة، أو لمنطق تحقّق أُعيد تنفيذه في مكانين، أو لوسيط برمجي (middleware) "شبه متطابق" تحت اسم مختلف. وعندما تجد مرشّحًا، ابحث في المستودع عن مكافئ له واطلب الدمج قبل الإدماج. فإن تُرك هذا دون ضبط، فهذه بالضبط هي الطريقة التي يتراكم بها ذلك الدَّين التقني الإضافي.

تتبّع المسار الحرج يدويًا

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

• الحالات الحدية: صفر، فارغ، الحد الأقصى، null
• فحوص الأذونات في كل فرع، وليس في المسار السعيد فقط
• حالات السباق (race conditions) عند مشاركة الحالة

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

مثال ملموس. "يصلح" وكيلٌ نقطة نهاية للخصم وتنجح كل الاختبارات. تتبّع المسار فتلاحظ أن الشِفرة الجديدة تقرأ cart.items قبل التحقّق من if (!cart) return. مع مستخدم غير مسجّل الدخول، تكون قيمة cart هي null فيرمي المسار خطأ 500 — وهي حالة لم يختبرها الوكيل قط لأنه لم يشغّل سوى المسار السعيد. دقيقتان من التتبّع اليدوي التقطتا ما أخفته العلامة الخضراء.

ارفض مبكرًا عندما يكون طلب السحب أكبر من اللازم

ليس كل طلب سحب صادر عن وكيل يستحق مراجعة عميقة. أعِده لطلب أصغر إن كان:

• يمسّ خمسة ملفات أو أكثر غير مترابطة
• لا يمكن تلخيصه في جملة واحدة
• يصل دون خطة تنفيذ
• يغيّر ملفات الاختبار فقط بينما لا يزال الـ CI يفشل

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

دع الأتمتة تتولّى التمرير الميكانيكي

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

قائمة تحقّق في 10 دقائق

بالنسبة لطلب سحب محدّد النطاق جيدًا، يتسع هذا الروتين كله في نحو عشر دقائق:

1. افحص وصنّف (1–2 دقيقة) — إصلاح ضيّق أم تغيير متضخّم؟
2. فرق الـ CI (2–3 دقيقة) — أبرِز أي شيء يُضعف الاختبارات.
3. الدوال المساعِدة الجديدة (3–5 دقائق) — ابحث عن التكرارات.
4. المسار الحرج (5–8 دقائق) — تتبّع المنطق بنفسك.
5. الأمن (8–9 دقائق) — تحقّق من الأسرار، والرموز (tokens)، وأي خطوات يكون فيها نموذج لغوي ضمن الحلقة (LLM-in-the-loop).
6. الدليل (9–10 دقائق) — اطلب اختبارًا يفشل-ثم-ينجح لتغييرات المنطق.

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