وكلاء البرمجة جعلوا CI عنق زجاجة؛ وتسريع خطوط البناء ليس الحل الكامل

أصبح التكامل المستمر (CI) نقطة اختناق جديدة مع توسع استخدام وكلاء البرمجة. وتستند هذه الخلاصة إلى تجارب عرضتها فرق هندسية في Anthropic وLinear وDepot خلال سبتمبر، لا إلى إعلان أداة واحدة. فقد ارتفع حجم وظائف CI لدى Anthropic 25 مرة خلال ستة أشهر، بينما أصبح مهندسوها يشحنون في الربع الواحد شيفرة تزيد بنحو ثمانية أضعاف ما كانوا يشحنونه بين 2021 و2025. وفي Linear، اقترب حجم مجموعة الاختبارات من أربعة أمثال مستواه منذ يناير، فيما بات الوكلاء يكتبون معظم الاختبارات.

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

لماذا لم تعد سرعة CI كافية؟

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

المشكلة الثانية هي موضع التحقق. فالوكيل يكتب التغيير ثم ينتظر النتيجة بعد إنشاء طلب الدمج. وعندما تصل النتيجة بعد 20 دقيقة، قد يكون قد فقد سياق المهمة، فيما تعني كل مشكلة دورة انتظار جديدة.

المستودع ليس النظام

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

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

ويستشهد المقال ببيانات DevOps Research and Assessment (DORA)، التي تربط ارتفاع تبني الذكاء الاصطناعي بزيادة في وتيرة تسليم البرمجيات وبالاضطراب في التسليم معاً. أي أن إنتاج شيفرة أسرع لا يضمن تحققاً أفضل.

ما الذي يتغير عملياً؟

الحل المقترح ليس إلغاء CI أو إبطاء الوكلاء، بل نقل جزء من التحقق إلى وقت أبكر داخل حلقة عمل الوكيل، بحيث يختبر التغيير against النظام الفعلي لا نسخة المستودع وحدها. وتستخدم أدوات مثل Cursor بيئات سحابية معزولة؛ إذ تأتي أكثر من 30% من طلبات الدمج التي تدمجها Cursor من وكلاء يعملون بهذه الطريقة. كما توفر أدوات أخرى، منها GitHub Copilot cloud agent وCodex وDevin وGreptile، أشكالاً مختلفة من تشغيل الشيفرة داخل بيئات مؤقتة.

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

بيئات مشتركة وتحقق محكوم

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

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

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