Faros AI: وكلاء AI رفعوا عدد pull request بنسبة 98%، لكن المراجعة صارت أطول بنسبة 91%

تكتب الفرق التي تستخدم وكلاء AI الكود بسرعة أكبر، لكنه لا يصل إلى main أسرع، بل يصل أحيانًا أبطأ. حلل موقع Habr هذه المفارقة استنادًا إلى بيانات Faros AI وCircleCI وDORA. أكثر رقم يُقتبس من تقرير Faros AI، المبني على قياسات تليمترية لأكثر من 10 آلاف مطوّر: لدى من يستخدمون AI بنشاط عدد مهام مغلقة أكبر بنسبة 21%، وعدد pull request مدموجة أكبر بنسبة 98%. وفي الوقت نفسه ارتفع زمن المراجعة بنسبة 91%.

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

أين يتعثر الكود

المشكلة ليست في عدد الـ PR، بل في حجمها. وبحسب بيانات Faros AI، ازداد متوسط حجم pull request لدى الفرق ذات المستوى العالي من AI-adoption بنحو 154%. يميل الوكيل إلى إجراء إعادة هيكلة كبيرة، ويضيف اختبارات، ويعدّل وحدات مجاورة. وعلى المراجع أن يحتفظ في ذهنه بسياق أوسع، ومراجعة diff من 800 سطر بتمعّن لا تستغرق الوقت نفسه الذي تستغرقه مراجعة diff من 300 سطر.

نقطة الخسارة الثانية في QA. فقد سجّلت Faros AI ارتفاعًا في عدد الأخطاء لكل مطوّر بنحو 9%. وكل عيب إضافي يعيد المهمة إلى الدورة: تعليقات، وتعديلات، وإعادة تشغيل CI، ومراجعة جديدة. يرتفع مقياس «المهام المغلقة»، بينما يبقى lead time حتى production ثابتًا أو يزداد.

وتعرض بيانات DORA الصورة نفسها من زاوية أخرى. ففي تقرير 2024 ارتبط ارتفاع AI-adoption بنسبة 25% بانخفاض في معدل إنجاز التسليم بنسبة 1,5% وتراجع في الاستقرار بنسبة 7,2%. ووصفت DORA لاحقًا AI بأنه مضخِّم: يسرّع العمليات الجيدة ويكشف ضعف العمليات الضعيفة. أما CircleCI فتنظر إلى المشكلة من خلال خطوط CI، حيث يظهر أين تتراكم عمليات البناء الفاشلة والتشغيلات الطويلة، أي أين تصطدم سرعة الكتابة بسرعة التحقق.

المقاييس التي ينبغي متابعتها

لا تكفي إحصاءات الـ commits وحدها لتحديد عنق الزجاجة. المطلوب صورة شاملة من أول commit حتى النشر:

• الزمن حتى أول مراجعة: كم تنتظر الـ PR قبل أن ينظر فيها أحد أصلًا.
• زمن المراجعة الكلي: من فتح الـ PR حتى approve.
• حجم الـ PR بالأسطر والملفات، إضافة إلى الوسيط والمئين التسعين.
• نسبة الـ PR التي عادت للتعديل بعد المراجعة أو QA.
• Change failure rate وزمن التعافي بعد الحوادث.
• Lead time for changes: من commit حتى production.

إذا ارتفع المقياسان الأولان مع ارتفاع عدد الـ PR، فالمشكلة في المراجعة. وإذا ارتفعت نسبة الإرجاع وchange failure rate، فالمشكلة في جودة الكود المولَّد نفسه والاختبارات.

ماذا تفعل الفرق

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

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

ثالثًا: إعادة النظر في مقاييس الإنتاجية. عدد الـ PR والمهام المغلقة لكل شخص بالكاد يقول شيئًا في عصر الوكلاء. أكثر دلالة هما lead time واستقرار الإصدارات، أي المقاييس التي تعتمدها DORA منذ سنوات طويلة.

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