ربطت وكيل مراجعة كود بالذكاء الاصطناعي في خط أنابيبك، وقد نجح الأمر. رصد غياب فحص للقيم الفارغة، والتقط استيرادًا غير مستخدم، وترك ثلاثة تعليقات مرتبة حول التسمية. ثم دمجت التغيير. وبعد يومين اصطدم أحد العملاء بخطأ مرّ عليه الوكيل دون أن يلاحظه: كان التغيير سليمًا من الداخل لكنه يفعل الشيء الخطأ. تحقق وكيل المراجعة من الكود، لكنه لم يستطع التحقق من النية.
تلك الفجوة هي القصة كاملةً لوكلاء مراجعة الكود بالذكاء الاصطناعي. فهم بارعون في فئة محددة وقابلة للفحص من المشكلات، وعميون عن فئة أخرى تبدو مطابقة تمامًا في فرق التغييرات (diff). وإن تعاملت مع موافقتهم كقبول نهائي، فستُطلق إلى الإنتاج تلك الفئة التي لا يرونها. أما إن عرفت أين يقع الخط الفاصل، فستحصل على مرور أولي سريع يحرّر مراجعيك للقيام بالحكم الذي لا يقدر عليه إلا البشر.
ترسم هذه المقالة ذلك الخط الفاصل: ما يستطيع وكيل مراجعة الكود بالذكاء الاصطناعي التحقق منه، وما لا يستطيع، والنموذج التشغيلي الذي يبقي الاثنين منفصلين بوضوح. وSharkly هو الطبقة التي سنستعرضها، مساحة العمل المشتركة حيث تكون مراجعة الوكيل وقبول الإنسان حالتين مختلفتين على المهمة نفسها، لا ختم موافقة واحد. أنت تملك بالفعل وكلاء برمجة؛ والنقطة هنا هي مراجعة مخرجاتهم دون التظاهر بأن وكيلًا ثانيًا يُغلق الحلقة.
ما الذي يستطيع وكيل مراجعة الكود بالذكاء الاصطناعي التحقق منه
وكيل مراجعة الكود بالذكاء الاصطناعي هو برنامج يقرأ فرق التغييرات (diff)، ويجري فحوصًا عليه، ويُبلّغ عن النتائج بالطريقة التي يترك بها المراجع البشري تعليقاته. ومنطقته الموثوقة تشمل كل ما يستطيع مراجع دقيق تأكيده بقراءة التغيير وما يجاوره مباشرة:
- الصحة الميكانيكية: الصياغة (syntax)، والأنواع (types)، ومعالجة القيم الفارغة والحدود الواضحة، ورفض الوعود (promise rejections) غير المعالَج، وتسريبات الموارد الظاهرة في فرق التغييرات.
- المنطق المحلي: أخطاء الخطأ بواحد (off-by-one)، والشروط المعكوسة، والفروع الميتة، وقراءة متغير قبل تعيينه.
- الاصطلاحات: التسمية، والتنسيق، ونظافة الاستيراد، وما إذا كانت الدالة الجديدة مصحوبة باختبار إلى جوارها.
- الأنماط المضادة المعروفة: بناء استعلامات SQL عبر دمج النصوص، أو حفظ الأسرار بنص صريح، أو دالة عامة تفتقر إلى التحقق من المُدخلات.
تشترك هذه كلها في سمة واحدة: الدليل موجود داخل فرق التغييرات نفسه. لا يحتاج الوكيل إلى معرفة طبيعة عملك ليرصدها، وهو يرصدها أسرع وبثبات أكبر من إنسان متعب في السادسة مساءً. وهذه قيمة حقيقية، ولهذا تهرع الفرق إلى هذه الأدوات. ويعتبر دليل مراجعة الكود من Google هذا المرور الميكانيكي حدًا أدنى أساسيًا حتى يتفرغ انتباه البشر للتصميم. والمراجع الذكي وسيلة صبورة لاجتياز هذا المرور في كل مرة.
ما الذي لا يستطيع التحقق منه
وهذا هو الحد الفاصل بصراحة: لا يستطيع وكيل مراجعة الكود بالذكاء الاصطناعي التحقق من أن التغيير هو التغيير الصحيح. فكل ما يلي يحتاج إلى سياق لا يحتويه فرق التغييرات.
- النية مقابل المواصفة. قد يكون الكود خاليًا من العيوب لكنه يحل المشكلة الخطأ. ولا يحدد ذلك سوى معايير القبول الخاصة بالتذكرة، والوكيل نادرًا ما تكون هذه المعايير أمام عينيه.
- الصحة التجارية. ما إذا كانت قاعدة خصم، أو حساب ضريبة، أو حد صلاحيات يتوافق مع طريقة عمل الشركة، هو حكم تقديري وليس قاعدة فحص آلي.
- السلوك عبر الأنظمة. فقد يبدو تغيير سليمًا في ملف واحد لكنه يعطّل جهة استدعاء تبعد ثلاثة خدمات. وقائمة OWASP العشرة الأوائل مليئة بأخطاء مثل انكسار التحكم في الوصول لا تظهر إلا عند تتبع مسار الطلب كاملًا، لا فرق التغييرات وحده.
- ما إذا كانت الاختبارات صادقة. يستطيع الوكيل التأكد من وجود اختبار ونجاحه، لكنه لا يستطيع إخبارك بأن الاختبار يتحقق من الأمر المهم فعلًا، أو بأن الوكيل الذي كتب الكود هو نفسه من كتب اختبارًا مصممًا لينجح.
وهذه النقطة الأخيرة هي الفخ الخاص بالكود المكتوب بالذكاء الاصطناعي. فعندما تنتج فئة النظام نفسها التغيير والمراجعة معًا، قد يكون فرق التغييرات نظيفًا وعلامة الفحص خضراء، وكلاهما صحيح ومع ذلك لا قيمة له. لذا فإن موافقة وكيل المراجعة إشارة، لا قرار. الوكيل يُبلّغ، والإنسان يقبل.
النموذج التشغيلي الذي يسد الفجوة
الحل ليس وكيل مراجعة أفضل، بل نموذج تشغيلي تكون فيه مهمة وكيل المراجعة ومهمة الإنسان حالتين مختلفتين، ولا تُتجاوز أي منهما.
ويجعل Sharkly هذه الحالات صريحة عبر حالة المهمة. تنتقل المهمة من «قيد التنفيذ» إلى «جاهزة للمراجعة» إلى «منتهية». والقاعدة بسيطة وحاسمة: الوكلاء ينقلون العمل إلى «جاهزة للمراجعة»، والبشر ينقلونه إلى «منتهية». ولا يستطيع أي وكيل، سواء كتب الكود أو راجعه، اعتبار عمله مقبولًا. الوكلاء يبحثون وينفذون ويختبرون ويُبلّغون. والبشر يحددون التوجه، ويمنحون الصلاحية، ويقبلون النتيجة. وتتوقف الأتمتة حيث يلزم حكم الفريق.
لكل دور مهمة واحدة. وكيل البرمجة ينتج التغيير. ووكيل المراجعة يجري المرور الميكانيكي ويرفق نتائجه. والمراجع البشري يقرأ تلك النتائج، ويتحقق من التغيير مقابل نية التذكرة، ثم يقرر. ويعود كل ذلك إلى المهمة: فرق التغييرات، وتعليقات وكيل المراجعة، ومخرجات الاختبار، وقرار الإنسان، كلها تسير على خط زمني واحد بدل أن تتفرق بين طلب سحب (PR) ومحادثة وذاكرة شخص ما.
استخدم وكيل المراجعة كبوابة أولى عندما يكون التغيير ميكانيكيًا ومستقلًا بذاته، مثل إعادة هيكلة، أو تحديث اعتمادية، أو إصلاح خطأ محدد النطاق؛ ودعه ينظف الضجيج كي يكون مرور الإنسان سريعًا. لكن لا تعتمد عليه كبوابة وحيدة عندما يمس التغيير المال أو المصادقة أو ترحيل البيانات أو العقود العامة؛ فهناك يقرأ الإنسان أولًا، ويكون مرور الوكيل قائمة تحقق لا حكمًا نهائيًا.
مثال عملي: من التذكرة إلى دمج طلب السحب
خذ التذكرة SH-312: «ارفض أكواد الكوبونات المنتهية عند الدفع». يكتب شخص معايير القبول ويعيّن المهمة. فيتولاها وكيل برمجة، ويعمل في شجرة عمل معزولة، ويعيد إلى المهمة فرق تغييرات مع اختبار ناجح، ناقلًا إياها إلى «جاهزة للمراجعة».
الآن يعمل وكيل المراجعة. يؤكد الأنواع، ويرصد فحصًا ناقصًا للقيم الفارغة، ويلاحظ أن الاختبار يغطي حالة الانتهاء. مرور نظيف. وبحسب العادة القديمة، تُدمج هذه الموافقة.
لكن المراجع البشري يفتح المهمة ويقرأ على ضوء النية. الكود يرفض الكوبونات المنتهية، تمامًا كما كُتب. غير أن معايير القبول كانت تعني ضمنًا أيضًا رفض الكوبونات المستردّة سابقًا، ولم يعرف ذلك لا وكيل البرمجة ولا وكيل المراجعة، لأنه موجود في ذهن المراجع وفي مواصفة المنتج، لا في فرق التغييرات. فيطلب المراجع إجراء تغيير. وتعود SH-312 إلى «قيد التنفيذ» بملاحظة محددة، فيوسّعها الوكيل، وعندها فقط ينقلها شخص إلى «منتهية» ويدمج طلب السحب.
أدى وكيل المراجعة مهمته جيدًا، ومع ذلك كان سيشحن ثغرة. لكن النموذج التشغيلي التقطها، لأن القبول كان فعلًا منفصلًا يقوم به شخص يملك السياق. وهذا هو الانضباط نفسه الذي تقوم عليه مراجعة الكود المولّد بالذكاء الاصطناعي بأدلة على مستوى المهمة: وحدة المراجعة هي المهمة ونيّتها، لا فرق التغييرات بمعزل عن سياقه.
أين تضع بوابات المراجعة
السؤال العملي ليس ما إذا كنت ستستخدم وكلاء مراجعة الكود بالذكاء الاصطناعي، بل أين يُحتسب مرورهم وأين يجب أن يقرأ الإنسان أولًا. وإليك بعض القواعد الصامدة:
- دع الوكيل يبوّب الأسلوب والتنسيق والأخطاء الميكانيكية في كل تغيير. فهذا هو المرور الذي يبرع فيه أكثر وأسوأ ما يفعله البشر عند الإرهاق.
- اشترط بوابة بشرية على أي شيء يمس المصادقة أو الفوترة أو ترحيل البيانات أو واجهة برمجية عامة. فالنقطة العمياء تتركز هناك.
- اضبط حجم بواباتك بحسب طاقة المراجعة لديك. فالوكلاء ينتجون أسرع مما يقبل البشر، لذا أنفق مرور الإنسان حيث يكون الوكيل أعمى.
- اجعل البوابة حالة، لا عادة. فبوابة موافقة موثّقة تحجب الانتقال إلى «منتهية» قابلة للإنفاذ، أما قاعدة «ينبغي على أحدهم إلقاء نظرة» فلا. وإبقاء إنسان في الحلقة لا ينجح إلا عندما تكون الحلقة خطوة تستلزمها سير العمل.
وكيل مراجعة الكود بالذكاء الاصطناعي ليس بديلًا عن المراجع البشري. إنه المرور الأول الذي يجعل مرور الإنسان أسرع وأدق. وإن كنت تدير بالفعل عدة وكلاء برمجة وتريد مراجعة مخرجاتهم وقبولها في مكان واحد بدل خمسة تبويبات لطلبات السحب، فهذه هي المشكلة التي بُني Sharkly من أجلها: تعيين عمل الوكلاء وتتبعه ومراجعته على مهام مشتركة، بحيث تعود نتائج وكيل المراجعة وقرار الإنسان معًا إلى السجل نفسه. أبقِ على وكلاء البرمجة ووكيل المراجعة الذين تستخدمهم بالفعل، ثم أضف الطبقة التي تحدد متى يكون مرورهم كافيًا.
