لماذا يصبح المطورون المخضرمون أبطأ بنسبة 19% مع الذكاء الاصطناعي: المنحنى J للتبني

مقدمة

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

المفارقة: هؤلاء المطورون أنفسهم توقعوا أن يكونوا أسرع بنسبة 24% مع الذكاء الاصطناعي. آمنوا بأنهم أكثر إنتاجية بينما كانوا قابلين للقياس أقل إنتاجية. الفجوة بين التصور والواقع — 43 نقطة مئوية — ليست خطأً في التقريب. إنها سوء فهم منهجي لكيفية تفاعل أدوات الذكاء الاصطناعي مع سير العمل المرسّخة.

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

ما الذي قاسته دراسة METR فعلاً

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

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

النتيجة: استغرقت المهام المدعومة بالذكاء الاصطناعي وقتاً أطول بنسبة 19% في المتوسط. كان التأثير ذا دلالة إحصائية واستمر عبر أنواع مختلفة من المهام ومستويات خبرة المطورين.

بحث الباحثون في السبب. عدة عوامل تضافرت لخلق هذا التباطؤ:

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

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

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

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

تصحيح أخطاء دقيقة. الكود المولَّد الذي يبدو صحيحاً لكنه يحتوي على أخطاء منطقية خفية أصعب تصحيحاً من الكود الذي كتبه المطور بنفسه، لأن المطور لا يملك “الأثر الذهني” لتشييد المنطق خطوة بخطوة. إنه يصحح تفكير شخص آخر — باستثناء أن “الشخص الآخر” نموذج احتمالي لا يفكر بطرق يمكن للبشر تتبعها بسهولة.

يوفر استطلاع Stack Overflow للمطورين لعام 2025 سياقاً داعماً: فقط 29% من المطورين يثقون في دقة الكود المولَّد بالذكاء الاصطناعي، بانخفاض من 40% في عام 2024. و66% يشيرون إلى الإحباط ذاته: حلول الذكاء الاصطناعي “شبه صحيحة، لكن ليس تماماً.” كما وجد الاستطلاع أنه بينما يستخدم 84% من المطورين أو يخططون لاستخدام أدوات الذكاء الاصطناعي، انخفضت الاتجاهات الإيجابية من أكثر من 70% إلى ما يقارب 60%. الصناعة تتبنى الأدوات بينما تزداد شكوكاً حيالها.

المنحنى J للتبني

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

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

أدوات برمجة الذكاء الاصطناعي في المنحدر الأولي للمنحنى J لمعظم المؤسسات. جرى تبني الأدوات. سير العمل لم تتكيف. والانخفاض في الإنتاجية حقيقي وقابل للقياس ويُساء تفسيره.

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

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

مشكلة “المحرك الجديد، الناقل القديم”

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

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

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

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

يوفر إطار Ben Shapiro لمستويات نضج برمجة الذكاء الاصطناعي الخمسة إطاراً مفيداً هنا. معظم المؤسسات في المستوى الثاني (التكرار — الذكاء الاصطناعي يولد المسودات، البشر يصقلونها) مع سير عمل المستوى الأول (المصممة للكود المكتوب بشرياً). عدم التطابق بين قدرة الأداة وتصميم سير العمل هو المكان الذي يقطن فيه المنحنى J. المؤسسات التي تعيد تصميم سير عملها لتتناسب مع استخدام الأداة في المستوى الثاني أو الثالث ترى مكاسب في الإنتاجية. المؤسسات التي تحتفظ بسير عمل المستوى الأول بينما تستخدم أدوات المستوى الثاني ترى التباطؤ بنسبة 19%.

لماذا ينفصل التصور عن الواقع

قد تكون النتيجة الأكثر إثارة للقلق في دراسة METR هي فجوة التصور. آمن المطورون بأنهم أسرع بنسبة 24% بينما كانوا في الواقع أبطأ بنسبة 19%. هذه ليست ثقة زائدة معتدلة. إنها سوء إدراك منهجي.

عدة عوامل تفسر ذلك. تخلق أدوات الذكاء الاصطناعي شعوراً بالإنتاجية لا يتوافق مع المخرجات الفعلية. رؤية الكود يظهر على الشاشة بشكل أسرع يبدو منتجاً، حتى لو زاد الوقت الإجمالي للوصول إلى كود عامل. ضربة الدوبامين من مشاهدة الذكاء الاصطناعي يولد 50 سطراً من الكود في ثوانٍ حقيقية، حتى لو قُضيت الـ 15 دقيقة التالية في إيجاد الأخطاء الثلاثة الدقيقة في تلك الـ 50 سطراً وإصلاحها.

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

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

كيف تصعد المنحنى J

الاعتراف بالمنحنى J هو الخطوة الأولى. الخطوة الثانية هي إعادة تصميم سير العمل بشكل متعمد للتقدم إلى ما بعد الانخفاض. عدة نهج ملموسة تُسرّع الانتقال:

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

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

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

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

ابدأ بالمهام الصحيحة. تقدم أدوات الذكاء الاصطناعي أكبر قيمة على المهام المحددة جيداً والثقيلة في الكود النمطي ذات معايير القبول الواضحة. تقدم أقل قيمة على المهام المعقدة الثقيلة في السياق في قواعد الأكواد المألوفة — تماماً السيناريو الذي قاسته دراسة METR. البدء بتبني الذكاء الاصطناعي في المهام التي تتفوق فيها الأداة يبني الثقة والعادة قبل تطبيقه على المهام التي يكون فيها المنحنى J أشد.

المصادر والقراءات الإضافية

• دراسة METR: قياس تأثير نماذج الذكاء الاصطناعي في مطلع 2025 على إنتاجية مطوري المصدر المفتوح المخضرمين — دراسة عشوائية محكومة على 16 مطوراً مخضرماً تُظهر تباطؤاً بنسبة 19% مع أدوات الذكاء الاصطناعي، في مقابل توقع بتسارع بنسبة 24%.
• استطلاع Stack Overflow للمطورين 2025 — قسم الذكاء الاصطناعي — استطلاع صناعي يُظهر تبني 84% لأدوات الذكاء الاصطناعي، وانخفاض الثقة (ثقة بالدقة 29%)، وإحباط 66% من المخرجات “شبه الصحيحة”.
• إطار StrongDM لمستويات برمجة الذكاء الاصطناعي الخمسة — نموذج نضج Ben Shapiro لتبني برمجة الذكاء الاصطناعي، من الإكمال التلقائي إلى المصنع المظلم.
• دراسة إنتاجية GitHub Copilot (2023) — دراسة برعاية GitHub تُظهر إنجازاً أسرع بنسبة 55.8% مع Copilot، وإن كانت تقتصر على مهمة JavaScript محدودة مع مشاركين مُوظَّفين من Upwork.
• McKinsey: تحرير إنتاجية المطورين مع الذكاء الاصطناعي التوليدي — تحليل McKinsey يُظهر تسارعاً في توليد الكود بنسبة 35-45% لكن تحسناً أقل من 10% في المهام عالية التعقيد.
• Everett Rogers، انتشار الابتكارات (1962) — النظرية الأساسية في منحنيات تبني التقنية، بما في ذلك الانخفاض في الإنتاجية الذي يحدث خلال فترات انتقال سير العمل.