في شركة Aviator، تمكن تسعة مهندسين من مراجعة ودمج طلبات سحب كود الذكاء الاصطناعي بمعدل أربعة أضعاف، مما خفض متوسط وقت الدمج من 2.1 يوم إلى 3.4 ساعات، وقلل عمليات التراجع بنسبة 40%. هذا التحول سمح للمهندسين بالتركيز على جوانب أساسية مثل النية وراء التغيير، ومعايير القبول، والثوابت التي لا يمكن كسرها، والقرارات المتخذة، والأدلة التي تثبت عمل الكود، بدلاً من قراءة كل سطر. لا يزال البشر يوافقون على كل طلب سحب، لكن ما تغير هو ما يقرؤونه.
تبين أن القرارات تحتاج إلى شخص، وأن مقارنة الفروقات (diff) هي أسوأ مكان لاتخاذها. جاء هذا الفهم من خلال فرز تعليقات المراجعة الخاصة بالشركة، حيث أن معظم ما يكتبه المراجع على طلب السحب هو إما قاعدة سبق له كتابتها أو قرار. يجب أن تتحقق الآلات من القواعد في كل مرة، بينما تحتاج القرارات إلى شخص.
لماذا لم تعد مراجعة الكود التقليدية مجدية مع الذكاء الاصطناعي؟
لم تعد مراجعة الكود التقليدية تتناسب مع حجم كود الذكاء الاصطناعي. فقد تحول الكود من كونه مكتوبًا بواسطة البشر بمساعدة الذكاء الاصطناعي إلى كود مولّد بالذكاء الاصطناعي بمساعدة بشرية. ارتفعت طلبات السحب المدمجة أسبوعيًا من حوالي 100 إلى أكثر من 400. وصل متوسط حجم طلب السحب المولّد بالذكاء الاصطناعي إلى 640 سطرًا، متجاوزًا بكثير حد الـ 400 سطر الذي يُعتبر النقطة التي تتراجع عندها القدرة على اكتشاف الأخطاء.
يُذكر أن اكتشاف الأخطاء لم يكن النقطة الأساسية لمراجعة الكود على الإطلاق. ففي دراسة مايكروسوفت لعام 2013 (Bacchelli & Bird)، كانت 14% فقط من تعليقات المراجعة تتعلق بالعيوب. تُعد المراجعة وسيلة للمهندسين لتبادل المعرفة والحفاظ على نموذجهم الذهني للنظام محدثًا، وهذا هو الجزء الذي يستحق الحماية. عندما تكتب الوكلاء معظم الكود، يصبح هذا الجزء هو الأكثر عرضة للخطر.
لم تنجح بعض الأساليب في تحسين مراجعة الكود:
أصبحت المراجعات الأولى أسرع، والموافقات أكثر فراغًا، حيث كان المراجعون يتصفحون بسرعة للالتزام بالوقت، وتوقفت أعمالهم الخاصة.
- المراجع الآلي: في أحد طلبات السحب الخاصة بالمؤلف، فتح 16 من أصل 18 موضوعًا: أرقام سحرية، مفاتيح React تعتمد على فهرس المصفوفة، ومكون استغرق وقتًا طويلاً. موضوع واحد فقط اكتشف حالة سباق حقيقية. أما التعليقان المهمان، وكلاهما قرارات تصميم من زملاء الفريق، فقد دُفنا تحت التفاصيل الثانوية.
- مهارة المراجعة الذاتية المخصصة لاتفاقيات الشركة: كانت نتائجها أفضل بكثير من الروبوت العام. لكنها كانت لا تزال تقرأ الفروقات بعد كتابة الكود، والجزء الأكثر فائدة من التفاعل، وهو ما جادلت فيه وما تم اتخاذه من قرارات، ضاع في نافذة الدردشة.
كل هذه المحاولات الثلاث سعت إلى قراءة الفروقات بشكل أفضل. لكن الفروقات هي الجزء الأقل أهمية في مراجعة الكود على أي حال، فهي تُظهر ما تغير، وليس السبب وراء التغيير.
كيف تعمل المراجعة الفعالة لكود الذكاء الاصطناعي؟
كانت مراجعة الكود تؤدي عدة وظائف في وقت واحد: اكتشاف الأخطاء، فرض اتفاقيات الفريق، تسوية قرارات التصميم، والحفاظ على فهم الجميع للنظام محدثًا. قامت الشركة بتقسيم هذه الوظائف ومنح كل منها مكانًا أفضل.
مثال على ذلك قاعدة تنص على أن كل تغيير في الإعدادات يكتب إدخالاً في سجل التدقيق، فقط عندما يتغير شيء. تغطي هذه القاعدة تعديلات GraphQL ومعالجات API التي تكتب الإعدادات، ويتم التحقق منها عن طريق تشغيل معاينة تحفظ مرتين وتقرأ سجل التدقيق، وقد تم استخراجها من 23 موضوع مراجعة عبر 17 طلب سحب، وهي تابعة لفريق المنصة. يُعد نموذج التحقق من كل قاعدة ثابتة على كل طلب سحب بطيئًا وغير قابل للتكرار بشكل مثالي، لذلك حيثما أمكن، يقوم وكيل بتجميع القواعد الثابتة في قواعد ast-grep تعمل في الظل بجانب النموذج حتى تتفق. تعليق سابق مثل إضافة مهلة لتجنب تعليق عامل، والذي تركته الشركة على تسعة طلبات سحب، أصبح الآن قاعدة من ثمانية أسطر. تعمل تسعة عشر قاعدة ثابتة بشكل حتمي في 0.3 ثانية.
هذا الجزء الثاني هو بالضبط ما لن يتحقق منه المراجع الذي يقرأ الفروقات أبدًا. لا يحتاج كل معيار إلى متصفح: يتم إثبات عقد API بطلب واستجابة مسجلين، وقاعدة الكود بمطابقة ast-grep أو استشهاد بملف وسطر. يتم اختيار أرخص دليل يحسم السؤال.
يتصفح المراجعون ما تم تسويته، ويسوون ما لم يتمكن الوكلاء من تسويته، ويعيدون فتح أي شيء قد يختلفون فيه، ويناقشونه مع المؤلف. هذه المحادثة تبني فهمًا للنظام.
- المجادلة قبل وجود طلب السحب: يقوم وكيل المراجعة باستجواب وكيل المؤلف، الذي يعمل على نموذج مختلف، ويسجل كل خلاف. في أحد طلبات السحب الأخيرة، أثار الوكلاء أربعة خلافات وسووا ثلاثة منها بسبب معلن. الخلاف الوحيد المتبقي للبشر كان قرارًا يتعلق بالتسمية.
- التقاط النية ومعايير القبول: ليس كمواصفات مسبقة، بل يتم التقاطها من جلسة البرمجة مع الوكيل. في كل مرة يقوم فيها المهندس بتصحيح الوكيل أو الإجابة على سؤاله، يتم إنشاء معيار. كانت هذه المعايير تُهمل بعد انتهاء الجلسة. لا يمكن التحقق من النية بدون معايير، ولا يمكن الحكم على المعايير بدون نية.
- تدوين التعليقات المتكررة كقواعد ثابتة (invariants): تم استخراج تاريخ المراجعة لمدة عام في ثلاث مراحل: إسقاط الضوضاء مثل ملخصات الروبوت وعبارات الموافقة العامة، وتصنيف كل تعليق كقاعدة أو اقتراح أو إصلاح لمرة واحدة أو سؤال، ثم دمج التكرارات. تحولت 11,400 تعليق إلى 212 قاعدة مرشحة و 64 قاعدة ثابتة معتمدة. لكل منها نطاق، وطريقة تحقق، ومصدر، ومالك.
- إثبات كل معيار بالأدلة: يصبح كل معيار سيناريو. يقوم وكيل بإنشاء بيئة معاينة، ويشغلها كمستخدم، ويسجل لقطات الشاشة والطلبات والسجلات.
- مناقشة القرارات: تأتي القرارات من ثلاثة أماكن: جلسة البرمجة، ومجادلة الوكلاء، وتشغيل التحقق الفاشل. يسرد طلب السحب كل قرار، ومصدره، ومن قام بتسويته.
- امتلاك القواعد: يتوقف المهندسون عن قراءة كل سطر. يمتلكون القواعد التي تتحقق من كل سطر، ويحافظون على فهمهم للنظام من خلال قراءة النية والأدلة والقرارات.
النتائج:
- طلبات السحب المدمجة أسبوعيًا: 4 أضعاف، بنفس المهندسين التسعة.
- متوسط وقت الدمج: من 2.1 يوم إلى 3.4 ساعات.
- المواضيع البشرية لكل طلب سحب: من 6.2 إلى 1.3.
- عمليات التراجع لكل 100 طلب سحب: انخفاض بنسبة 40%.
لم يختفِ عمل المراجعة، بل انتقل إلى تحسين القواعد الثابتة، ومناقشة القرارات، وتحسين التحقق. يُتوقع أن يكون الانتقال مؤلمًا: الشهر الأول هو عمل مضاعف، وبحلول الشهر الثاني تلحق القواعد الثابتة بالركب بما يكفي لتقليص المراجعات، وبحلول الشهر الثالث تقرأ النية والأدلة، وليس الكود.
جرّب الأداة: فاحص الفروقات بين النصوص
