وكلاء الذكاء الاصطناعي: زيادة 98% في طلبات السحب، لكن المراجعة تأخرت 91%. أين انتقل الطابور

حلّل سيرغي بروششاييف، قائد تقني ورئيس قسم تطوير Java | Kotlin في مجال التكنولوجيا المالية والتجارة الإلكترونية، ثلاث دراسات كبرى من عامي 2025-2026، واكتشف حقيقة واحدة: الذكاء الاصطناعي سرّع كتابة الكود، لكنه أبطأ التسليم إلى بيئة الإنتاج.

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

سرّع الذكاء الاصطناعي عملية التوليد أسرع من قدرة الفريق على الفحص والدمج والتسليم. العنق الزجاجي لا يختفي، بل ينتقل فقط إلى مرحلة أخرى في خط الإنتاج.

ثلاث دراسات، نتيجة واحدة: التوليد رخيص، والفحص ليس كذلك

Faros AI: مفارقة إنتاجية الذكاء الاصطناعي (يوليو 2025) — بيانات شملت 10,000 مطور من 1,255 فريقًا. تبدو النتيجة إيجابية ظاهريًا: المطورون الذين يستخدمون مساعدات الذكاء الاصطناعي بفعالية يُغلقون 21% مهام إضافية، ويقدّمون 98% طلبات سحب أكثر. لكن تفصيلًا واحدًا يغيّر الصورة كاملة: زمن المراجعة ارتفع 91%، وحجم طلب السحب المتوسط ارتفع 154%، وعدد الأخطاء لكل مطور ارتفع 9%. وعلى مستوى الشركة، لم يجد الباحثون أي ارتباط ذي دلالة بالنتيجة الإجمالية.

Faros AI: فخ السرعة (18 سبتمبر 2026) — 22,000 مطور من 4,000 فريق خلال 12 شهرًا. ارتفع زمن المكوث في ضمان الجودة بنسبة 300.6% — وهو أسوأ تدهور بين جميع مقاييس التدفق. حجم طلب السحب المتوسط أعلى بنسبة 71.8%، وعدد الحوادث شهريًا ارتفع 125.4%. ومؤشر مثير للقلق: نسبة طلبات السحب المدمجة دون مراجعة ارتفعت من 31.3% إلى 76.3%.

CircleCI: تقرير تسليم البرمجيات 2026 — تحليل 28.7 مليون عملية تكامل مستمر (CI) في سبتمبر 2025. ارتفع المتوسط اليومي لعمليات التشغيل بنسبة 59% على أساس سنوي، لكن نشاط الفريق المتوسط على فروع الميزات نما 15%، بينما انخفض على main بنسبة 7%. انخفضت نسبة نجاح عمليات البناء على main إلى 70.8% (أدنى مستوى في خمس سنوات)، وبلغ زمن العودة إلى بناء ناجح 72 دقيقة. أقل من 5% من الفرق تمكّنت من زيادة التطوير والمرور عبر main في الوقت نفسه.

DORA 2025: في عام 2024، ترافقت زيادة استخدام الذكاء الاصطناعي بنسبة 25% مع انخفاض سرعة التسليم بنسبة 1.5% وانخفاض الاستقرار بنسبة 7.2%. وفي عام 2025 تغيّرت الصورة: أصبح الارتباط بين الذكاء الاصطناعي وسرعة التسليم ونتائج المنتج إيجابيًا، لكنه بقي سلبيًا مع الاستقرار. يصف المؤلفون الذكاء الاصطناعي بأنه «مرآة ومضخّم» — فهو يسرّع التطوير، لكن بدون أتمتة قوية للاختبارات، يتحول نمو حجم التغييرات إلى عدم استقرار.

أين تعثّر الطابور

تسير طلبات السحب بالتوازي مع التوليد والمراجعة البشرية، ثم تنتظر مراحل ضمان الجودة والدمج والنشر. يسرّع الوكيل عملية التوليد (الكتلة الخضراء)، لكن قدرة كل ما تبقى من المراحل لا تنمو بالمعدل نفسه.

عندما تصل التغييرات أسرع مما يستطيع النظام معالجته، يتضخم الطابور، ويتراكم العمل غير المكتمل، ويطول زمن التسليم. تتطوّر قدرة المراجعة وضمان الجودة والدمج بوتيرة أبطأ بكثير من سرعة توليد الكود.

الملاحظة الأولى: طلبات الدمج تكبر أسرع من قدرة المراجعة. لا يتعامل الوكيل مع حجم التغييرات كهدف تقني مستقل. يُطلب منه ميزة واحدة، فيُسلّم الميزة كاملة مع إعادة هيكلة للوحدات المجاورة «في الطريق». في أحد المشاريع، تضخّمت مهمة بسيطة لإضافة حقل واحد في استجابة خدمة إلى عدة مئات من السطور (في حين كانت المهمة المحددة 20 سطرًا فقط). توصي SmartBear بألا يتجاوز حجم المراجعة الواحدة 200-400 سطر، وبسرعة لا تتعدى 500 سطر في الساعة، وبجلسات مدتها نحو ساعة واحدة — وفي هذه الظروف يُكتشف 70-90% من العيوب.

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

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

الملاحظة الرابعة: الذكاء الاصطناعي يضيف قدرة للفحص لكنه لا يحلّ محل المسؤولية. تساعد المراجعة الآلية فعليًا بالفعل — فالمراجعة الأولى تصل أسرع، ونسبة التغييرات الفاشلة أقل. لكن مستوى الثقة لا يزال منخفضًا: في دراسة DORA 2025، عبّر 24% فقط عن ثقة عالية، في حين لا يثق 30% بالقدر الكافي أو لا يثقون على الإطلاق. وإذا كان الوكيل هو من كتب الكود وفحصه، واقتصر دور الإنسان على الضغط على زر، فلا توجد أي مراجعة مستقلة فعلية. والحل يكمن في تدرّج حسب المخاطر: التغييرات الآلية البسيطة تُترك بالكامل للأتمتة، أما التغييرات الحساسة (التفويض، الدفع، الأمان) فتحتاج إلى مراجعة معزّزة بمراجعين مستقلين اثنين.