من 7 سنوات إلى 7 أيام مع الذكاء الاصطناعي الوكيل

إذا سبق لك أن نظرت إلى جدول بيانات COCOMO II وشاهدته يتوقع 33 شهراً تقويمياً لمشروع أنجزه فريقك في دورتي عمل (سبرينت)، فأنت تعرف المشكلة مسبقاً: تمت معايرة كل نموذج تقدير قيد الاستخدام اليوم بناءً على عالم يكتب فيه المطورون كل سطر، ولتبديل السياق تكلفة، ويتوقف تقويم العمل عند الساعة الخامسة مساءً. لم يعد هذا العالم موجوداً. لقد طورنا مؤخراً تطبيقاً يتكون من 286 ألف سطر برمجي، و672 ملفاً، ومتعدد الأنظمة الفرعية من الصفر - طبقة البروتوكول، وطبقة البيانات، ومحرك العرض، وتكامل المنصة - ووصلنا إلى نسخة أولية جاهزة للاختبار في ٧ أيام. أعادت لوحة النموذج الكامل (COCOMO الأساسي/المتوسط/ما بعد الهندسة المعمارية، نقاط الوظائف، خط أساس SLOC، بوتنام/SLIM) متوسط توقعات لـ 30.3 شهر تقويمي. مضاعف الإنتاجية الوسيط: 4,240×. حتى أكثر خط الأساس تحفظاً (25 سطراً برمجياً لكل مطور-يوم للنظم المعقدة) كان غير دقيق بما يكفي لدرجة 1,433×.النماذج ليست خاطئة. بل هي مُساءة التطبيق. إليك التفصيل نموذجاً بنموذج، والمعايرة التجريبية للمؤلف نفسه، وما تقوله حقاً أدبيات التجارب عشوائية ذات الشاهد (RCT) لفترة 2024–2026 حول المكان الذي يضغط فيه الذكاء الاصطناعي الوكيل (الآيغنتيك) المدة الزمنية — والمكان الذي لا يفعل فيه ذلك.

المشروع الذي حطّم التقديرات

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

• ٢٨٦,٦٦٢ سطر من كود المصدر (حوالي 286 ألف سطر برمجي) موزعة على 672 ملف مصدر
• 1,329,399 خطاً من إجمالي معدل التراجع — 862,488 إدراج و 466,911 حذف
• 700 التزام انتهى 7 أيام تطور نشطة للوصول إلى أول نسخة ألفا جاهزة للاختبار
• تدويل كامل بعشرات اللغات المحلية
• أنظمة فرعية متعددة وغير مرتبطة تماماً ببعضها البعض — معالجة البروتوكولات، وإدارة البيانات، والتقديم، وتكامل المنصة — وكلها مبنية من الصفر للبيئة المستهدفة

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

ما توقعته نماذج التقدير مقابل ما حدث بالفعل

تُشغل الأداة كل نموذج تقدير رئيسي في أدبيات هندسة البرمجيات — نموذج كوكومو الأساسي (العضوي، شبه المترابط، المدمج)، ون نموذج كوكومو الوسيط (شه المترابط والمدمج، المُعدّل)، ونموذج كوكومو 2 لما بعد البنية (المُعدّل)، ونقاط الوظيفة، وخط إنتاجية أسطر التعليمات البرمجية (SLOC)، ونموذج بوتنام/سليم (Putnam/SLIM) — معايرةً وفقاً لنوع المشروع باستخدام الثوابت المنشورة من أدبيات المصدر الأصلي.

نموذج تقدير	الجهد المتوقع	التقويم المتوقع	التسريع مقابل الفعلي
COCOMO الأساسي (العضوي)	913 شهراً بشرياً	٣٣.٣ شهراً	2,282×
كوكومو الأساسي (شبه مستقل)	١,٦٩٦ رجل-شهر	٣٣.٧ شهراً	4,240×
كوكومو الأساسي (المضمّن)	3,200 شهر-شخص	33.1 شهراً	8,000×
COCOMO الوسيط (شبه مستقل، مضبوط)	1259 شهراً بشرياً	٣٠.٤ شهراً	3,148×
كوكومو الوسيط (مدمج، مُعدَّل)	2,376 شهراً عمل بشرياً	30.1 شهراً	5,940×
نموذج كوكومو 2 لما بعد الهندسة المعمارية (المعدل)	1,703 شهر-شخص	٣٠.٣ شهراً	4,257×
نقاط الوظيفة (تقدير تقريبي)	17.9 رجل-شهر	٧.٥ أشهر	45×
خط الأساس لإنتاجية سطر البرمجة (25 سطر برمجي / مطور-يوم)	٥٧٣ شهراً بشرياً	٥٧٣٫٣ شهرًا	1,433×
بوتنام/سليم	تم تخطيه (المدة < 30 يوماً؛ T4/3 ينفجر	—	—

ال مضاعف الإنتاجية الوسيط عبر جميع النماذج هو 4,240×. حتى أكثر النماذج تحفظاً يتوقع وقت تسليم تقريباً أطول بـ 1,400 مرة مما حدث بالفعل. حتى أكثرها تفاؤلاً، وهي نقاط الوظيفة، تنبأت بـ 7.5 أشهر تقويمية — أطول بـ 45 مرة من الأيام السبعة الفعلية. تقول النماذج إن هذا المشروع كان من المفترض أن يستغرق ما بين من 7 أشهر إلى 47 عاماً. كانت النسخة الأولية جاهزة للاختبار في غضون 7 أيام.

تختلف النماذج عن بعضها البعض — بنسبة تتراوح بين 50 إلى 8,000 ضعف

لا تتفق هذه النماذج مع بعضها البعض. على قاعدة الكود نفسها، تتراوح التنبؤات بين 17.9 و 3,200 شهر-شخص — وهو ما يمثل انتشار 178×. ووجدت معيار SEAA لعام 2013 لنظم COCOMO II و SEER-SEM و SLIM و TruePlanning عبر 51 مشروعاً حقيقياً أن متوسط خطأ المقدار المطلق (MMRE) يبلغ 50–100%. وجدت تقييمية لعام 2023 على مجموعة بيانات COCOMO NASA أن معدل الخطأ المطلق المتوسط (MMRE) يقترب من 1.0 و PRED(0.25) = 0.0 — لم يقع تقدير أي مشروع ضمن نطاق الخطأ 25%. لم تُصمم النماذج أبدًا لمشروع مدعوم بالذكاء الاصطناعي. لكن حجم الفجوة — حتى مع أخذ عدم دقة النموذج في الحسبان — يشير إلى أن هناك تغييرًا هيكليًّا قد حدث.

ما تقوله الأبحاث حقاً حول الذكاء الاصطناعي الوكيلي وإنتاجية المطورين

رقم 4,240× مبالغ فيه، ولا أريد المبالغة في تقديره. فالسقالات للمشاريع الجديدة تضخم معدل ترك العملاء، وخطوط التعليم البرمجية المصدرية (SLOC) مؤشر ضعيف للقيمة. لذا دعونا ننظر إلى الأدبيات التي تمت مراجعتها من قبل الزملاء. توفر المساعدات على غرار كوبايلوت مكاسب متواضعة وحقيقية. وجد بينغ وآخرون (2023) أن المطورين الذين استخدموا مساعد برمجة ذكي أكملوا مهمة أسرع بمقدار 55.8% (95% CI: 21–89%). أظهرت الدراسة العشوائية ذات المجموعات المتوازية التي أجرتها مايكروسوفت/أكسنتشر/فورتشن 100 (2025) — وهي أكبر دراسة حتى الآن، حيث بلغ عدد المشاركين فيها 4,867 — أن 26% زيادة في المهام المنجزة. أظهرت تجربة معشاة ذاتياً داخلية لشركة جوجل (2024) أن ~21% انخفاض في الوقت المستغرق في أداء المهمة. قاسَت تجربة ميدانية لم بنك التسويات الدولية/مجموعة أنت (٢٠٢٤) 55% زيادة في إنتاج الكود للموظفين المبتدئين. الخلاصة الصادقة: 1.26× إلى 1.56× في المهام المناسبة. حقيقي، ولكنه ليس تحويلياً. يعمل الذكاء الاصطناعي الوكيل في نطاق مختلف. أفادت مراجعة شركة كوجنيشن لعام 2025 الخاصة بـ ديفين بأن نتائج العملاء كانت عشرة أضعاف على ترحيل عمليات استخراج وتحويل وتحميل البيانات, 14 ضعف عمليات ترحيل إصدارات جافا, ، و عشرون ضعفاً على الإصلاحات الأمنية. أبلغت نوبانك تحسن في الكفاءة بمقدار 12 ضعفاً و توفير بمقدار 20 ضعفاً في التكاليف في عملية إعادة هيكلة بملايين الأسطر كانت مقدرة سابقاً بجهد يستغرق عدة سنوات وآلاف المهندسين. يقع نقلنا تماماً ضمن هذا النطاق - حيث يُظهر رسم بياني لعمليات الالتزام دفعات كثيفة في الساعات 22:00، و00:00، و01:00، وهي سمة الجلسات التي تقودها الوكلاء. الأدلة المعاكسة حقيقية. وجدت التجربة المعشاة ذات الشاهد لعام 2025 الصادرة عن منظمة Metr.org (والتي شملت 16 مطوراً ذوي خبرة و246 مهمة على مشاريع ناضجة) أن الذكاء الاصطناعي زيادة وقت الإنجاز بمقدار 19% - هو تباطأ المطورون ذوو الخبرة على قواعد أكواد مألوفة. وجدت دراسة فرق بين الفروق لعام 2026 شملت 807 مستودعات على غيت هاب تستخدم أدوات الذكاء الاصطناعي (He et al., MSR ’26) زيادة “عابرة” في السرعة وزيادة “دائمة” في تعقيد الكود والتي أدت إلى تباطؤ على المدى الطويل. العنوان يغني عن كل شيء: السرعة على حساب الجودة. الاجماع: يساعد الذكاء الاصطناعي كثيراً في المشاريع الجديدة والمبرمجة بشكل منظم، ويساعد بشكل متواضع في مهام الإنجاز، ويمكن أن يضر بسرعة العمل في قواعد البيانات البرمجية الناضجة. دَين الجودة أمر حقيقي.

لماذا تنكسر النماذج: ثلاثة تحولات هيكلية

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

المعايرة التجريبية لنفس المؤلف

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

مشروع	مرحلة ما قبل الذكاء الاصطناعي/يوم التطوير	معدل هجر العملاء/يوم المطورين في عصر الذكاء الاصطناعي	مضاعف
المشروع أ (موازن الحمل)	673	2,056	3.1×
المشروع ب (خدمة التقارير)	239	2,127	8.9×
المشروع C (خدمة المعالجة)	1,322	982	0.7×
تجميع (المتوسط / الوسيط)	—	—	4.2× / 3.1×

نفس المؤلف، نفس النطاق، أعمال صيانة حقيقية. المضروب التجريبي هو 3–9× — أكثر تحفظاً بكثير من رقم الـ 4,240× للمشاريع الجديدة، ومتسق مع الحد الأعلى لأبحاث الذكاء الاصطناعي الوكيلية المنشورة. أحد المشاريع حصل فعلياً على أبطأ — المكاسب تعتمد على المهمة وليست شاملة.

ما تعنيه هذه الخطوة لتخطيط المشروع

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

1. عاير وفقاً لتاريخك الخاص. قارن مخرجات شيفرتك الخاصة لكل شخص-يوم مع وجود الذكاء الاصطناعي وبدونه. فهو أرخص، وأكثر صدقاً، وينتج نطاقاً من 3 إلى 9 أضعاف يمكنك الدفاع عنه في خطة المشروع.
2. فصل المشاريع الجديدة عن أعمال الصيانة. مضاعف الذكاء الاصطناعي الوكيل يكون في أعلى مستوياته في المشاريع الجديدة والمطورة بنية تحتية منظمة، ويكون في أدنى مستوياته (وسلبياً في بعض الأحيان) في صيانة قواعد التعليمات البرمجية الناضجة. لا تقم بتطبيق رقم واحد على كليهما.
3. ميزانية للديون الجيدة. تترافق سرعة الذكاء الاصطناعي مع زيادة مستمرة في التعقيد. قم بالتخطيط لمرحلة تقوية واعمل على توثيقها ومراقبتها؛ تتبع تعقيد القيادة (cyclomatic complexity) وقم بتنفيذ عملية اكتشاف النسخ واللصق مع كل إطلاق.
4. قَدِّرِ المنحنى بأكمله، وليس مقدّمتَه فقط. إنّ تحقيق زيادة بمقدار 10 أضعاف في السرعة تؤدي إلى مضاعفة كثافة العيوب ليس مكسباً بمقدار 10 أضعاف، بل هو تقديم لموعد التسليم على حساب مرحلة استقرار أطول.

الخلاصة

مشروع تشير كل نماذج التقدير إلى أنه يجب أن يستغرق من 7 أشهر إلى 47 عاماً، وصل إلى نسخة أولية جاهزة للاختبار في غضون 7 أيام. إن مضاعف الوسيط البالغ 4,240 ضعفاً يجب ألا يصبح خطة مشروع لأي شخص. لكنه إشارة واضحة على أن المدة يتم إعادة ضغط تطوير البرمجيات المعقدة بواسطة نفس القوة التي تعيد ضغط جهد.تظهر الأبحاث المنشورة أن الذكاء الاصطناعي يقدم في أي مكان من دفعة ١.٢٦× إلى زيادة بمقدار 20 ضعفاً, مع وجود خطر حقيقي بـ عائدات سلبية على قواعداك البرمجية الناضجة وضريبة جودة قابلة للقياس. النماذج التي أخبرتنا أن هذا المشروع يجب أن يستغرق عقوداً هي نفس النماذج التي لا تزال تعمل في جداول تقديرات المؤسسات اليوم. السؤال ليس عما إذا كان الذكاء الاصطناعي الوكيلي يغير مدة المشروع — فقد أجابت الأبحاث على ذلك. السؤال هو ما إذا كانت ممارسات التقدير لديك قد واكبت الأدلة. إذا كانت أرقامك لا تزال تأتي من نموذج عام 1981 المعاير على لغة كوبر (COBOL) ولغة التجميع، فقد حان وقت إعادة معايرتها — أو على الأقل التوقف عن تصديق التقويم الذي تطبعه.

“لا يزال هناك مجال كبير للتحسين من أجل معالجة تحديات التنبؤ التي تواجه الممارسة بشكل أفضل.”