يؤدي ترميز الذكاء الاصطناعي إلى خلق عنق الزجاجة الجديد للبرامج

تعمل البرمجة المدعومة بالذكاء الاصطناعي على تسريع عملية تطوير البرمجيات بسرعة كافية بحيث يتعين على المؤسسات إعادة التفكير في كيفية مواكبة التعليمات البرمجية التي تنتجها – وهو تحدٍ يستحق الآن ثروة.
وقد اجتذبت شركتان تهدفان إلى حل هذه المشكلة مئات الملايين من الدولارات من المستثمرين هذا الأسبوع. وصلت قيمة شركة CodeRabbit لمراجعة أكواد الذكاء الاصطناعي إلى 1.5 مليار دولار بعد جولة التمويل الأخيرة، في حين جمعت منصة اختبار البرمجيات Blacksmith 45 مليون دولار بتقييم يقترب من 550 مليون دولار. تتعامل الشركات مع أجزاء مختلفة من دورة حياة تطوير البرمجياتلكن ظهورهما المتزامن يشير إلى نفس التحول: الذكاء الاصطناعي يساعد المؤسسات على إنتاج التعليمات البرمجية بشكل أسرع مما يستطيع الكثيرون تقييمه بثقة.
وهذا يعكس القيد المألوف في تطوير البرمجيات. لسنوات، ركزت المنظمات الهندسية على جعل المطورين أكثر إنتاجية وتقليل الوقت اللازم لكتابة التعليمات البرمجية وشحنها. الآن، العامل المحدد بشكل متزايد هو ما يحدث بعد إنتاج الكود.
قال ريتشارد سايمون، مدير التكنولوجيا للخدمات السحابية الاحترافية في T-Systems International: “لقد قام الذكاء الاصطناعي بأمرين: زيادة معدل إنشاء التعليمات البرمجية، ولكنه كشف أيضًا عن عنق الزجاجة المتمثل في فحص هذا الرمز والتحقق من صحته وتعقيمه”. “نحن نبتعد عن كون المطورين هم عنق الزجاجة في اختبار يجري عنق الزجاجة“.
بالنسبة لقادة تكنولوجيا المعلومات في المؤسسات، يطرح التغيير سؤالًا أكثر جوهرية من ما إذا كان يجب الاستثمار في أداة اختبار أخرى: هل يمكن تسريع بقية دورة حياة تطوير البرامج بنفس معدل التعليمات البرمجية المولدة بواسطة الذكاء الاصطناعي؟
يخلق الكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي مشكلة في السياق
إحدى نتائج تطوير البرمجيات المدعومة بالذكاء الاصطناعي هي أن المهندسين ليس لديهم نفس السياق للتعليمات البرمجية التي ينشئها الذكاء الاصطناعي والتي قد تكون لديهم للتعليمات البرمجية التي كتبوها بأنفسهم.
وقال تومي تران، مهندس برمجيات في شركة ميتا المتخصصة في الذكاء الاصطناعي والبنية التحتية للتعلم الآلي، إن المهندسين يفهمون عادة القرارات التي تكمن وراء الكود الخاص بهم لأنهم عملوا على حل المشكلة بأنفسهم. مع التعليمات البرمجية التي تم إنشاؤها بواسطة الذكاء الاصطناعي، فإن هذا المنطق مفقود، حتى عندما يبدو التنفيذ الناتج سليمًا.
وهذا يجعل التحقق من الصحة أكثر تعقيدًا من مجرد التحقق من اجتياز الكود لمجموعة تقليدية من الاختبارات. باستخدام التعليمات البرمجية التي تم إنشاؤها بواسطة الذكاء الاصطناعي، يحتاج المراجع أيضًا إلى تحديد سبب كتابة التعليمات البرمجية كما كانت، وما إذا كان التنفيذ يعكس بالفعل المتطلبات الأصلية للمهمة وما إذا كان يتصرف بشكل صحيح في المواقف التي ربما لم يتوقعها الذكاء الاصطناعي.
يصبح هذا التمييز مهمًا بشكل خاص عندما يتم استخدام الذكاء الاصطناعي أيضًا لإنشاء الاختبارات التي تهدف إلى التحقق من صحته. قد يوضح الاختبار الآلي أن التنفيذ يتصرف بشكل متسق مع توقع معين – دون إثبات أن التوقع كان صحيحًا في المقام الأول.
ولمواجهة ذلك، يرى تران أن الشركات يجب أن تربط الاختبارات بالمتطلبات وعقود النظام بدلاً من التنفيذ الناتج عن نظام الذكاء الاصطناعي. وبخلاف ذلك، فإن المؤسسات تخاطر بإنشاء حلقة تعليقات مغلقة يتم من خلالها تقييم التعليمات البرمجية التي تم إنشاؤها بواسطة الذكاء الاصطناعي مقابل الافتراضات التي يولدها الذكاء الاصطناعي. وقال تران: “على نحو فعال، فإنك تخاطر باختبار ما إذا كان الذكاء الاصطناعي يتفق مع نفسه”.
والمعنى الضمني هو أن الشركات لا تستطيع الحكم على الكود من خلال اجتيازه اختباراته؛ يحتاجون أيضًا إلى تحديد ما إذا كانت هذه الاختبارات تلبي متطلبات العمل والنظام.
كما أنه يغير الطريقة التي يجب أن تفكر بها المؤسسات في تغطية الاختبار. قال بالاجي سرينيفاسان، كبير مديري الهندسة في LinkedIn، إن مقاييس التغطية التقليدية – النسبة المئوية للتعليمات البرمجية التي تمارسها الاختبارات – يمكن أن تحجب ما إذا كانت الاختبارات تتحقق بالفعل من صحة السلوك الهادف. نظرًا لأن الذكاء الاصطناعي يجعل من السهل إنشاء كل من التعليمات البرمجية والاختبارات، فإن جودة تلك التغطية لها أهمية أكبر من مجرد زيادة النسبة المئوية للتعليمات البرمجية التي يتم ممارستها.
وقال سرينيفاسان: “تصبح التغطية المفيدة للتعليمات البرمجية مقياسًا أكثر أهمية من أرقام التغطية التقليدية التي نراها”.
يجب أن يتحرك التحقق مع التطوير
التحدي التالي هو التوقيت. في عملية التطوير التقليدية، يمكن إجراء الاختبار بعد انتهاء المطورين من عملهم. لكن الذكاء الاصطناعي يمكنه إنشاء تعليمات برمجية بالتوازي وتكرارها بسرعة. إذا تم التعامل مع الاختبار كمرحلة منفصلة في نهاية التطوير، فقد تتراكم العديد من تغييرات التعليمات البرمجية قبل أن تحدد المؤسسة ما إذا كانت هذه التغييرات تعمل أم لا.
ووفقا لسيمون، فإن هذا يؤثر بالفعل على الكيفية التي ينبغي للمنظمات أن تفعل بها ذلك التفكير في ضمان الجودة.
وقال سيمون: “لقد حدثت تغييرات بالفعل في مجال ضمان الجودة والاختبار والتحقق من الصحة”. “ما قد يكون أكثر منطقية هو أنه إذا تم دمج مرحلة الاختبار على طول دورة حياة التطوير، بحيث يتم تضمينها كجزء من عملية التطوير للاستفادة من “رؤية التعليمات البرمجية” عند إنشائها – وليس لاحقًا.”
ستظل أساسيات الاختبار قائمة: لا تزال البرمجيات بحاجة إلى تلبية المتطلبات، والتصرف بشكل صحيح، والبقاء آمنًا والأداء المناسب. لكن الضوابط المحيطة بهذه الأهداف يمكن أن تسير على نحو متزايد جنباً إلى جنب مع التنمية.
وأشار سيمون إلى مصدر نموذج الذكاء الاصطناعي، والمراجعة الآلية، والتحقق من التبعية، والمسح الأمني، وملاءمة الاختبار كضوابط يمكن ويجب دمجها في عملية التطوير، مع الاحتفاظ بالموافقة البشرية على التغييرات حيثما تتطلب العواقب المحتملة ذلك.
وستكون النتيجة دورة حياة تطوير يتم فيها التحقق من الصحة بشكل مستمر، بدلاً من العمل كبوابة في النهاية.
البنية التحتية أصبحت استثمارا
وتعتمد قدرة الشركات على تحقيق هذا التحول على نطاق واسع جزئيًا على مدى نضج البنية التحتية للاختبار الحالية لديها. يمكن للمؤسسات التي لديها اختبار آلي قوي زيادة حجم التعليمات البرمجية دون الحاجة إلى زيادة متناسبة في المراجعة اليدوية، في حين أن تلك التي لا تملكها قد تواجه صعوبات.
قال سرينيفاسان: “إذا كانت تغطية الاختبار الخاصة بك ضعيفة وكنت تعتمد على الاختبار اليدوي للكشف عن الأخطاء والمشكلات وتأهيل الإصدارات، فلن تتمكن من إدراك الفوائد الكاملة للبرمجة بمساعدة الذكاء الاصطناعي نظرًا لأنه مطلوب من الإنسان التحقق من صحة الكود”.
ويساعد ذلك في وضع نشاط التمويل لهذا الأسبوع في سياقه.
يقوم CodeRabbit بأتمتة مراجعة التعليمات البرمجية، بينما يوفر Blacksmith البنية التحتية للتكامل والاختبار المستمر. كلاهما يعالج أجزاء من البنية التحتية التي تحتاجها المؤسسات مع تزايد أتمتة تطوير البرمجيات. وبدلاً من أن يكون الأمر مجرد حالة من الاستعانة بمصادر خارجية، وصف سايمون التحول بأنه “تصنيع وأتمتة التحقق من الصحة”.
وهناك أيضاً مبررات اقتصادية لشراء تلك القدرات بدلاً من بنائها. وقال تران إن أنظمة التحقق الداخلية تتطلب عملاً مستمرًا مع تغير نماذج الذكاء الاصطناعي والمخاطر الأمنية وبيئات التطوير. يمكن للبائعين المتخصصين نشر هذا الاستثمار عبر العملاء، مما يجعل المنتج النهائي أكثر فعالية من حيث التكلفة.
وأضاف تران أن الشركات التي تشتري هذه الأنواع من المنتجات لا تسلم مسؤولية جودة البرامج إلى هؤلاء البائعين. يمكن للأدوات مراجعة التعليمات البرمجية وإجراء الاختبارات وتحديد المشكلات المحتملة، ولكن لا تزال المؤسسات تحدد متطلباتها وقدرتها على تحمل المخاطر وما إذا كان التغيير جاهزًا للشحن.
وبالتالي، فإن البرمجة بمساعدة الذكاء الاصطناعي لا تغير فقط مدى سرعة إنتاج البرامج. إنه يجبر الشركات على إعادة النظر في كيفية قيام عملية التطوير بأكملها بترسيخ الثقة في ما يتم إنتاجه.
بالنسبة لقادة تكنولوجيا المعلومات في المؤسسات، قد يكون هذا هو التحول الأكثر أهمية: تعتمد قيمة إنشاء التعليمات البرمجية بشكل أسرع بشكل متزايد على ما إذا كانت الأنظمة المحيطة بها قادرة على التحقق من صحة هذه التعليمات البرمجية بنفس السرعة.
كيف تقوم مؤسستك بتكييف عمليات الاختبار والتحقق من الصحة الخاصة بها مع التعليمات البرمجية التي ينشئها الذكاء الاصطناعي؟ راسلنا عبر البريد الإلكتروني على [email protected].




