الذكاء الاصطناعي يسرّع كتابة الكود لكن الإنتاجية لا ترتفع: ماذا تفسّر مقاييس DevEx

كان التوقع بسيطًا: مع مساعدات الذكاء الاصطناعي يُنتج المطور كودًا عالي الجودة بمقدار ثلاثة إلى أربعة أضعاف. أما عمليًا فبالكاد يلحظ أحد نموًا مضاعفًا في إنتاجية الفرق. فإحدى أكثر الدراسات استشهادًا، وهي تجربة METR العشوائية لعام 2025، أظهرت أن مطوري المصادر المفتوحة ذوي الخبرة أنجزوا المهام بمساعدة أدوات الذكاء الاصطناعي بوتيرة أبطأ بنسبة 19%، مع أنهم قدّروا بأنفسهم أن التسارع يبلغ نحو 20%. وقد نشر موقع «هابر» ترجمة لتحليل يقترح فيه كاتبه إضافة مقاييس DevEx إلى DORA وSPACE، لرصد ما تغفله الإحصاءات المعتادة. نعتمد في هذا العرض على إعلان المادة والأوصاف المعروفة عمومًا لهذه الأطر.

لماذا يصبح الكود أسرع بينما تبقى النتيجة كما هي

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

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

ثلاثة أطر للقياس

كل إطار ينظر إلى جزء مختلف من المنظومة:

• DORA: أربعة مؤشرات للتسليم: وتيرة النشر (deploy)، والوقت من الـcommit إلى بيئة الإنتاج، ونسبة التغييرات الفاشلة، ووقت التعافي بعد العطل. يعرض هذا الإطار نتيجة خط الإنتاج.
• SPACE: خمسة أبعاد: الرضا، والأداء، والنشاط، والتواصل والتعاون، والكفاءة والتدفق. ويحذّر هذا الإطار من أن الإنتاجية لا يمكن وصفها برقم واحد.
• DevEx: ثلاثة عوامل لتجربة المطور: سرعة التغذية الراجعة، والحمل المعرفي، وإمكانية الدخول في حالة التدفق. يُظهر هذا الإطار ما يعيق العمل.

وDevEx تحديدًا هو من يجيب عن سؤال: أين تذهب الدقائق التي جرى توفيرها؟ فبطء CI، وغموض البنية المعمارية، وتشتت التوثيق، وطابور الموافقات، كلها تلتهم مكسب الإكمال التلقائي، ولا ترصد DORA ذلك إلا بصورة غير مباشرة عبر زمن التسليم النهائي.

كيف يغيّر الذكاء الاصطناعي القياس نفسه

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

ماذا نقيس عمليًا

ينبغي البدء قبل التبنّي الواسع للمساعدات: فبلا نقطة مرجعية أولية لا يمكن فصل الأثر عن التقلبات الموسمية وتغيّر تركيبة الفريق. بعد ذلك من المنطقي مقارنة ثلاث طبقات من البيانات.

• أوقات الانتظار: طابور المراجعة، ومدة CI، وتأخر الموافقات.
• الجودة: نسبة التغييرات الفاشلة ووقت التعافي من DORA، كثقل موازن للسرعة.
• تجربة المطورين: استبيانات قصيرة ومنتظمة حول التدفق والحمل وجودة التغذية الراجعة.

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