كيف تراجع Aviator كود الذكاء الاصطناعي أكثر بأربعة أضعاف دون قراءة كل سطر

تقول Aviator إن المهندسين التسعة أنفسهم دمجوا طلبات سحب أكثر بأربعة أضعاف بعد أن غيّروا مراجعة الكود من قراءة الفروقات الخام إلى التحقق من النية ومعايير القبول والثوابت والقرارات والأدلة الملموسة. انخفض الوسيط الزمني للدمج من 2.1 يوم إلى 3.4 ساعة، وتراجعت عمليات الإرجاع بنسبة 40%، وما زال إنسان يعتمد كل طلب سحب.

المشكلة: مراجعة الكود لا تتوسع مع الذكاء الاصطناعي

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

لم يكن اكتشاف الأخطاء الهدف الأساسي لمراجعة الكود على أي حال. في دراسة Microsoft لعام 2013 التي أعدّها Bacchelli وBird، كانت 14% فقط من تعليقات المراجعة تتعلق بالعيوب. فالمراجعة هي الطريقة التي يتبادل بها المهندسون المعرفة ويحافظون بها على نموذجهم الذهني للنظام محدّثاً، وهذا هو الجزء الذي يستحق الحماية. وعندما يكتب الوكلاء معظم الكود، يصبح هذا الجزء أيضاً الأكثر عرضة للخطر. وعندما سُئل الفريق إن كان قد توقف ببساطة عن المراجعة، قال لا: لقد توقف عن مراجعة الفرق. وخلاصته أن القرارات تحتاج إلى شخص، وأن الفرق هو أسوأ مكان لاتخاذها.

ما تغيّر: التحقق من النية لا من الأسطر

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

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

وهذا النصف الثاني هو بالضبط ما لا يتحقق منه أبداً مراجع يقرأ الفرق. فليس كل معيار يحتاج إلى متصفح: عقد API يثبته طلب واستجابة مسجّلان، وقاعدة برمجية يثبتها تطابق ast-grep أو إحالة إلى ملف وسطر. والنصيحة هي اختيار أرخص دليل يحسم السؤال. ففحص CI الناجح يقول فقط إن الاختبارات التي فكّرت فيها قد نجحت.

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

ويتوقف المهندسون عن قراءة كل سطر. فهم يملكون القواعد التي تفحص كل سطر، ويحافظون على فهمهم للنظام عبر قراءة النية والأدلة والقرارات.

النتائج

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

المصادر: The New Stack