في دراسة جديدة وُجد أنّ أدوات الذكاء الصناعيّ المُعدَّة للمساعدة في تطوير البرمجيّات لم تزِد من الإنتاج أو سرعة الموظّفين- بل زادت من كميّة الأخطاء
منذ إطلاق ChatGPT في نوفمبر 2022، أو "جيبيتبوت" كما أسماه صحفي الشؤون التكنولوجيّة ران بار-زيك، يبدو أنّ أدوات الذكاء الصناعيّ التوليديّة (Generative AI) أصبحت موجودة في كلّ مكان، وباتت تخدمنا طوال الوقت. لكن هناك أدوات مماثلة تمّ تطويرها قبل ذلك في مجالات محدّدة أكثر. مثال على ذلك، المنتجات الّتي تمّ تصميمها خصّيصًا للمساعدة في تطوير البرمجيّات، والّتي اعتمدها العاملون في هذا المجال بكثير من الغبطة. يُطرح هنا سؤال واضح حولها: هل تعمل هذه المنتجات حقًّا على تحسين تطوير البرامج، أو تساعد مطوّري البرامج على العمل بشكل أسرع وأكثر كفاءة؟ يشعر الكثيرون أنّ الإجابة هي نعم، بما في ذلك كاتب هذه السطور؛ لكن ومن أجل تقديم ادّعاءات صحيحة، فالشعور الداخليّ لا يكفي- هناك حاجة إلى وجود معطيات. وفقًا لدراسة أجرتها شركة Uplevel، والّتي توفّر لعملائها مفاهيم ورؤى حول عمليّة التطوير الخاصّة بهم، فإنّ العكس هو الصحيح.
فحصت الدراسة أربعة مؤشّرات إنتاج لـ 775 من مطوّري البرمجيّات ذوي السّمات المتشابهة، 351 في المجموعة التجريبيّة و434 في المجموعة الضابطة. وقد تبيّن أنّ استخدام أدوات المساعدة على كتابة الكود لم تزِد من إنتاج المطوّرين أو كفاءتهم، بل زادت من عدد الأخطاء البرمجيّة، والمعروفة باسم "خطأ برمجيّ- Bugs" في اللغة المهنيّة.
هل تعمل منتجات الذكاء الصناعيّ بالفعل على تحسين تطوير البرامج، أو مساعدة المطوّرين على العمل بشكل أسرع؟ رسم توضيحيّ لأعمال البرمجة باستخدام الذكاء الصناعيّ AI | صورة: Shutterstock, Deemerwha studio
كيف نفحص ذلك؟
لفهم مؤشّرات الإنتاج الّتي تمّ قياسها في الدراسة؛ دعونا نتوقّف لشرحٍ مختصر عن طبيعة العمل في مجال تطوير البرمجيّات. في إدارة قاعدة كود (تعليمات برمجيّة) لشركةٍ ما، يكون أحد الأهداف السماح لأشخاص مختلفين بالعمل على إضافة إمكانات جديدة في نفس الوقت، بينما يكون بإمكانهم دائمًا العودة إلى الخلف والقيام بالتصحيح إذا ما تمّ اكتشاف مشكلة في تحديثٍ معيّن. لأجل ذلك، يتمّ استخدام برنامج لإدارة الإصدارات. عند العمل مع مثل هكذا برنامج، فإنّ من يرغبون في تحديث الكود ليس لديهم إمكانيّة الوصول المباشر إلى قاعدة كود للشركة، وإنّما إلى نسخة عنه. يقومون بتحديث النسخة (الإصدار)، وعندما يكتمل العمل على نحوٍ مرضٍ، يقومون بإنشاء طلب تحديث لقاعدة الكود الرئيس وفقًا للتغييرات. يُسمَّى هذا الطلب PR، وهو اختصارٌ لـ Pull Request، ويتمّ مراجعته، والمصادقة عليه- على أمل- من قبل عضو آخر في الطاقم.
فحصت الدراسة عدد الـ PR في فترة زمنيّة معطاة، ومتوسّط الفترة الزمنيّة من لحظة فتح الـ PR وحتّى إغلاقه. افترض الباحثون أنّ العمل مع أدوات المساعدة، من شأنه أن يؤدّي إلى إنشاء كود ذوجودة أفضل، وبالتالي تقليل متوسّط الوقت اللازم للتعامل مع الـ PR إلى أن تتمّ المصادقة عليه، وكذلك تسريع عمليّة كتابة الكود - وهكذا يزداد عدد الـ PR في نفس ذات الفترة الزمنيّة. تمّ أيضًا فحص عدد الأخطاء في الكود، وعدد ساعات العمل الإضافيّة الّتي قرّر الموظّفون استثمارها خارج نطاق ساعات العمل الرّسميّة لمكان العمل.
فُحصت المعطيات ذات الصّلة للمشاركين في الدراسة على مدى ثلاثة أشهر، وذلك من 9 يناير ولغاية 9 أبريل 2023. وبعد ذلك، بدأ المشاركون في المجموعة التجريبيّة باستخدام أداة مساعِد الكود. فُحصت الأرقام مرّة أخرى خلال نفس الأشهر الثلاثة من العام التالي- من 8 يناير ولغاية 7 أبريل 2024 (تمّ اختيار التواريخ ذاتها في عامين مختلفين من أجل تحييد أيّ عوامل تتعلّق بالتغيّرات الموسميّة). على عكس التوقّعات، تبيّن أنّه لم يكن هناك سوى اختلافات هامشيّة في مقاييس الكفاءة بين المجموعة التجريبيّة، والّتي عملت في سنة 2024 مع مساعد الكود، والمجموعة الضابطة الّتي لم تعمل معه مُطلقًا. من ناحية أخرى، كان عدد أخطاء الكود لدى المشاركين في المجموعة التجريبيّة أكبر بنسبة 41 بالمائة من عدد المشاركين في المجموعة الضابطة.
كما ذكرنا، فقد فحصت الدراسة أيضًا التغيير في عدد ساعات عمل المشاركين خارج ساعات العمل العاديّة، وذلك اعتمادًاعلى عدّة فرضيّات أساس: أوّلًا، إنّ ساعات العمل الإضافيّة، خارج نطاق ساعات العمل الروتينيّة، تزيد من التعرّض للاستنزاف؛ ثانيًا، إنّ العمل الإضافيّ بمعدّل مرتفع يشير إلى الكثير من الاستنزاف؛ والأهمّ من ذلك، في السياق الحاليّ- إنّ استخدام مساعد الكود سيؤدّي إلى عمل أكثر كفاءة، وبالتالي استنزاف أقلّ. تبيّن أنّ عدد الساعات كان أقلّ في سنة 2024 مقارنةً بسنة 2023 لدى المشاركين في المجموعتين، ولكن لدى المشاركين في المجموعة الضابطة بالذات، كان هناك انخفاضٌ أكبر بكثير من المجموعة التجريبيّة.
كان عدد أخطاء الكود للمشاركين في المجموعة التجريبيّة أكبر بنسبة 41 بالمائة من عددها لدى المشاركين في المجموعة الضابطة. مطوِّرة برمجيّات | Shutterstock, Gorodenkoff
دراسة واحدة فقط
لم تقدّم شركة GitHub Copilot، صانعة أداة مساعِد كتابة الكود المستخدَمة في الدراسة ردًّا مباشرًا، وإنّما أشارت إلى دراسة أجرتها هي بنفسها، والّتي تُظهر رضًا كبيرًا لدى مستخدمي مساعد الكود خاصتها، وزيادة تصل إلى 55 بالمائة في الكفاءة بفضل استخدام المساعد.
وعلى الرغم من نتائجها، إلّا أنّه من المهمّ الإشارة إلى أنّ الدراسة لا تنبذ استخدام برامج مساعِد كتابة الكود، ويرجع ذلك بالأساس إلى أنّ هذه البرامج يتمّ تحسينها بشكل مستمرّ. بالإضافة إلى ذلك، فهذه ما زالت دراسة وحيدة، وربّما لم يأخذ الباحثون في عين الاعتبار عوامل من شأنها أن تؤثّر في صحّة الاستنتاجات. على سبيل المثال، مساعِد الكود هو أداةٌ يتطلّب استخدامُها بشكلٍ حكيم التّعلُّم طوال الوقت، ومن المحتمل أنّ المشاركين في المجموعة التجريبيّة لم يكونوا قد طوّروا هذه الإمكانيّة لديهم بشكل كامل بعد، أو لم يكيّفوا طرق عملهم مع الوضع الجديد. ربّما بعد استخدام مطوّل أكثر لمساعِد كتابة الكود يُلاحظ تحسُّن أكبر في إنتاجهم. كذلك فإنّ الوعي بالاختبار بحدّ ذاته قد يؤدّي إلى أن تكون النتائج متحيّزة، كما وُجد على سبيل المثال في تجارب هوثورن (على الرغم من أنّه وبأثر رجعيّ تمّ وضع هذه التجارب محل شكّ). وهذا هو السبب في أنّ دراسة واحدة لا تكفي عادةً للتوصّل إلى نتيجة قاطعة؛ هناك حاجة إلى دراسات إضافيّة مستقلّة لدعمها.
حاليًا نحن نسمع عن نتائج مختلفة كليًّا، كتلك القادمة من شركة Innovative Solutions، والّتي توفّر خدمات سحابيّة لعملائها- حيث أبلغوا في الشركة عن زيادة في الإنتاج بمقدار ضعفين إلى ثلاثة أضعاف منذ أن بدأ مطوّرو الشركة في استخدام برامج مساعِد كتابة الكود. ومع ذلك، يجب أن نتذكّر أنّ هذا تقريرٌ للشركة، وليس دراسة خارجيّة.
شخصيًّا، إنّ كاتب هذه السطور يعمل في كتابة الأكواد لكسب لقمة عيشه، ويستخدم مساعِد كتابة الكود ويشعر أنّ هناك تحسّنًا في إنتاجه. عدد من زملاء العمل، والّذين يستخدمون هم أيضًا مساعد كتابة الكود، عبّروا كذلك عن مشاعر مماثلة. ولكنّ المشاعر الشخصيّة وأقوال الأصدقاء ليس لها أيّة صلاحيّة بحثيّة من أيّ نوع.
من أجل تحديد ما إذا كانت أدوات مساعد كتابة الكود تساهم فعلًا في العمل، سيتعيّن علينا انتظار المزيد من الدراسات.