«من ملفات الإرشادات إلى بوابات التحقق: كيف تتكيف البرمجيات مفتوحة المصدر مع المساهمين الآليين؟»

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

أظهرت التجربة العملية في «أوتو جي بي تي» أن كتابة أدلة المساهمة التقليدية والوثائق العامة لا تفي بالغرض، لأن الأدوات والوكلاء لا يقرؤون الوثائق تلقائياً ما لم يتم توجيههم إليها مباشرة. فالوكلاء يقرؤون ما يوضع أمامهم مباشرة في النطاق الخاص بالدليل الذي يعملون فيه. ولهذا السبب، بدأ المشروع بتضمين الإرشادات في الأماكن التي يبحث فيها الوكلاء مباشرة، عبر استخدام ملفات «CLAUDE.md» في البداية، ثم التوسع نحو اعتماد ملفات معيارية باسم «AGENTS.md» توضع بجوار الكود الذي تحكمه. تتيح هذه الملفات المحددة بنطاق المجلدات تزويد الوكلاء بالسياق الخاص بالمستودع البرمجي، إلى جانب المهارات التي تكتشف ديناميكياً خارج نطاق المجلد لفرض قواعد محددة، مثل إلزام الوكلاء بكتابة اختبارات واجهة المستخدم أو تحقيق نسبة تغطية لا تقل عن 80% في الشفرات الخلفية قبل فتح طلب التعديل.

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

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

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