Garage Eight تتخلى عن موافقات الآخرين في 69 طلب دمج (MR) لخدمة داخلية بمراجعة بالذكاء الاصطناعي

سرّعت الفريق كتابة الكود بمساعدة الذكاء الاصطناعي، ثم اصطدم بمرحلة المراجعة: فعدد المراجعين لم يزد. في Garage Eight كان بإمكان ميزة واحدة لنظام Android مؤلفة من 35 طلب دمج (merge request) أن تنتظر أسبوعًا للحصول على موافقتين لكل طلب. والسؤال العملي هنا بسيط: أي التغييرات يمكن تمريرها بعد فحص الروبوت، كي يتفرغ الناس لتحليل الأخطاء المكلفة فعلًا؟

بحسب ما روته آنا ساﺑوتوفيتش، التي تقود تبنّي المراجِع الآلي بالذكاء الاصطناعي، دُمج في أكتوبر 69 طلب دمج في الخدمة الداخلية لتحليلات التطوير دون موافقة شخص آخر. أما في مستودع المراجِع نفسه فكانت موافقة الغير موجودة في ستة طلبات فقط من أصل 35. هذه حالة مفيدة للفرق التي يتزايد لديها طابور التغييرات، لكنها لا تمنح إذنًا شاملًا بالاستغناء عن المراجعين.

عدد المراجعين يتوقف على كلفة الخطأ

تقسّم Garage Eight خدماتها إلى أربعة مستويات من المخاطر. وما يهمّ في المراجعة هو ما سيحدث إذا أعطت الخدمة نتيجة خاطئة. يضع معماريو المجالات التقييم وفق أسوأ سيناريو، وتُعدّ الخدمة التي بلا تقييم الأعلى خطورة.

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

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

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

الملاحظة المغلقة لا تعني خطأً مُصلَحًا

بدت المقياس الأول مقنعًا: 92% من ملاحظات الروبوت كانت تُغلق. لكن GitLab في المستودعات المحمولة يمنع الدمج ما دام هناك نقاش مفتوح. ومن بين الملاحظات المحلَّلة على طلبات الدمج المدموجة أُغلقت جميعها: 647 من 647. أي أن المقياس كان يعكس عمليًا استيفاء شرط الدمج.

لذلك بدأ الفريق ينظر هل تغيّر قبل الدمج الكود المجاور لسطر الملاحظة. ثم قارن النتيجة بالخلفية: كم مرة يتغيّر موضع عشوائي في الملف نفسه.

خلال الربع الثالث في 12 مستودعًا ترك الروبوت 585 ملاحظة جدّية. وبعد 219 منها تغيّر الكود المجاور، أي 37% مقابل 7% للخلفية. ومن 27 حالة فُحصت يدويًا كان التعديل في 25 منها متعلقًا فعلًا بالملاحظة. وبتقدير كاتب المادة، أُصلح قبل الدمج خلال الربع نحو 200 مشكلة جدّية، بينها 98 خطأً برمجيًا.

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

الروبوت أيضًا يحتاج إلى طابور وفحوص وصمامات أمان

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

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

وهناك أيضًا مشكلة النقاشات اللانهائية: ففي أحد طلبات الدمج فحص الروبوت 27 تعديلًا (commit) وترك 45 ملاحظة، وردّ وكيل المؤلف على 44 منها. ويرى الفريق أنه لا بدّ من تحديد عدد الدورات وفحص الفروق (diff) الجديدة فقط.

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