لقد تم قصفنا بادعاءات حول مدى تأثير الذكاء الاصطناعي التوليدي على تحسين إنتاجية مطوري البرامج: فهو يحول المبرمجين العاديين إلى مبرمجين 10x، ومبرمجي 10x إلى 100x. وحتى في الآونة الأخيرة، تعرضنا (بشكل أقل إلى حد ما، ولكن لا يزال) للقصف بالجانب الآخر من القصة: حيث تشير تقارير METR إلى أنه على الرغم من اعتقاد مطوري البرمجيات بأن إنتاجيتهم قد زادت، فقد انخفض إجمالي الإنتاجية الشاملة بمساعدة الذكاء الاصطناعي. لقد رأينا أيضًا تلميحات لذلك في تقرير DORA العام الماضي، والذي أظهر أن إيقاع الإصدار تباطأ بالفعل قليلاً عندما ظهر الذكاء الاصطناعي في الصورة. ويعكس تقرير هذا العام هذا الاتجاه.
أريد أن أتخلص من بعض الافتراضات أولاً:
- أنا لا أؤمن بمبرمجي 10x. لقد عرفت أشخاصًا اعتقدوا أنهم مبرمجون 10x، لكن مهارتهم الأساسية كانت إقناع أعضاء الفريق الآخرين بأن بقية الفريق مسؤولون عن أخطائهم. 2x، 3x؟ هذا حقيقي. نحن لسنا جميعًا متشابهين، ومهاراتنا تختلف. لكن 10x؟ لا.
- هناك الكثير من المشاكل المنهجية في تقرير METR، وقد تمت مناقشتها على نطاق واسع. لا أعتقد أن هذا يعني أنه يمكننا تجاهل نتائجهم؛ من الصعب جدًا قياس الإنتاجية الشاملة لمنتج برمجي.
كما كتبت (وغيري الكثير)، فإن كتابة التعليمات البرمجية في الواقع تمثل حوالي 20٪ فقط من وظيفة مطور البرامج. لذا، إذا قمت بتحسين ذلك بشكل كامل – كود آمن مثالي، لأول مرة – فلن تحقق سوى 20٪ من السرعة. (نعم، أعلم أنه من غير الواضح ما إذا كان “تصحيح الأخطاء” مدرجًا في نسبة الـ 20% هذه أم لا. إن حذفه هو هراء – ولكن إذا افترضت أن تصحيح الأخطاء يضيف 10% إلى 20% أخرى وأدركت أن ذلك يولد الكثير من الأخطاء الخاصة به، فسوف تعود إلى نفس المكان.) هذه نتيجة لقانون أمدال، إذا كنت تريد اسمًا فاخرًا، ولكنها في الحقيقة مجرد عملية حسابية بسيطة.
يصبح قانون أمدال أكثر إثارة للاهتمام إذا نظرت إلى الجانب الآخر من الأداء. لقد عملت في شركة ناشئة للحوسبة عالية الأداء في أواخر الثمانينيات، وقد فعلت هذا بالضبط: حاولت تحسين 80% من البرنامج الذي لم يكن من السهل توجيهه. وبينما فشل كمبيوتر Multiflow في عام 1990، كانت بنية كلمات التعليمات الطويلة جدًا (VLIW) الخاصة بنا هي الأساس للعديد من الرقائق عالية الأداء التي جاءت بعد ذلك: الرقائق التي يمكنها تنفيذ العديد من التعليمات في كل دورة، مع تدفقات التنفيذ المعاد ترتيبها والتنبؤ بالتفرع (التنفيذ التأملي) للمسارات شائعة الاستخدام.
أريد تطبيق نفس النوع من التفكير على تطوير البرمجيات في عصر الذكاء الاصطناعي. ويبدو أن توليد الأكواد البرمجية هو بمثابة ثمرة قريبة، على الرغم من ارتفاع أصوات المتشككين في الذكاء الاصطناعي. ولكن ماذا عن الـ 80% الأخرى؟ ما الذي يمكن أن يفعله الذكاء الاصطناعي لتحسين بقية المهمة؟ وهنا تكمن الفرصة حقًا.
حديث أنجي جونز في AI Codecon: Coding for the Agentic World يأخذ هذا النهج بالضبط. تلاحظ أنجي أن إنشاء التعليمات البرمجية لا يغير مدى سرعة الشحن لأنه يأخذ جزءًا واحدًا فقط من دورة حياة تطوير البرامج (SDLC)، وليس كلها. تتضمن “الـ 80٪ الأخرى” كتابة الوثائق والتعامل مع طلبات السحب (PRs) وخط أنابيب التكامل المستمر (CI). بالإضافة إلى ذلك، أدركت أن إنشاء التعليمات البرمجية هو مهمة شخص واحد (ربما شخصين، إذا كنت مقترنًا)؛ البرمجة هي في الأساس عمل فردي. يتطلب الحصول على الذكاء الاصطناعي لمساعدة بقية أعضاء SDLC إشراك بقية الفريق. وفي هذا السياق، ذكرت قاعدة 1/9/90: 1% هم القادة الذين سيجربون الذكاء الاصطناعي بقوة ويبنون أدوات جديدة؛ 9% من المتبنين الأوائل؛ و90% منهم “انتظر وانظر”. إذا كان الذكاء الاصطناعي سيعمل على تسريع الإصدارات، فسوف يحتاج 90٪ إلى اعتماده؛ إذا كانت النسبة 1% فقط، فستتم إدارة العلاقات العامة هنا وهناك بشكل أسرع، ولكن لن تكون هناك تغييرات جوهرية.
تتخذ أنجي الخطوة التالية: تقضي بقية الحديث في التطرق إلى بعض الأدوات التي صممتها هي وفريقها لإخراج الذكاء الاصطناعي من بيئة التطوير المتكاملة (IDE) وإدخاله في بقية العملية. لن أفسد حديثها، لكنها تناقش ثلاث مراحل للاستعداد للذكاء الاصطناعي:
- فضولي للذكاء الاصطناعي: الوكيل قابل للاكتشاف، ويمكنه الإجابة على الأسئلة، ولكن لا يمكنه تعديل أي شيء.
- جاهز للذكاء الاصطناعي: لقد بدأ الذكاء الاصطناعي في تقديم المساهمات، لكنها مجرد اقتراحات.
- الذكاء الاصطناعي مضمن: تم توصيل الذكاء الاصطناعي بالكامل بالنظام، وهو عضو آخر في الفريق.
يتيح هذا التقدم لأعضاء الفريق التحقق من الذكاء الاصطناعي وبناء الثقة تدريجيًا، حيث يقوم مطورو الذكاء الاصطناعي أنفسهم ببناء الثقة فيما يمكنهم السماح للذكاء الاصطناعي بالقيام به.
هل تأخذنا أفكار إنجي إلى كل هذا الطريق؟ هل هذا ما نحتاجه لنرى زيادات كبيرة في سرعة الشحن؟ إنها بداية جيدة جدًا، ولكن هناك مشكلة أخرى أكبر. الشركة ليست مجرد مجموعة من فرق تطوير البرمجيات. ويشمل المبيعات والتسويق والتمويل والتصنيع وبقية تكنولوجيا المعلومات وغير ذلك الكثير. هناك قول مأثور مفاده أنه لا يمكنك التحرك بشكل أسرع من الشركة. قم بتسريع وظيفة واحدة، مثل تطوير البرامج، دون تسريع المهام الأخرى، ولن تنجز الكثير. المنتج الذي ليس تسويقه جاهزًا للبيع أو الذي لم تفهمه مجموعة المبيعات بعد لا يساعد.
هذا هو السؤال التالي الذي علينا الإجابة عليه. لم نقم بعد بتسريع عملية تطوير البرمجيات الشاملة، ولكننا نستطيع ذلك. هل يمكننا تسريع بقية الشركة؟ ادعى تقرير METR أن 95% من منتجات الذكاء الاصطناعي فشلت. وافترضوا أن ذلك يرجع جزئيًا إلى أن معظم المشاريع استهدفت خدمة العملاء، لكن العمل المكتبي الخلفي كان أكثر قابلية للذكاء الاصطناعي في شكله الحالي. هذا صحيح، ولكن لا تزال هناك مسألة “الباقي”. هل من المنطقي استخدام الذكاء الاصطناعي لإنشاء خطط عمل، وإدارة تغيير العرض، وما شابه ذلك إذا كان كل ما سيفعله هو الكشف عن عنق الزجاجة التالي؟
بالطبع يفعل. قد تكون هذه هي أفضل طريقة لمعرفة مكان الاختناقات: في الممارسة العملية، عندما تصبح اختناقات. هناك سبب جعل دونالد كنوث يقول إن التحسين المبكر هو أصل كل الشرور، وهذا لا ينطبق فقط على تطوير البرمجيات. إذا أردنا حقًا رؤية تحسينات في الإنتاجية من خلال الذكاء الاصطناعي، فعلينا أن ننظر إلى جميع أنحاء الشركة.