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

تطلب من الوكيل أولًا الحصول على موافقة على الخطة، ثم كتابة الكود وفحصه على بيئة اختبار. وبعد ساعة يأتيك بـ PR جاهز، لكن الموافقة جرى تخطيها، وبدل نتائج الفحص هناك شرح واثق لسبب وجوب عمل كل شيء. يمكن إضافة تحذير آخر في AGENTS.md، لكن هذا لن يمنح ضمانًا للتنفيذ.

وصف فاليري بوشتاريوف من فريق Checks، الذي يتولى مكافحة الاحتيال في أفيتو، نهجًا مختلفًا: نقل المتطلبات القابلة للتحقق من التعليمات إلى سكربتات وhooks. فهي تحدد المرحلة التي بلغتها المهمة، وهل التعديلات مسموحة، وهل يمكن تسليم النتيجة للمراجعة. يُسمّى الإعداد af-checks-context؛ ويعمل المؤلف حاليًا على نقله من استخدامه الشخصي إلى الفريق.

كيف يتحول المتطلب إلى حجب

أساس النظام مستودع git منفصل يحوي سياق الفريق: المواصفات والخطط والمعارف ووصف العملية. وتقع مستودعات الخدمات بجانبه. تبدأ جلسة الوكيل بسياق الفريق حتى لا تقتصر مهمة تمتد عبر عدة خدمات على محتوى مشروع واحد.

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

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

بعد التنفيذ يلزم تقرير من بيئة الاختبار. ويُفحص فيه الحكم pass وهاش الـ commit الذي جرى فحصه. فإذا أضاف الوكيل بعد تشغيل ناجح تعديلًا آخر، فلن يؤكد التقرير السابق النسخة الحالية. حتى التغيير الصغير يتطلب دليل فحص محدّثًا.

أين كانت القيود الأولى مليئة بالثغرات

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

ونشأت مشكلة منفصلة مع بوت كان يميّز بين تغييرات العملية والمحتوى العادي. فقد كان يقرأ قائمة المسارات المحمية من الـ PR قيد الفحص. وكان بوسع تغيير أن يزيل دليله من القائمة فيقع في فئة تسمح بالدمج دون إنسان. الإصلاح: أخذ القواعد من الفرع الهدف، واعتبار أي تغيير في ملف الإعداد نفسه تغييرًا في العملية دائمًا.

كما أن الفحص بواسطة وكيل آخر لا يضمن الصواب. ففي إحدى المرات وجد المدقق تناقضًا بين المواصفة وخدمة مجاورة. وكانت نسخته المحلية متأخرة بـ 36 commit؛ أما السلوك المطلوب فكان موجودًا أصلًا. والآن تُقارَن مثل هذه الاكتشافات أولًا مع origin المحدّث. فتقسيم الأدوار مفيد، لكن لا بد مع ذلك من التحقق من حداثة البيانات المصدرية.

ما يستحق النقل إلى عمليتك

يمكن البدء بانتقال واحد ينكسر عندكم باستمرار. مثلًا، منع تسليم الـ PR للمراجعة دون تقرير ناجح للـ commit الحالي. ثم اختبار الـ gate نفسه: ماذا يحدث عند تقرير فارغ، أو نوع ملف خاطئ، أو commit جديد، أو خطأ في تحميل سكربت الفحص؟

يجب دفع ثمن الرقابة في صورة صيانة. فعند المؤلف كان الـ hook الابتدائي يعمل من 14.6 إلى 18 ثانية مع مهلة 15 ثانية، ولذلك كان السياق أحيانًا لا يصل إلى الوكيل بصمت. وكانت علامات الاختيار الخدمية تغيّر هاش الخطة وتسبب موافقات متكررة. واضطر إلى تبسيط النظام، وفصل الفحوص السريعة عن البطيئة، واستبعاد الأسطر الخدمية من حساب نسخة الخطة.

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