في هذا المقال
إن سبق لكم أن حدّقتم في جدول COCOMO II ورأيتموه يتوقع 33 شهرًا تقويميًا لمشروع أنجزه فريقكم في دورتي عمل، فأنتم تعرفون المشكلة مسبقًا: كل نموذج تقدير مستخدم اليوم جرت معايرته على عالم يكتب فيه المطورون كل سطر بأيديهم، ويُكلّف فيه التنقل بين المهام ثمنًا، ويتوقف فيه التقويم عند الخامسة مساءً. وهذا العالم لم يعد موجودًا. فقد طوّرنا مؤخرًا من الصفر تطبيقًا متعدد الأنظمة الفرعية يضم 286 ألف سطر من الشيفرة في 672 ملفًا، يشمل طبقة البروتوكول وطبقة البيانات ومحرك العرض والتكامل مع المنصات، وبلغنا نسخة ألفا جاهزة للاختبار في 7 أيام. وقد أعطت مجموعة النماذج الكاملة (COCOMO Basic وIntermediate وPost-Architecture، ونقاط الوظائف، وخط الأساس المبني على عدد الأسطر، وPutnam/SLIM) توقعًا وسيطًا قدره 30.3 شهرًا تقويميًا. أما مُضاعِف الإنتاجية الوسيط فبلغ 4,240×. وحتى خط الأساس الأكثر تحفظًا (25 سطرًا لكل مطور يوميًا للأنظمة المعقدة) أخطأ بمعامل 1,433×. النماذج ليست خاطئة، بل يُساء تطبيقها. وفيما يلي التحليل نموذجًا بنموذج، والمعايرة التجريبية لدى المؤلف نفسه، وما تقوله فعلًا أدبيات التجارب العشوائية المضبوطة للفترة من 2024 إلى 2026 عن المواضع التي يختصر فيها الذكاء الاصطناعي الوكيلي المدة، والمواضع التي لا يختصرها فيها.
المشروع الذي حطّم التقديرات
في RIADVICE، طوّرنا مؤخرًا تطبيقًا معقدًا وغنيًا بالميزات، من النوع الذي ينسّق عدة أنظمة فرعية عبر معمارية موزعة، في صورة بيئة أصلية متعددة المنصات تستهدف الأجهزة المحمولة وأجهزة سطح المكتب انطلاقًا من قاعدة شيفرة واحدة، استجابةً لمتطلبات سوق استدعت تنفيذًا جديدًا. وقاعدة الشيفرة تكشف حجم المشروع:
- 286,662 سطرًا من الشيفرة المصدرية (~286 ألف سطر) موزعة على 672 ملفًا مصدريًا
- 1,329,399 سطرًا من إجمالي التغييرات: 862,488 إضافة و466,911 حذفًا
- 700 إيداع على مدى 7 أيام تطوير فعلية للوصول إلى أول نسخة ألفا جاهزة للاختبار
- تعريب وتدويل كامل إلى عشرات اللغات والإعدادات المحلية
- عدة أنظمة فرعية لا رابط عميقًا بينها، من معالجة البروتوكولات وإدارة البيانات إلى العرض والتكامل مع المنصات، بُنيت كلها من الصفر للبيئة المستهدفة
لم يكن هذا غلافًا ولا مجرد تغيير سطحي في الواجهة، بل تنفيذًا أصليًا بُني من الأساس لتلبية متطلبات سوق عجزت الحلول القائمة عن الوفاء بها. وقبل كتابة أي سطر، ربطتُ بالمشروع أداة تحليل مخصصة تُشغّل المجموعة الكاملة من نماذج تقدير جهد البرمجيات المعتمدة في القطاع على قاعدة الشيفرة مع نموها. وكان الهدف صادقًا: قياس الفجوة بين ما تتوقعه النماذج الكلاسيكية وما يُنتجه فعلًا التسليم بمساعدة الذكاء الاصطناعي. والنتائج ليست هامش خطأ، بل قطيعة من نوع آخر.
ما توقعته نماذج التقدير مقارنةً بما حدث فعلًا
تُشغّل الأداة كل نموذج تقدير رئيسي في أدبيات هندسة البرمجيات، وهي COCOMO Basic (Organic وSemi-Detached وEmbedded) وCOCOMO Intermediate (Semi-Detached وEmbedded، بعد الضبط) وCOCOMO II Post-Architecture (بعد الضبط) ونقاط الوظائف وخط أساس الإنتاجية المبني على عدد الأسطر وPutnam/SLIM، مع معايرتها وفق نوع المشروع باستخدام الثوابت المنشورة في المصادر الأصلية.
| نموذج التقدير | الجهد المتوقع | المدة التقويمية المتوقعة | التسريع مقارنةً بالواقع |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 شخص-شهر | 33.3 شهرًا | 2,282× |
| COCOMO Basic (Semi-Detached) | 1,696 شخص-شهر | 33.7 شهرًا | 4,240× |
| COCOMO Basic (Embedded) | 3,200 شخص-شهر | 33.1 شهرًا | 8,000× |
| COCOMO Intermediate (Semi-Det.، بعد الضبط) | 1,259 شخص-شهر | 30.4 شهرًا | 3,148× |
| COCOMO Intermediate (Embedded، بعد الضبط) | 2,376 شخص-شهر | 30.1 شهرًا | 5,940× |
| COCOMO II Post-Architecture (بعد الضبط) | 1,703 شخص-شهر | 30.3 شهرًا | 4,257× |
| نقاط الوظائف (تقدير تقريبي) | 17.9 شخص-شهر | 7.5 أشهر | 45× |
| خط أساس الإنتاجية (25 سطرًا لكل مطور يوميًا) | 573 شخص-شهر | 573.3 شهرًا | 1,433× |
| Putnam/SLIM | تم تخطيه (المدة أقل من 30 يومًا، والحد T 4/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× رقم متطرف، ولا أريد المبالغة فيه. فبناء الهياكل الأولية في المشاريع الجديدة يضخّم حجم التغييرات، وعدد الأسطر مؤشر ضعيف على القيمة. لذا لننظر في الأدبيات المحكّمة. المساعدات من نوع Copilot تحقق مكاسب متواضعة لكنها حقيقية. فقد وجد Peng وزملاؤه (2023) أن المطورين الذين استخدموا مبرمجًا مرافقًا بالذكاء الاصطناعي أنجزوا مهمة أسرع بنسبة 55.8% (فاصل ثقة 95%: من 21 إلى 89%). ووجدت التجربة العشوائية المضبوطة لـ Microsoft وAccenture وإحدى شركات Fortune 100 (2025)، وهي أكبر دراسة حتى الآن بعينة قوامها 4,867، زيادة بنسبة 26% في المهام المنجزة. ووجدت التجربة الداخلية لـ Google (2024) انخفاضًا بنحو 21% في الوقت المستغرق في المهمة. وقاست التجربة الميدانية لـ BIS وAnt Group (2024) زيادة بنسبة 55% في إنتاج الشيفرة لدى الموظفين المبتدئين. والخلاصة الصادقة: من 1.26× إلى 1.56× في المهام المناسبة. مكاسب حقيقية، لكنها ليست تحوّلية. أما الذكاء الاصطناعي الوكيلي فيعمل في نطاق مختلف. فقد أفادت مراجعة Cognition لعام 2025 بشأن Devin بنتائج لدى العملاء بلغت 10× في ترحيلات ETL، و14× في ترحيلات إصدارات Java، و20× في الإصلاحات الأمنية. وأفاد Nubank بتحسّن في الكفاءة بمعامل 12× ووفورات في التكلفة بمعامل 20× في إعادة هيكلة شملت ملايين الأسطر، كانت تُقدَّر سابقًا بجهد يمتد سنوات ويتطلب ألف مهندس. ويقع مشروعنا في صميم هذا النطاق، إذ يُظهر المدرج التكراري للإيداعات دفعات كثيفة عند الساعة 22:00 و00:00 و01:00، وهي البصمة المميزة للجلسات التي يقودها الوكلاء. غير أن الأدلة المعاكسة حقيقية. فقد وجدت التجربة العشوائية المضبوطة لـ Metr.org عام 2025 (16 مطورًا متمرسًا، و246 مهمة على مشاريع ناضجة) أن الذكاء الاصطناعي زاد وقت الإنجاز بنسبة 19%، أي أنه أبطأ المطورين المتمرسين على قواعد شيفرة مألوفة لديهم. ووجدت دراسة بأسلوب الفروق في الفروق أُجريت عام 2026 على 807 مستودعات في GitHub اعتمدت أدوات الذكاء الاصطناعي (He وزملاؤه، MSR ’26) دفعة «عابرة» في السرعة وزيادة «مستمرة» في تعقيد الشيفرة أدّت إلى تباطؤ على المدى الطويل. والعنوان يقول كل شيء: Speed at the Cost of Quality. والإجماع هو: الذكاء الاصطناعي يساعد كثيرًا في المشاريع الجديدة والتطوير المنظم، ويساعد بقدر متواضع في مهام الإكمال، وقد يضر بالسرعة في قواعد الشيفرة الناضجة. ودَين الجودة حقيقي.
لماذا تنهار النماذج: ثلاثة تحولات بنيوية
لا يتضمن أي من محركات التكلفة في النماذج الكلاسيكية إعدادًا لحالة «المطور لديه وكيل مستقل لا ينام ويستوعب قاعدة الشيفرة كاملةً في سياقه». وثلاثة تحولات تُطيح بمنحنى المدة:
- اختفى اختناق الكتابة.
تفترض النماذج أن جزءًا كبيرًا من الجهد عمل آلي: الشيفرة النمطية، والهياكل الأولية، وإعادة الهيكلة المتكررة، وموارد التعريب، وغيرها من البيانات المنظمة. وفي هذا المشروع، يتألف جزء كبير من الحجم من نصوص وتوصيلات منتظمة إلى حد بعيد يستطيع الوكيل توليدها أو تحويلها دفعةً واحدة. أما الشيفرة المكتوبة يدويًا نفسها، من هياكل أولية ودوال بناء وشيفرة ربط بالمنصات، فباتت تُولَّد على دفعات بدلًا من كتابتها سطرًا بسطر.
- تكلفة التنقل بين السياقات تتهاوى.
الإنسان الذي يتنقل بين طبقة البروتوكول وطبقة البيانات ومحرك العرض يدفع ضريبة تحميل السياق في كل مرة. أما الوكيل الذي قرأ المستودع كاملًا بملفاته الـ 672 فيدفعها مرة واحدة. ويتراكم هذا التفاوت بسرعة في قاعدة شيفرة بهذا الحجم.
- لم يعد التقويم هو الاختناق.
تحوّل النماذج الأشهر البشرية إلى أشهر تقويمية عبر معادلة توظيف تفترض يوم عمل بشريًا. أما جلسات الوكلاء فتستمر طوال الليل. ويُظهر المدرج التكراري للإيداعات إنتاجًا متواصلًا من الساعة 07:00 حتى 01:00، أي 18 ساعة نشطة لا 8.
المعايرة التجريبية لدى المؤلف نفسه
لأن النماذج البارامترية تختلف فيما بينها بمراتب عشرية، أجريتُ أيضًا معايرة تجريبية عبر المشاريع قارنتُ فيها حجم تغييرات الشيفرة التي أنتجتها لكل يوم عمل قبل اعتماد أداة ذكاء اصطناعي وكيلي وبعده، على ثلاثة مستودعات إنتاجية أخرى في المنظومة نفسها:
| المشروع | التغييرات لكل يوم عمل قبل الذكاء الاصطناعي | التغييرات لكل يوم عمل في عصر الذكاء الاصطناعي | المُضاعِف |
|---|---|---|---|
| المشروع A (موازن أحمال) | 673 | 2,056 | 3.1× |
| المشروع B (خدمة تقارير) | 239 | 2,127 | 8.9× |
| المشروع C (خدمة معالجة) | 1,322 | 982 | 0.7× |
| الإجمالي (المتوسط / الوسيط) | لا ينطبق | لا ينطبق | 4.2× / 3.1× |
المؤلف نفسه، والمجال نفسه، وعمل صيانة حقيقي. ويتراوح المُضاعِف التجريبي بين 3× و9×، وهو أكثر تحفظًا بكثير من رقم 4,240× المسجّل في مشروع جديد، ويتسق مع الحد الأعلى لما نشرته الأبحاث عن الذكاء الاصطناعي الوكيلي. بل إن أحد المشاريع أصبح أبطأ فعلًا، فالمكاسب تتوقف على طبيعة المهمة وليست عامة.
ما يعنيه ذلك لتخطيط المشاريع
إن كنتم لا تزالون تقدّرون مشاريع البرمجيات بنماذج غير معايَرة وبخط أساس قدره 25 سطرًا يوميًا، فستخطئون بما يتراوح بين مرتبة عشرية وثلاث مراتب في الأعمال المنجزة بمساعدة الذكاء الاصطناعي. وإليكم ما نفعله في RIADVICE:
- عايِروا وفق تاريخكم الخاص. قارنوا إنتاجكم من الشيفرة لكل يوم عمل مع الذكاء الاصطناعي ومن دونه. فذلك أقل تكلفة وأكثر صدقًا، ويعطيكم نطاقًا يتراوح بين 3× و9× يمكنكم الدفاع عنه في خطة المشروع.
- افصلوا المشاريع الجديدة عن الصيانة. يبلغ مُضاعِف الذكاء الاصطناعي الوكيلي أقصاه في المشاريع الجديدة والتطوير المنظم، وأدناه (وقد يكون سلبيًا أحيانًا) في صيانة قواعد الشيفرة الناضجة. فلا تطبّقوا رقمًا واحدًا على الحالتين.
- خصّصوا ميزانية لدَين الجودة. تأتي سرعة الذكاء الاصطناعي مصحوبة بزيادات مستمرة في التعقيد. فخطّطوا لمرحلة تحصين وزوّدوها بأدوات القياس: تتبّعوا التعقيد الدوري (cyclomatic complexity) وشغّلوا كشف الشيفرة المنسوخة في كل إصدار.
- قدّروا المنحنى كاملًا لا بدايته فقط. فمكسب سرعة بمعامل 10× يضاعف كثافة العيوب لديكم ليس مكسبًا بمعامل 10×، بل جدول زمني مُقدَّم على حساب ذيل استقرار أطول.
الخلاصة
مشروع تقول كل نماذج التقدير إنه كان يجب أن يستغرق ما بين 7 أشهر و47 عامًا بلغ نسخة ألفا جاهزة للاختبار في 7 أيام. ولا ينبغي أن يصبح المُضاعِف الوسيط 4,240× خطة مشروع لأحد. لكنه إشارة واضحة إلى أن مدة تطوير البرمجيات المعقدة تُضغط من جديد بفعل القوة ذاتها التي تضغط الجهد. وتُظهر الأبحاث المنشورة أن الذكاء الاصطناعي يحقق ما بين دفعة بمعامل 1.26× وقفزة بمعامل 20×، مع خطر حقيقي لعوائد سلبية في قواعد الشيفرة الناضجة وضريبة جودة قابلة للقياس. والنماذج التي أخبرتنا أن هذا المشروع يحتاج إلى عقود هي ذاتها التي لا تزال تعمل اليوم في جداول التقدير لدى المؤسسات. والسؤال ليس ما إذا كان الذكاء الاصطناعي الوكيلي يغيّر مدة المشاريع، فقد أجابت الأبحاث عن ذلك. بل السؤال هو ما إذا كانت ممارساتكم في التقدير قد واكبت الأدلة. فإن كانت أرقامكم لا تزال تأتي من نموذج يعود إلى عام 1981 جرت معايرته على COBOL ولغة التجميع، فقد حان وقت إعادة المعايرة، أو على الأقل التوقف عن تصديق التقويم الذي يطبعه.
«لا يزال هناك مجال كبير للتحسين من أجل التصدي على نحو أفضل لتحديات التنبؤ التي تُواجَه في الممارسة العملية.»
Accuracy of Contemporary Parametric Software Estimation Models، SEAA 2013
🏆 خبرة هندسية وسحابية موثوقة
RIADVICE: شريككم الموثوق في هندسة البرمجيات
نصمّم أنظمة برمجية معقدة ونبنيها وننشرها، بالانضباط الهندسي والأدوات اللازمة للتسليم في عصر الذكاء الاصطناعي: في الموعد، وضمن الميزانية، وبالجودة المطلوبة.
📚 المصادر وقراءات إضافية
يستند هذا المقال إلى أبحاث محكّمة وتجارب عشوائية مضبوطة وتقارير ميدانية من القطاع حول إنتاجية تطوير البرمجيات بمساعدة الذكاء الاصطناعي وتقدير جهد البرمجيات:
- دراسات إنتاجية الذكاء الاصطناعي (تجارب عشوائية مضبوطة وتجارب ميدانية)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot، arXiv:2302.06590: انخفاض بنسبة 55.8% في وقت إنجاز المهمة
- Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers Microsoft Research: عينة قوامها 4,867، و+26.08% في المهام المنجزة
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial، arXiv:2410.12944: تجربة Google العشوائية المضبوطة، عينة قوامها 96، وانخفاض بنحو 21% في الوقت المستغرق في المهمة
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: تجربة عشوائية مضبوطة، عينة قوامها 16، و246 مهمة، والذكاء الاصطناعي زاد وقت الإنجاز بنسبة 19%
- He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects، arXiv:2511.04427: دراسة بأسلوب الفروق في الفروق على 807 مستودعات في GitHub، MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks دراسة تكرارية خلصت إلى +13% (غير دالة إحصائيًا)
- تقارير القطاع حول الذكاء الاصطناعي الوكيلي
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× في ترحيلات ETL، و14× في ترحيلات Java، و20× في الإصلاحات الأمنية
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× في ساعات العمل الهندسي، و20× في وفورات التكلفة في إعادة هيكلة شملت ملايين الأسطر
- BIS / Ant Group (2024). تجربة ميدانية: +55% في إنتاج الشيفرة، تركّزت لدى الموظفين المبتدئين
- تقدير جهد البرمجيات: الأسس والدقة
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: نموذج COCOMO الأصلي
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: معايَر على 161 مشروعًا
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II وSEER-SEM وSLIM وTruePlanning على 51 مشروعًا، وMMRE بين 50 و100%
- Kemerer, C. F. (1993). An empirical validation of software cost estimation models، Communications of the ACM
- Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibration معايرة قائمة على النوافذ الزمنية عبر 341 + 93 مشروعًا
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort Estimation MMRE ~1.0، وPRED(0.25) = 0.0
- Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE: نموذج Putnam/SLIM
⚡ RIADVICE.com تقدّم هندسة موثوقة وخبرة سحابية وحلولًا برمجية بمستوى المؤسسات: في الموعد، وضمن الميزانية، وبالجودة المطلوبة.
