GitLab تنقل نظام تحديد معدل الطلبات إلى وكلاء الذكاء الاصطناعي: 14 مواصفة وأكثر من 30 طلب دمج

أجرى فريق صغير في GitLab تجربة رحّل فيها، بمساعدة وكلاء الذكاء الاصطناعي، جزءًا من نظام قديم لتحديد معدل الطلبات (rate limiting) إلى تنفيذ موحّد داخل مكتبة labkit-ruby، دون خفض مستوى الموثوقية. ويصف الفريق نفسه نتيجة التجربة بأنها ناجحة.

كيف كان النظام قبل الترحيل

ظل مساران لتحديد معدل الطلبات يعملان بالتوازي في GitLab لسنوات: المسار التطبيقي `Gitlab::ApplicationRateLimiter` الذي يضم 121 مفتاحًا، ونظام منفصل على مستوى Rack. وكان هدف الترحيل دمج المسارين في تنفيذ موحّد داخل `labkit-ruby`، بحيث يصبح النظام قابلًا للمراقبة والاختبار ويعمل بالطريقة نفسها في جميع أجزاء المنتج. ويمرّ كل طلب إلى النظام المتجانس (monolith) في GitLab عبر هذا النظام، ولذلك يجب أن تكون أعطاله مرئية وقابلة للتراجع عنها.

من عمل على الترحيل وكيف

عمل على المشروع ثلاثة مهندسين من GitLab ومجموعة من وكلاء الذكاء الاصطناعي.

• ماكس وولف (Max Woolf)، مهندس خلفية أول (Staff Backend Engineer) في فريق API Platform، تولى جانب النظام المتجانس وأشرف على معظم الإصدارات
• بوب فان لاندويت (Bob Van Landuyt) من فريق Scalability، تولى المكتبة نفسها وهندسة الحل المعمارية
• شارك عدة مهندسين آخرين في مراحل محددة للاطلاع على السياق والمساعدة في الشيفرة والمراجعة
• استُخدم GitLab Duo Agent Platform وGitLab Duo Code Review

قرأ الوكلاء السياق وأعدّوا مسودات المواصفات، ونفذوا تغييرات محدودة النطاق، وكتبوا الاختبارات، وأجروا مراجعة أولية لطلبات الدمج (merge request). واحتفظ المهندسون البشر بتحديد النطاق والهندسة المعمارية والإصدارات والقرار النهائي.

كيف كانت دورة العمل

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

• أصدر الفريق خلال المشروع 14 مواصفة مرقّمة
• أُرسل إلى مكتبة `labkit-ruby` أكثر من 30 طلب دمج (merge request)
• عمليًا، اختلف مدى صرامة الدورة من مهندس إلى آخر: فقد كان بوب فان لاندويت يجري في كثير من الأحيان عدة جولات من المواصفات والمراجعة بمفرده قبل عرض النتيجة المشتركة على الفريق

ماذا يعني ذلك

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

الأسئلة الشائعة

كم شخصًا عمل على ترحيل rate limiting في GitLab؟

عمل على المشروع ثلاثة مهندسين من GitLab، هم ماكس وولف وبوب فان لاندويت وعدة مهندسين آخرين شاركوا في مراحل محددة، إلى جانب مجموعة من وكلاء الذكاء الاصطناعي المبنيين على GitLab Duo Agent Platform.

كم شيفرة ومواصفة أنتج الفريق؟

أعدّ الفريق خلال التجربة 14 مواصفة مرقّمة، وأرسل أكثر من 30 طلب دمج (merge request) إلى مكتبة labkit-ruby.