مفاهيم CCS: • المواضيع الاجتماعية والمهنية صناعة الحوسبة؛ إدارة أنظمة الحوسبة والمعلومات؛ إدارة المشاريع والأشخاص.

كلمات وعبارات إضافية: الذكاء الاصطناعي التوليدي، نماذج اللغة الكبيرة، تكييف التكنولوجيا، هندسة البرمجيات التجريبية.

دانييل روسو. 2024. التنقل في تعقيد اعتماد الذكاء الاصطناعي التوليدي في هندسة البرمجيات. ACM Trans. Softw. Eng. Methodol. 37, 4, المقال 111 (يناير 2024)، 49 صفحة.https://doi.org/10.1145/1122445.1122456

تظهر الوعد التحويلي للذكاء الاصطناعي (AI) بشكل متزايد عبر مختلف القطاعات، حيث تظهر نماذج الذكاء الاصطناعي كفاءات شبيهة بالبشر في مجالات متنوعة مثل فهم اللغة الطبيعية والتعرف على الصور [120]. أحد المجالات التي يكون فيها هذا الإمكان بارزًا بشكل خاص هو هندسة البرمجيات، وهي وظيفة حيوية ضمن المنظمات المعاصرة. يتم التأكيد على هذه الأهمية من خلال الانتشار المتزايد للبرمجيات في مجموعة واسعة من المنتجات والخدمات، حيث تعزز الميزات الرقمية من قيمتها [92]. من المراحل الأولية لدورة حياة تطوير البرمجيات، يمكن أن تكون أدوات الذكاء الاصطناعي حلفاء قيمين. يمكن للذكاء الاصطناعي التوليدي أن ينقح من خلال مصادر بيانات ضخمة مثل ملاحظات المستخدمين، واتجاهات السوق، وسجلات النظام، مما يوفر رؤى لتوليد الأفكار للميزات. خلال تحليل وتصميم الأنظمة، يمكن أن تقترح الأدوات المعززة بالذكاء الاصطناعي تصميمات معمارية متعددة لتكنولوجيا المعلومات وتتكيف بسرعة مع التكوينات، مما يسرع من عملية التصميم وإطلاق المنتجات. في مرحلة الترميز، لا يساعد الذكاء الاصطناعي فقط في توليد الشيفرة، بل يساعد أيضًا المطورين من خلال صياغة مسودات الشيفرة الأولية، واكتشاف الأنماط بسرعة، ويعمل كمستودع للمعرفة. في مرحلة الاختبار،

يمكن لأدوات الذكاء الاصطناعي أن تولد تلقائيًا حالات الاختبار وتؤتمت وظائف اختبار معينة. خلال النشر، تعمل أدوات الذكاء الاصطناعي على تبسيط عملية الإصدار، مما يضمن دمج إصدارات البرمجيات بسلاسة في الأنظمة الحالية، بينما تراقب أيضًا عن أي شذوذ محتمل في النشر وتساعد في استراتيجيات التراجع إذا لزم الأمر. عندما يتعلق الأمر بالصيانة، يمكن أن تساعد الرؤى المستمدة من الذكاء الاصطناعي مهندسي البرمجيات في تشخيص المشكلات، واقتراح الإصلاحات، والتنبؤ بالمجالات المحتملة للتحسين. قد تكون آثار الذكاء الاصطناعي على مجال تطوير البرمجيات هائلة، مع توقعات تشير إلى زيادة في الإنتاجية تتراوح بين 20 إلى 45 في المئة [19]. يمكن تحقيق هذه الزيادة الكبيرة من خلال تبسيط المهام التقليدية مثل صياغة مسودات الشيفرة الأولية، وتحسين هياكل الشيفرة الحالية (إعادة الهيكلة)، أو إجراء تحليلات جذرية شاملة. لا يقلل دمج الذكاء الاصطناعي من الوقت المخصص لهذه الأنشطة فحسب، بل يعزز أيضًا الكفاءة والفعالية العامة لعملية تطوير البرمجيات [75]. ومع ذلك، على الرغم من الفوائد المحتملة، يبدو أن دمج نماذج اللغة في هندسة البرمجيات معقد ومليء بالتحديات. في الواقع، هناك حتى مؤشرات على أن استخدام نماذج اللغة الكبيرة في تراجع، ربما نتيجة لتجارب المستخدم النهائي التي وجدت أنها غير مناسبة لمتطلباتهم [113]. وبالتالي، هناك حاجة ملحة لفك رموز المحددات الأساسية التي تؤثر على اعتماد أدوات الذكاء الاصطناعي التوليدية، مثل الأدوات المدعومة بنماذج اللغة الكبيرة. كما نعلم، تشكل مجموعة متنوعة من العناصر نمطية وعقلية وراء قرار مهندسي البرمجيات باستخدام نماذج اللغة. تشمل هذه العناصر مكونات تقنية، مثل جودة النموذج والأداء، ومكونات غير تقنية، بما في ذلك الفائدة المدركة وسهولة الاستخدام [112]. ومع ذلك، كانت هناك أبحاث تجريبية محدودة حول العوامل التي تؤثر على اعتماد نماذج اللغة في هندسة البرمجيات. ومن ثم، نصوغ أسئلة بحثنا على النحو التالي:

سؤال البحث: ما الذي يؤثر على اعتماد أدوات الذكاء الاصطناعي التوليدية في هندسة البرمجيات؟
في مسعانا لاستكشاف سؤال بحثنا، قمنا بتطبيق نهج مختلط متقارب، مستكشفين اعتماد الذكاء الاصطناعي التوليدي ونماذج اللغة الكبيرة ضمن مجال هندسة البرمجيات. لتأطير فهمنا لاعتماد الذكاء الاصطناعي، أشرنا إلى ثلاثة إطارات نظرية رئيسية تفحص التأثيرات على المستويات الفردية والتكنولوجية والاجتماعية. شملت هذه الإطارات نموذج قبول التكنولوجيا (TAM) [110]، ونظرية انتشار الابتكار (DOI) [85]، ونظرية التعلم الاجتماعي المعرفي (SCT) [9]. من خلال دمج هذه النظريات المعتمدة جيدًا، تمكنا من فهم شامل لمحددات اعتماد نماذج اللغة واستكشاف الطرق المميزة التي يتم بها تشغيل هذه المتغيرات في مجال هندسة البرمجيات. بدأنا بحثنا بإجراء استبيان مع مجموعة من 100 مهندس برمجيات. تأثر تصميم هذا الاستبيان بالأبعاد الرئيسية لنظرياتنا المختارة. تم تحليل البيانات المجمعة باستخدام منهجية جيويا [38]، مما سهل تطوير نموذجنا النظري الأولي. تم التحقق من صحة هذا النموذج النظري المؤقت باستخدام نمذجة المعادلات الهيكلية – المربعات الصغرى الجزئية (PLS-SEM)، مدعومًا بالبيانات التي تم جمعها من 183 مهندس برمجيات. تعزز تقارب الرؤى المستمدة من هذه التحقيق الشامل والمتعدد الأبعاد فهمنا لاعتماد الذكاء الاصطناعي ضمن هندسة البرمجيات. علاوة على ذلك، من خلال فهم ديناميات الاعتماد وتأثير هذه التقنيات المدمرة، يحمل هذا البحث إمكانية توجيه تصميم أدوات الذكاء الاصطناعي المستقبلية وتقديم توصيات ذات صلة لاستراتيجيات التنفيذ على مستوى المنظمة. في الواقع، تمثل أدوات الذكاء الاصطناعي التوليدية ابتكارًا مدمراً في مجال هندسة البرمجيات، كما عرّف مفهوم “الابتكار المدمر” لكريستنسن [18]. تستهدف هذه الأدوات، بينما تستهدف في البداية تطبيقات متخصصة أو شرائح سوق غير مخدومة، إمكانية إحداث ثورة في ممارسات هندسة البرمجيات التقليدية. إن قدرتها على أتمتة المهام المعقدة، وتوليد الشيفرة، وتقديم حلول استنادًا إلى مجموعات بيانات ضخمة تتحدى الوضع الراهن ويمكن أن تؤدي إلى تحول جذري في
كيف يتم الاقتراب من تطوير البرمجيات. مع مرور الوقت، ومع تزايد دقة هذه الأدوات واعتمادها على نطاق واسع، قد تحل محل المنهجيات والأدوات الراسخة، تمامًا كما تعيد الابتكارات المدمرة تشكيل الصناعات. من خلال فهم ديناميات اعتماد هذه التقنيات التحويلية، تقدم هذه الدراسة رؤى حول مسارها المحتمل وآثارها، مما يوجه تصميم أدوات الذكاء الاصطناعي المستقبلية ويقدم توصيات لتنفيذها الاستراتيجي عبر المنظمات.

يتكشف هيكل هذه المقالة على النحو التالي. في القسم 2، نقدم مراجعة شاملة للأعمال ذات الصلة. تبدأ تحقيقاتنا المختلطة الأساليب مع استنتاج نظرية أولية، وهي عملية نفصلها بدقة في القسم 3. ثم نقوم بتحليل نتائج هذه العملية في القسم 4. من هذه النتائج، نصوغ إطارنا النظري في القسم 5، موضحين فرضياته. يخضع نموذجنا لعملية تحقق صارمة باستخدام النمذجة الهيكلية بالحد الأدنى من المربعات، كما هو موضح في القسم 6. في الأقسام الختامية، نتأمل في الآثار الأوسع والقيود المحتملة لدراستنا في القسم 7، ونرسم مسارات البحث المستقبلية في القسم 8.

يشهد مجال هندسة البرمجيات تحولًا مع إدخال الذكاء الاصطناعي التوليدي، خاصة من خلال قدرات نماذج اللغة الكبيرة (LLMs). تعود قوة نماذج اللغة الكبيرة، مثل سلسلة المحولات المدربة مسبقًا (GPT) من OpenAI، إلى الدور الأساسي لهياكل المحولات في معالجة اللغة الطبيعية، والتي كانت مؤثرة لعدة سنوات. بالإضافة إلى كفاءتها المعروفة في توليد نصوص تشبه النصوص البشرية، فإن نماذج اللغة الكبيرة، في مجال هندسة البرمجيات، مستعدة لتقديم اقتراحات برمجية، والمساعدة في التوثيق الآلي، والمساعدة في استنباط المتطلبات، وأكثر من ذلك. لقد تم دفع تطور نماذج اللغة الكبيرة كذكاء اصطناعي توليدي بشكل أكبر من خلال دمج هياكل المحولات، مما يعزز فهمها وتوليدها للسياق. بينما نتنقل في تقاطع نماذج اللغة الكبيرة وهندسة البرمجيات، يصبح من الواضح أن إمكاناتها تمتد إلى ما هو أبعد من مجرد توليد النصوص. إنها تظهر كأدوات تعاونية، من المقرر أن تعيد تعريف جوانب مختلفة من دورة حياة تطوير البرمجيات. لذلك، طوال هذا البحث، نستخدم مصطلحي الذكاء الاصطناعي التوليدي ونماذج اللغة الكبيرة بالتبادل، مع التأكيد على أهميتهما وإمكاناتهما في هندسة البرمجيات.

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

تشمل إحدى الاتجاهات البارزة في البحث تقييم دقة وجودة الشيفرة التي تولدها أنظمة الذكاء الاصطناعي مثل GitHub Copilot. أجرت دراسات من قبل نغوين ونادي، ودخل، وآخرون، ويتيستيرين، جميعها تقييمات تجريبية لتقييم صحة الشيفرة التي تولدها Copilot، ووجدت درجات متفاوتة من النجاح اعتمادًا على لغة البرمجة وتعقيد المهمة [27،68،118]. يشير هذا التركيز المشترك على التقييم إلى أهمية تقييم السلامة الوظيفية للشيفرة التي تولدها أدوات الذكاء الاصطناعي، وهو أمر أساسي في هندسة البرمجيات.

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

تتأثر الإنتاجية في تطوير البرمجيات بشكل إيجابي من خلال دمج أدوات الذكاء الاصطناعي، حيث تزيد أدوات مثل Copilot بشكل كبير من سرعة إنتاج الشيفرة [49، 75]. بينما تُشاد هذه الأدوات بقدراتها على تعزيز الإنتاجية، فإن فهم أدائها وقيودها أمر حيوي للاستفادة من إمكاناتها بشكل فعال. تسلط دراسات Tian وآخرون [103] وCamara وآخرون [15] الضوء على قدرات وقيود النماذج اللغوية الكبيرة، مثل ChatGPT. تشير التقييمات التجريبية إلى أنه بينما تظهر هذه النماذج كفاءة في المهام البسيطة والمهيكلة جيدًا، فإنها تميل إلى مواجهة صعوبات في المهام المعقدة التي تتضمن تمييزًا دلاليًا [103]. بالإضافة إلى ذلك، تم تحديد علاقة كبيرة بين طول تسلسل الإدخال وجودة المخرجات، حيث تؤدي المدخلات الأطول غالبًا إلى نتائج أسوأ [15]. تبرز هذه النتائج الدور الدقيق للذكاء الاصطناعي في إنتاجية تطوير البرمجيات. بينما تعزز السرعة، يمكن أن تكون تعقيد المهام وطول تسلسلات الإدخال عوامل محددة، مما يشير إلى مجالات لتحسين إضافي وتحسين في هذه النماذج.

بوضوح، بدأ سوبانيا وآخرون دراسة مقارنة بين كوبايلوت وبرمجة الجينات، وهو نهج آخر في توليد البرامج تلقائيًا. وقد استنتجوا أنه، على الرغم من الأداء المتقارب، لم تكن برمجة الجينات ناضجة بما يكفي للتطوير البرمجي العملي مثل كوبايلوت [97]. توفر هذه التحليل المقارن وجهة نظر فريدة حول مشهد منهجيات البرمجة التلقائية.

تمت مناقشة القضايا التربوية من قبل كل من دراسات ويرميلينجر ودخل وآخرون التي تناولت آثار أدوات الذكاء الاصطناعي مثل كوبايلوت في البيئات التعليمية. بينما استكشف ويرميلينجر آثار كوبايلوت على طرق التدريس والتقييم في دورات البرمجة [116]، ناقش دخل وآخرون التحديات المحتملة للمطورين المبتدئين الذين قد يفشلون في تصفية الحلول غير المثلى لكوبايلوت بسبب نقص الخبرة [27]. تبرز هذه التشابهات الآثار التربوية الكبيرة لدمج أدوات الذكاء الاصطناعي في التعليم.

تتعلق المخاوف حول تكامل وأمان أدوات الذكاء الاصطناعي مثل GitHub Copilot بنتيجة مشتركة بين يافورسكي وبيوتروفسكي [51] وزانغ وآخرين [119]. توضح كلا الدراستين أنه على الرغم من الفوائد المحتملة لهذه الأدوات، يعبر المطورون عن تردد ويواجهون تحديات عند دمجها في سير العمل الخاص بهم، بسبب صعوبات التكامل ومخاوف الأمان. ومع ذلك، تختلف هذه الدراسات عند فحص تفاعلات المطورين. يوضح زانغ وآخرون جوانب أكثر عملية مثل لغات البرمجة وبيئات التطوير المتكاملة المستخدمة مع Copilot، بينما يركز يافورسكي وبيوتروفسكي على مشاعر المطورين تجاه أدوات الذكاء الاصطناعي. إرنست وبافوتا [34]، على الرغم من مناقشتهما أيضًا لتعقيدات تكامل الذكاء الاصطناعي، يختلفان من خلال تسليط الضوء على تحديات إضافية تتعلق بالامتثال القانوني والتحيز. هذا يوسع النقاش حول تأثير الذكاء الاصطناعي على تطوير البرمجيات ليشمل الاعتبارات الأخلاقية والقانونية. توجد أيضًا قواسم مشتركة، وإن كانت من زاوية مختلفة، في دراسة بيرد وآخرين [13] وموزانار وآخرين [66]. تتناول كلا الدراستين الدور المتطور للمطورين مع تزايد انتشار أدوات الذكاء الاصطناعي. يقترح بيرد وآخرون تحولًا نحو قضاء المطورين مزيدًا من الوقت في مراجعة الشيفرة التي تم إنشاؤها بواسطة الذكاء الاصطناعي، بينما يقدم موزانار وآخرون تحليلًا منظمًا لتفاعلات المطورين مع أدوات الذكاء الاصطناعي، كاشفين عن عدم الكفاءة وتكاليف الوقت. وبالتالي، بينما تتقارب الدراسات بشكل كبير حول التحول
إمكانات وتحديات أدوات الذكاء الاصطناعي في تطوير البرمجيات، كما أنها تقدم وجهات نظر فريدة، مما يوسع النقاش ليشمل جوانب مثل القضايا القانونية، وتغييرات سير العمل، وتكاليف الوقت.

تم التحقيق في دور المجتمع في تشكيل ثقة المطورين في أدوات الذكاء الاصطناعي بواسطة تشينغ وآخرين [16]. يقدمون تحليلًا مفصلًا لكيفية تأثير المجتمعات عبر الإنترنت، مثل المنتديات ومجموعات النقاش، على إدراك المطورين لأدوات الذكاء الاصطناعي. تشير أبحاثهم إلى أن التجارب المشتركة والمناقشات الجماعية تلعب دورًا كبيرًا في تشكيل ثقة المطورين في المساعدة التي يقدمها الذكاء الاصطناعي.

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

كانت قابلية استخدام مساعدي البرمجة بالذكاء الاصطناعي نقطة محورية في البحث، حيث تم تحديد الدوافع الرئيسية للاستخدام على أنها تقليل عدد الضغطات، وإكمال المهام بسرعة، واسترجاع الصياغة [58، 107]. ومع ذلك، غالبًا ما يواجه المطورون تحديات في التحكم في الأدوات، وتوافق المخرجات مع المتطلبات، وصعوبات في فهم وتحرير وتصحيح مقتطفات الشيفرة التي تم إنشاؤها [58، 107]. بالنسبة للمبرمجين المبتدئين، تظهر قضايا معرفية وما وراء معرفية أثناء استخدام هذه الأدوات للمهام، مما يشير إلى الحاجة إلى تصميم داعم أفضل [77]. أيضًا، يظهر المطورون أنماط تفاعل مميزة، كل منها يتطلب أشكالًا مختلفة من دعم الأدوات [11]. وهذا يدل على ضرورة تحسين قابلية الاستخدام في مساعدي البرمجة بالذكاء الاصطناعي، مع التركيز على التحكم من قبل المستخدم، وتقليل الجهد المعرفي، ودعم أنماط التفاعل.

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

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

بعيدًا عن الأبحاث المذكورة أعلاه، من الضروري ملاحظة وجود مولدات شيفرة أخرى بجانب كوبايلوت. تلعب أدوات مثل ألفا كود [57]، وأمازون كود ويزبر [6]، وبلاك بوكس AI [3]، وكود كومبليت [21]، وكود جي إكس [121]، وكوديم [22]، وميوتابل AI [67]، وغوست رايتر ريبليت [82]، وتابناين [100] أيضًا أدوارًا في مجال توليد الشيفرة المدعوم بالذكاء الاصطناعي. من المثير للاهتمام، بينما يتم الاعتراف بهذه الأدوات في المشهد، هناك نقص واضح في الأبحاث التجريبية التي تقيمها. كشفت أبحاثنا في الأدبيات عن ثلاثة أوراق فقط تذكر هذه الأدوات، وذلك فقط في سياق الأعمال ذات الصلة أو أقسام النقاش [16، 42، 114]. وهذا يقدم فجوة واضحة في مجموعة الأبحاث الحالية.

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

تتطلب الطبيعة المتعددة الأوجه لاعتماد التكنولوجيا تطبيق أطر نظرية شاملة يمكن أن تلتقط وتفسر العوامل المؤثرة بشكل كافٍ. يقدم نموذج قبول التكنولوجيا، ونظرية انتشار الابتكار، والنظرية الاجتماعية المعرفية معًا نهجًا قويًا لفهم تعقيد اعتماد نماذج اللغة في هندسة البرمجيات.
3.1.1 نموذج قبول التكنولوجيا (TAM). تم الإشادة بنموذج قبول التكنولوجيا على نطاق واسع لملاءمته وكفاءته في التنبؤ بشرح قبول أشكال مختلفة من التكنولوجيا [110]. تشكل مكوناته الأساسية – الفائدة المدركة وسهولة الاستخدام المدركة – نقطة انطلاق ممتازة لفهم سلوك الاعتماد. على سبيل المثال، إذا تم اعتبار نماذج اللغة مفيدة وسهلة الاستخدام، فمن المرجح أن يتبناها مهندسو البرمجيات. نظرًا لصلابته وبساطته، يوفر نموذج قبول التكنولوجيا أساسًا لفهم المحددات الأساسية لاعتماد التكنولوجيا ويساعد في تشخيص الحواجز الأساسية لاعتماد نماذج اللغة.
3.1.2 نظرية انتشار الابتكار (DOI). بينما يركز نموذج قبول التكنولوجيا بشكل أساسي على تصورات المستخدمين، تكمل نظرية انتشار الابتكار نموذج قبول التكنولوجيا من خلال معالجة الخصائص التكنولوجية التي تؤثر على الاعتماد. حدد روجرز [85] السمات الرئيسية للابتكارات – الميزة النسبية، والتوافق، والتعقيد، وقابلية التجربة، والملاحظة – التي تؤثر بشكل كبير على معدلات اعتمادها. كابتكار في هندسة البرمجيات، يمكن أن يتشكل قبول نماذج اللغة من خلال هذه السمات. على سبيل المثال، قد تكون الميزة النسبية لنماذج اللغة مقارنة بأساليب البرمجة التقليدية دافعًا قويًا للاعتماد. قد يلعب توافق نماذج اللغة مع الممارسات الحالية وتعقيد هذه النماذج أيضًا أدوارًا حاسمة. وبالتالي، تضيف نظرية انتشار الابتكار عمقًا إلى فهمنا للعوامل المحددة للتكنولوجيا التي تؤثر على اعتماد نماذج اللغة.
3.1.3 النظرية الاجتماعية المعرفية (SCT). لا تحدث قرار اعتماد تقنيات جديدة في فراغ. إنه يتأثر بالبيئة الاجتماعية التي يعمل فيها الأفراد. تدخل النظرية الاجتماعية المعرفية في اللعب
هنا من خلال التأكيد على العوامل الاجتماعية والبيئية التي تؤثر على سلوكيات الأفراد [9]. هندسة البرمجيات، مثل أي مهنة، لها ثقافتها الخاصة، ومعاييرها، ومعتقداتها المشتركة التي يمكن أن تشكل بشكل كبير اعتماد نماذج اللغة. على سبيل المثال، قد تشجع المعايير السائدة أو مدى استخدام الأقران على استخدام نماذج اللغة أو تثبطه. علاوة على ذلك، قد تؤثر الكفاءة الذاتية للأفراد – التي تتشكل جزئيًا من خلال بيئتهم الاجتماعية – على استعدادهم للتفاعل مع هذه الأداة الجديدة. لذلك، تضيف SCT طبقة اجتماعية إلى فهمنا لاعتماد نماذج اللغة.

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

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

تشمل تحقيقاتنا ثلاث وحدات تحليل: عوامل على مستوى الأفراد، وعوامل على مستوى التكنولوجيا، وعوامل على المستوى الاجتماعي، مستوحاة من نموذج قبول التكنولوجيا، وانتشار الابتكارات، ونظرية الإدراك الاجتماعي. نهدف إلى الكشف عن فهم شامل لقبول واستخدام الأدوات المدعومة بـ LLM في سياق هندسة البرمجيات. هنا، نفصل أسئلة استبيان المسح النهائي المصممة لالتقاط هذه البنى بشكل فعال. كخطوة أولية، أجرينا مقابلة تجريبية مع مدير هندسي كبير من شركة برمجيات بارزة مقرها في وسط أوروبا لضمان وضوح وملاءمة أسئلتنا في أبريل 2023. لتصميم هذا التحقيق، استخدمنا المعيار التجريبي SIGSOFT لاستبيانات المسح [79].

تركز عوامل المستوى الفردي، المستمدة من نموذج قبول التكنولوجيا، على الفائدة المدركة، وسهولة الاستخدام المدركة، ونية السلوك:

تشمل عوامل المستوى التكنولوجي، المستمدة من انتشار الابتكارات، التوافق، والميزة النسبية، والتعقيد:

تم تنفيذ جمع البيانات عبر Prolific Academic [74]، وهي منصة معروفة لجمع البيانات الأكاديمية غالبًا ما تستخدمها مجتمع هندسة البرمجيات [28،88-90]. طلبنا مدخلات من 100 مهندس برمجيات، تم سؤالهم للإجابة على سلسلة من تسعة أسئلة مفتوحة مستندة إلى مبادئ نظرية. تجاوز التعويض للمشاركين (10 دقائق) الحد الأدنى للأجور الفيدرالي الأمريكي. تم إجراء الاستطلاع على منصة Qualtrics.

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

امتثلت منهجية جمع البيانات لدينا بدقة للإرشادات الأخلاقية لإعلان هلسنكي [71]. وافقت لجنة أخلاقيات البحث في جامعة آلبورغ على هذا المشروع البحثي في مارس 2023. كان جميع المشاركين أكبر من 18 عامًا، وقدموا موافقة مستنيرة قبل المشاركة في الدراسة، وتم إبلاغهم بحقهم في الانسحاب من المشاركة في أي وقت. بالإضافة إلى ذلك.

أكمل المؤلفون تدريبًا رسميًا في أخلاقيات البحث في الهندسة والعلوم السلوكية.

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

تراوحت الخبرة المهنية للمشاركين عبر مراحل مختلفة في صناعة البرمجيات: كان لديهم سنوات من الخبرة، و كان لديهم سنوات، و كان لديهم سنوات، و كان لديهم سنوات، و كان لديهم أكثر من 10 سنوات من الخبرة.

أما بالنسبة لأدوارهم في الصناعة، فقد كان الغالبية من مطوري البرمجيات أو المبرمجين ( ). تلا ذلك المختبرون أو مهندسو ضمان الجودة ( تحليل البيانات، مهندسو البيانات، أو علماء البيانات ( قادة الفرق ( مصممو تجربة المستخدم / واجهة المستخدم ( ).

تم تنفيذ تحليل البيانات ضمن إطار الاستفسار الطبيعي [59]، مدعومًا بطريقة المقارنة المستمرة [40]. الدور الحاسم الذي تلعبه هذه الاستراتيجيات في اكتساب البيانات النوعية وفحصها مهم. تسهل هذه العملية التكرارية تطوير النظرية الأولية من خلال تحديد الأنماط والأبعاد الأوسع [39]، المستمدة من المقارنة والتحليل المستمر للبيانات، وتنقيحها وفقًا لملاحظات المشاركين [50].

تم استخدام نهج التحليل الموضوعي لمعالجة البيانات. التحليل الموضوعي هو طريقة شائعة الاستخدام في البحث النوعي، والتي تتضمن تحديد وتحليل والإبلاغ عن الأنماط أو الموضوعات داخل البيانات، مع تقديم حساب غني ومفصل ومعقد للبيانات [20]. كانت المنهجية المنظمة المقترحة من قبل جيويا وآخرين [38] بمثابة الإطار التحليلي. شهدت الاتجاهات الحديثة داخل مجتمع علوم الإدارة اعتماد هذه المنهجية، مما يبرز إمكاناتها في تعزيز الصرامة العلمية [44، 60]. النهج منظم ومكرس لتشجيع التقدم النظري الشامل [38].

تقسم منهجية جيويا معالجة البيانات إلى ثلاث مراحل. تدور المرحلة الأولى حول التعرف على المفاهيم من الدرجة الأولى، أو الرموز الحية [99]، التي تتماشى عن كثب مع كلمات المشاركين أنفسهم، مع تصنيف مفروض من الباحث بشكل ضئيل. ثم تم تجميع هذه الرموز في موضوعات أوسع، وهي عملية تعرف بالتشفير المفتوح [108].

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

تجمع المرحلة النهائية الموضوعات من الدرجة الثانية المتشابهة في أبعاد مجمعة، تمثل ذروة المساهمة النظرية. كانت هذه العملية تكرارية وموجهة نحو العملية [61]، واستمرت حتى تم تحقيق التشبع النظري [25].

نتيجة هذا التحقيق هي هيكل البيانات، الذي يجسد المصطلحات من الدرجة الأولى، والموضوعات من الدرجة الثانية، والأبعاد المجمعة لكل من الأبعاد النظرية التسعة لتحقيقنا. من الجدير بالذكر أن الأبعاد المجمعة لم تكن فئات مسبقة تم تعريفها قبل التحليل؛ بل هي المنتج النهائي لعملية تحليل مكررة ومنقحة.

على سبيل المثال، في الجدول 1، الذي يوضح هيكل البيانات لفائدة LLMs المدركة في هندسة البرمجيات، يتم عرض تقدم واضح من المفاهيم من الدرجة الأولى إلى الموضوعات من الدرجة الثانية والأبعاد المجمعة. اعتبر الاقتباس من المشارك R-15، الذي تم تصنيفه تحت المفاهيم من الدرجة الأولى كـ “أتمتة المهام، تقليل الوقت والجهد، الترميز اليدوي، الوثائق.” ثم يتم دمج هذه المفاهيم في الموضوع من الدرجة الثانية “تحسينات الكفاءة الخاصة بالمهام”، مما يشير إلى فئة أوسع من التحسينات في الكفاءة المتعلقة بمهام محددة. بعد ذلك، يتم تجميع هذا الموضوع من الدرجة الثانية في بعد
“تحسين الكفاءة”، الذي يمثل منطقة تأثير عامة في هندسة البرمجيات من خلال استخدام LLMs. يوضح هذا المثال التقدم التحليلي من اقتباسات المشاركين المحددة إلى فئات موضوعية أوسع، مما يوضح منهجية دراستنا.

يتم تقديم هيكل البيانات مع الموضوعات من الدرجة الثانية والمفاهيم من الدرجة الأولى الخاصة بها في الجداول 1-9.

تم استخدام نموذج قبول التكنولوجيا على نطاق واسع في دراسة اعتماد التكنولوجيا، مع التركيز على اثنين من المؤشرات الرئيسية للقبول: الفائدة المدركة وسهولة الاستخدام المدركة [29]. في سياق هندسة البرمجيات، يمكن فحص الفائدة المدركة لنماذج اللغة الكبيرة من خلال تقييم كيف تساهم في الكفاءة والإنتاجية وتعزيز الأداء. يوفر الجدول 1 ملخصًا لآراء مهندسي البرمجيات حول LLMs في عملهم.
4.1.1 تحسين الكفاءة. واحدة من الفوائد المدركة الرئيسية لـ LLMs هي قدرتها على تحسين الكفاءة. كما هو موضح في الجدول 1، فإن تحسين الكفاءة هو البعد المجمّع الأكثر ذكرًا (55%). يدرك المهندسون أن LLMs يمكن أن تؤتمت بعض المهام، وتقلل من الوقت والجهد، وتبسط المهام المملة. على سبيل المثال، أشار R-15 إلى أن LLMs يمكن أن “تزيد من كفاءتي من خلال أتمتة بعض المهام وتقليل الوقت والجهد الذي يستغرقه الترميز اليدوي والوثائق.” يتماشى هذا الاكتشاف مع تأكيد نموذج قبول التكنولوجيا على الفائدة المدركة، الذي يفترض أن المستخدمين سيتبنون التكنولوجيا إذا رأوا أنها مفيدة في تعزيز أدائهم [29].
4.1.2 الفوائد الخاصة بالمهام. جانب آخر من الفائدة المدركة هو الفوائد الخاصة بالمهام التي تقدمها LLMs، مثل تصحيح الأخطاء، وتعلم الميزات الجديدة، وتوليد مقتطفات من الشيفرة. كما ذكر R-30، زادت LLMs بشكل كبير من كفاءتهم من خلال مساعدتهم في “تصحيح الشيفرة بشكل أسرع، وتعلم الميزات الجديدة دون الحاجة إلى مسح الوثائق بالكامل، وتوفير مقتطفات شيفرة مفيدة للعمل.” تمثل هذه الفئة من الأبعاد المجمعة وتدعم الفكرة القائلة بأن الفائدة المدركة هي مؤشر مهم لاعتماد LLMs [111].
4.1.3 أداة تكميلية. تُعتبر LLMs أيضًا أداة تكميلية للخبرة البشرية والحكم. أشار R-17 إلى أن “نماذج اللغة لديها القدرة على تعزيز الإنتاجية والكفاءة في هندسة البرمجيات، ولكن يجب استخدامها كأداة جنبًا إلى جنب مع الخبرة البشرية والحكم.” يبرز هذا التصور أهمية تحقيق التوازن بين فوائد LLMs والحاجة إلى الإشراف البشري، وهو جانب قد يؤثر على الفائدة المدركة العامة للتكنولوجيا.
4.1.4 قابلية تطبيق محدودة ومخاوف تتعلق بالجودة. بينما أبلغ العديد من المستجيبين عن آراء إيجابية حول LLMs، أعرب البعض عن مخاوف بشأن قابلية تطبيقها المحدودة ( ) ومخاوف تتعلق بالجودة (9%). على سبيل المثال، ذكر R-21 أن LLMs “جيدة للمهام العامة، لكن النماذج ليس لديها أي معرفة حول واجهات برمجة التطبيقات الداخلية لدينا، لذا من الصعب جدًا تطبيقها.” كما أشار R55 إلى أنه بينما قد تساعد LLMs، “يجب عليك مراجعة وفهم الشيفرة على أي حال. لذا لا أعرف إذا كانت ستجعلك أكثر كفاءة.” تشير هذه المخاوف إلى أنه بينما يمكن أن تقدم LLMs فوائد في بعض الحالات، قد تكون فائدتها محدودة بسبب الحاجة إلى المراجعة والتكيف مع السياقات المحددة. يتماشى هذا الاكتشاف مع أدبيات نموذج قبول التكنولوجيا، التي تبرز أن الفائدة المدركة للتكنولوجيا لا تحدد فقط من خلال فوائدها ولكن أيضًا من خلال قيودها [111].

تدعم الفائدة المدركة لـ LLMs في هندسة البرمجيات، كما يتضح من تحسين الكفاءة، والفوائد الخاصة بالمهام، والطبيعة التكميلية للتكنولوجيا، الإمكانية لـ
اعتماد واسع النطاق. ومع ذلك، تبرز المخاوف المتعلقة بقابلية التطبيق المحدودة والجودة أهمية معالجة هذه القيود لتعزيز الفائدة المدركة وبالتالي قبول LLMs. يتماشى هذا التحليل مع إطار نموذج قبول التكنولوجيا، الذي يؤكد أن الفائدة المدركة هي محدد حاسم لقبول التكنولوجيا [29].

في هذا القسم الفرعي، نقدم نتائج تحليلنا النوعي لبيانات استبيان الأسئلة، مع تسليط الضوء على العوامل الرئيسية التي تؤثر على سهولة استخدام نماذج اللغة الكبيرة في هندسة البرمجيات. يعتمد تحليلنا على إطار عمل نموذج قبول التكنولوجيا [29]، الذي يفترض أن سهولة الاستخدام المدركة والفائدة المدركة هما محددان أساسيان لتبني التكنولوجيا. لقد حددنا عدة أبعاد مجمعة تفسر سهولة استخدام نماذج اللغة الكبيرة ونقدمها في أقسام فرعية منفصلة، مع تقديم أدلة تجريبية من بيانات استبيان الأسئلة (الجدول 2).
4.2.1 عملية التعلم. يكشف تحليلنا أن عملية التعلم هي عامل حاسم يؤثر على سهولة استخدام نماذج اللغة الكبيرة في هندسة البرمجيات. كما هو موضح في الجدول 2، أفاد R-54 بأنه “بمجرد أن تعودت على التكنولوجيا، أصبح من الأسهل بكثير استخدامها.” يتماشى هذا الاكتشاف مع نموذج قبول التكنولوجيا المقترح من قبل [29]، الذي يقترح أن سهولة الاستخدام المدركة للتكنولوجيا مرتبطة مباشرة بتبنيها. علاوة على ذلك، أكدت الأبحاث السابقة على دور
التعلم في تبني التقنيات الجديدة [110]. في هذا السياق، يبدو أن منحنى التعلم المرتبط بنماذج اللغة الكبيرة هو محدد أساسي لسهولة استخدامها المدركة.
4.2.2 الخبرة السابقة. تؤكد بيانات استبيان الأسئلة أيضًا على أهمية الخبرة السابقة في تشكيل سهولة استخدام نماذج اللغة الكبيرة. على سبيل المثال، ذكر R-20 أنه “أعتقد أنه سهل عندما تعرف المفاهيم المختلفة.” يتماشى هذا الملاحظة مع الأدبيات حول تبني التكنولوجيا، التي تقترح أن الأفراد الذين لديهم خبرة سابقة في تقنيات ذات صلة هم أكثر عرضة لرؤية التكنولوجيا الجديدة على أنها سهلة الاستخدام [24]. في حالة نماذج اللغة الكبيرة، يمكن أن يسهل وجود خلفية في لغات البرمجة أو معالجة اللغة الطبيعية (NLP) تبنيها في هندسة البرمجيات.
4.2.3 الفروق الفردية. موضوع رئيسي آخر ظهر من تحليلنا هو دور الفروق الفردية في تشكيل سهولة استخدام نماذج اللغة الكبيرة. كما أشار R-9، “يعتمد ذلك على الشخص وكيف اعتادوا على العمل.” يدعم هذا الاكتشاف الفكرة القائلة بأن الخصائص الفردية، مثل أسلوب التفكير والابتكار الشخصي، يمكن أن تؤثر على سهولة استخدام التكنولوجيا المدركة [94]. في سياق نماذج اللغة الكبيرة، قد يعتمد مدى رؤية مهندسي البرمجيات لها على أنها سهلة الاستخدام على تفضيلاتهم الفريدة، وأنماط التعلم، وطرق حل المشكلات.
4.2.4 الحدسية وواجهة المستخدم. كانت الحدسية لنماذج اللغة الكبيرة وتصميم واجهة المستخدم الخاصة بها أيضًا عوامل مهمة في تحليلنا. على سبيل المثال، ذكر R-89 أن “تم تصميمها بشكل أساسي لتكون سهلة الاستخدام من قبل المستهلك العادي.” يتماشى هذا الملاحظة مع عمل [69]، الذي جادل بأن واجهة المستخدم المصممة بشكل جيد يمكن أن تعزز بشكل كبير سهولة استخدام التكنولوجيا المدركة. في حالة نماذج اللغة الكبيرة، يمكن أن تسهل واجهة مستخدم حدسية وسهلة الاستخدام تبنيها بين مهندسي البرمجيات.
4.2.5 تعقيد المهام. أخيرًا، يبدو أن تعقيد المهام التي تستخدم من أجلها نماذج اللغة الكبيرة في هندسة البرمجيات يؤثر على سهولة استخدامها المدركة. كما أشار R-53، “يمكن أن يختلف صعوبة تعلم كيفية استخدامها بشكل فعال حسب كيفية استخدامك لها، ولكن في الغالب، يتراوح من ليس صعبًا جدًا إلى صعب جدًا.” يتماشى هذا الاكتشاف مع نموذج ملاءمة المهمة والتكنولوجيا [41]، الذي يفترض أن الملاءمة بين التكنولوجيا والمهمة التي تهدف إليها تؤثر على سهولة الاستخدام المدركة للتكنولوجيا، وفي النهاية، على تبنيها. في سياق نماذج اللغة الكبيرة، يبدو أن مهندسي البرمجيات قد يجدونها أسهل للاستخدام في مهام معينة، بينما قد تتطلب مهام أخرى مستوى أعلى من الخبرة والمعرفة.

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

لقد تم استخدام نموذج قبول التكنولوجيا على نطاق واسع لفهم العوامل التي تؤثر على تبني التقنيات الجديدة في سياقات مختلفة، مثل هندسة البرمجيات [30،110]. وفقًا لنموذج قبول التكنولوجيا، فإن النية السلوكية، التي تعكس احتمال استخدام الفرد لتكنولوجيا معينة، تتأثر بعاملين رئيسيين: الفائدة المدركة وسهولة الاستخدام المدركة [30]. في هذا القسم الفرعي، نستكشف النية السلوكية لمهندسي البرمجيات فيما يتعلق بـ

اعتماد نماذج اللغة الكبيرة، مع التركيز على الأبعاد الإجمالية التي ظهرت من التحليل المنفذ (الجدول 3).
4.3.1 تحسين الكود والصيانة. أشار جزء كبير من مهندسي البرمجيات إلى نيتهم استخدام نماذج اللغة الكبيرة لتحسين وصيانة قاعدة الشيفرة الخاصة بهم. يتماشى هذا الاكتشاف مع مفهوم الفائدة المدركة في نموذج قبول التكنولوجيا، حيث يمكن أن يؤدي استخدام نماذج اللغة الكبيرة في إعادة هيكلة الكود، والالتزام بأنماط التصميم، وتنفيذ مبادئ SOLID إلى تحسين جودة البرمجيات وقابلية الصيانة. على سبيل المثال، ذكر R-8: “أفكر في شراء اشتراك في ChatGPT-4، بشكل أساسي لإعادة هيكلة (الكود القديم) أو لجعله يتماشى مع أنماط تصميم معينة. يمكن أن يساعد أيضًا في إعادة هيكلة الكود لجعله أكثر توافقًا مع مبادئ SOLID.” تسلط هذه الاقتباس الضوء على القيمة المحتملة لنماذج اللغة الكبيرة في معالجة التحديات الشائعة في هندسة البرمجيات.
4.3.2 الكفاءة والأتمتة. تم اعتبار نماذج اللغة الكبيرة مفيدة لأتمتة المهام المتكررة وزيادة الكفاءة. تتوافق هذه النظرة مع كل من الفائدة المدركة وسهولة الاستخدام المدركة في نموذج قبول التكنولوجيا، حيث يمكن أن تؤدي أتمتة المهام إلى توفير الوقت وتبسيط عملية التطوير. قال R-35: “أعتقد أنني قد أبدأ في استخدام نموذج لغة بشكل متزايد، خاصة لأتمتة المهام التي يمكن أن يؤديها نموذج اللغة والتي تستغرق وقتًا كبيرًا.” يمكن أن يؤدي اعتماد نماذج اللغة الكبيرة لأتمتة المهام إلى تحسين إنتاجية مهندسي البرمجيات.
4.3.3 التعلم وحل المشكلات. كان استخدام نماذج اللغة الكبيرة للتعلم وحل المشكلات موضوعًا آخر تم تحديده، وهو متماشي مع الفائدة المدركة لنموذج قبول التكنولوجيا. أعرب مهندسو البرمجيات عن نيتهم في استخدام نماذج اللغة الكبيرة لمهام مثل العثور على الوثائق، وتوضيح الشيفرة المربكة، والبحث عن معلومات حول الأسئلة المتعلقة بالبرمجة. كما ذكر R-25، “من المحتمل جدًا. في الغالب للعثور على الوثائق الخاصة بالمكتبات، وإعادة هيكلة وتوضيح الشيفرة المربكة.” يمكن أن تكون نماذج اللغة الكبيرة أداة قيمة للتعلم وحل المشكلات لمهندسي البرمجيات، تدعم التطوير المهني المستمر.
4.3.4 التطبيقات المتخصصة. ذكر المستجيبون الاستخدام المحتمل لنماذج اللغة الكبيرة لمهام محددة، مثل كتابة الوظائف الأساسية، وتحديد المهام، وصياغة الرسائل الإلكترونية. يرتبط هذا الموضوع بالفائدة المتصورة لنماذج اللغة الكبيرة في تلبية احتياجات معينة في هندسة البرمجيات. على سبيل المثال، ذكر R-62، “من المحتمل جدًا. لكتابة الوظائف الأساسية، وتحديد المهام، وللرسائل الإلكترونية.
يمكن أن يوفر اعتماد نماذج اللغة الكبيرة (LLMs) لتطبيقات متخصصة فوائد مستهدفة لمهندسي البرمجيات في عملهم اليومي.
4.3.5 حواجز القبول والمخاوف. على الرغم من الفوائد المحتملة لنماذج اللغة الكبيرة، أعرب بعض مهندسي البرمجيات عن مخاوف وحواجز أمام القبول، مثل التكلفة، والاعتماد على خدمات الطرف الثالث، والمشاكل الأخلاقية المحتملة. تتماشى هذه المخاوف مع مفهوم سهولة الاستخدام المدركة في نموذج قبول التكنولوجيا، حيث يمكن أن تعيق اعتماد نماذج اللغة الكبيرة [110]. على سبيل المثال، ذكر R-60: “قد تكون التكلفة والاعتماد على خدمة طرف ثالث مصدر قلق.” فهم هذه المخاوف ومعالجتها أمر ضروري لتعزيز اعتماد نماذج اللغة الكبيرة في هندسة البرمجيات.

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

تعتبر ملاءمة نماذج اللغة الكبيرة في هندسة البرمجيات عاملاً حاسماً في فهم اعتمادها وتأثيرها على ممارسات تطوير البرمجيات. تشير الملاءمة إلى الدرجة التي يُنظر بها إلى الابتكار على أنه متسق مع القيم الحالية، والخبرات السابقة، واحتياجات المحتملين من المتبنين. تقدم هذه الفقرة تحليلًا موضوعيًا لملاءمة نماذج اللغة الكبيرة في هندسة البرمجيات استنادًا إلى ردود مهندسي البرمجيات، والتي تم تلخيصها في الجدول 4. لقد حددنا أربعة أبعاد مجمعة، كما هو موضح في الفقرات الفرعية التالية: تحسين الكفاءة، المساعدة والدعم، التشابه مع الممارسات الحالية، والتكيف والتعلم.
4.4.1 تحسين الكفاءة. كان تحسين الكفاءة هو الموضوع الأكثر تكرارًا في البيانات، مع من الاستجابات التي تعكس هذا الجانب من التوافق. يُنظر إلى استخدام نماذج اللغة الكبيرة (LLMs) في مهام هندسة البرمجيات على أنه يُسرع من عملية التطوير، ويُؤتمت المهام الروتينية، وفي النهاية يُحسن الكفاءة العامة. أشار أحد المستجيبين (R-19) إلى أن نماذج اللغة الكبيرة “يمكن استخدامها لأتمتة بعض المهام في هندسة البرمجيات”، مما يقلل من الوقت والجهد المبذولين في المهام المتكررة. وبالمثل، أشار R-35 إلى أن استخدام نموذج اللغة “سيسرع من مهام البحث عن قطع محددة من الشيفرة من مواقع متعددة.” تتماشى هذه النتائج مع الأدبيات، حيث يُعتبر التوافق عاملاً رئيسياً في اعتماد التكنولوجيا [105].
4.4.2 المساعدة والدعم. ظهرت المساعدة والدعم كأكثر الموضوعات تكرارًا في البيانات، حيث تمثل من الردود. أشار المستجيبون إلى قيمة نماذج اللغة الكبيرة في تقديم المساعدة والدعم، خاصة في الحالات التي تفشل فيها طرق البحث التقليدية في تقديم النتائج المرغوبة. ذكر R-1 أن نماذج اللغة الكبيرة يمكن أن توفر “يدًا إضافية ومساعدة للأشياء التي لا أعرفها ولا أستطيع العثور عليها باستخدام بحث تقليدي.” وهذا يدل على أن قدرة نماذج اللغة الكبيرة على تقديم المساعدة ذات الصلة والسياقية تعتبر جانبًا مهمًا من توافقها مع ممارسات هندسة البرمجيات.
4.4.3 التشابه مع الممارسات الحالية. تم الإبلاغ عن التشابه مع الممارسات الحالية من قبل من المستجيبين. يشير هذا الموضوع إلى أن اعتماد نماذج اللغة الكبيرة في هندسة البرمجيات يسهل من خلال تشابهها المدرك مع الأدوات والممارسات الحالية. أشار R-15 إلى أنه “لا يوجد فرق كبير حيث يتم استخدام نموذج اللغة فقط لمساعدتي في ممارسات هندسة البرمجيات الحالية.” كما ذكر R-5 أن استخدام نماذج اللغة الكبيرة “يشبه البحث في جوجل لكنني لا أحتاج إلى تصفية الكثير من المعلومات.” يمكن أن يؤثر التشابه المدرك مع الممارسات الحالية على اعتماد نماذج اللغة الكبيرة حيث يقلل من الحواجز أمام دمجها في سير العمل الحالي [85، 105].
4.4.4 التكيف والتعلم. تم الإبلاغ عن التكيف والتعلم من قبل من المستجيبين. يبرز هذا الموضوع أهمية التعلم والتكيف مع الأدوات والتقنيات الجديدة في مجال هندسة البرمجيات. أعرب R-46 عن أن استخدام نماذج اللغة الكبيرة هو “شيء جديد: عليك أن تتعلم كيفية استخدامه.” وبالمثل، ذكر R-87 أن استخدام نموذج اللغة “يمثل نموذجًا جديدًا لـ .” يشير هذا الموضوع إلى أن توافق نماذج اللغة الكبيرة في هندسة البرمجيات يمكن أن يتحسن من خلال تعزيز التعلم والتكيف بين مهندسي البرمجيات. وبالتالي، يمكن تسهيل اعتماد نماذج اللغة الكبيرة من خلال توفير الموارد والتدريب لمساعدة المهندسين على فهم ودمج هذه الأدوات في عملهم اليومي.

في الختام، استكشفت هذه الفقرة توافق نماذج اللغة الكبيرة في هندسة البرمجيات من خلال تحليل الأبعاد المجمعة المستمدة من ردود مهندسي البرمجيات. توفر هذه الأبعاد – تحسين الكفاءة، المساعدة والدعم، التشابه مع الممارسات الحالية، والتكيف والتعلم – فهمًا شاملاً للعوامل التي تؤثر على توافق نماذج اللغة الكبيرة في هندسة البرمجيات. من خلال ربط هذه الأبعاد بنظرية انتشار الابتكار [85]، تقدم هذه التحليل رؤى قيمة حول العوامل التي تسهم في اعتماد ودمج نماذج اللغة الكبيرة في ممارسات هندسة البرمجيات. يمكن أن يساعد هذا الفهم في توجيه تطوير نماذج اللغة الكبيرة التي تتوافق بشكل أكبر مع سير العمل والممارسات الحالية، مما يؤدي في النهاية إلى اعتماد واستخدام أوسع في مجال هندسة البرمجيات.

يعتبر تعقيد اعتماد نماذج اللغة الكبيرة في هندسة البرمجيات جانبًا حاسمًا لفهم انتشارها وتأثيرها على الصناعة. وفقًا لنظرية انتشار الابتكار، يؤثر تعقيد الابتكار على معدل اعتماده، حيث تواجه الابتكارات الأكثر تعقيدًا معدل اعتماد أبطأ [85]. التحليل الموضوعي لبيانات استبيان الاستطلاع (الجدول 5)

يكشف عن عدة أبعاد مجمعة تسهم في التعقيد المدرك لنماذج اللغة الكبيرة في هندسة البرمجيات. في هذه الفقرة، نناقش كل من هذه الأبعاد وآثارها على اعتماد نماذج اللغة الكبيرة، وربطها بالأدبيات ذات الصلة ونظرية انتشار الابتكار.
4.5.1 مخاوف أمن الوظائف. ظهرت مخاوف فقدان الوظائف وتخفيض قيمة المهارات كقضية مهمة بين المستجيبين ( التكرار). ذكر المستجيب R-15، “أنا قلق من أنه يمكن أن يؤتمت الكثير من المهام ويجعل معظم عملي عتيقًا.” يتماشى هذا المنظور مع الأبحاث حول الآثار المدمرة المحتملة للذكاء الاصطناعي والأتمتة على سوق العمل [35]. وفقًا لنظرية انتشار الابتكار، من المحتمل أن تواجه الابتكارات التي يُنظر إليها على أنها تهدد أمن الوظائف مقاومة [85]. للتخفيف من هذه التحديات، يجب على المنظمات التواصل بشأن فوائد نماذج اللغة الكبيرة والتركيز على تطوير مهارات الموظفين [12،101].
4.5.2 الاعتماد والركود. أعرب بعض المستجيبين ( التكرار) عن مخاوف بشأن اعتماد المبرمجين المبتدئين بشكل مفرط على نماذج اللغة الكبيرة، مما يؤدي إلى تراجع فهم الشيفرة وزيادة الاعتماد على هذه النماذج. أوضح المستجيب R-34، “قلقي هو أن المبرمجين المبتدئين الآخرين يستخدمونها دون فهم الشيفرة مما يسبب أخطاء (مزيد من العمل بالنسبة لي).” يمكن معالجة هذه التحديات من خلال تعزيز الاستخدام المسؤول لنماذج اللغة الكبيرة وضمان أن يكون لدى المبرمجين أساس قوي في مفاهيم البرمجة.
4.5.3 أمان البيانات والخصوصية. تم تحديد مخاوف أمان البيانات والخصوصية من قبل من المستجيبين. أعربوا عن مخاوف بشأن تدريب نماذج اللغة الكبيرة على بيانات حساسة، مما قد يؤدي إلى انتهاكات للخصوصية. ذكر المستجيب R-17، “من حيث الخصوصية، حيث يمكن تدريب نماذج اللغة على بيانات حساسة أو شخصية، مثل الرسائل الإلكترونية، والرسائل، أو الوثائق. قد يثير هذا مخاوف بشأن الخصوصية وحماية البيانات.” لمعالجة هذه القضية، يجب على المطورين ضمان تدريب نماذج اللغة الكبيرة على مجموعات بيانات آمنة ومجهولة الهوية وأن يتم اتباع لوائح الخصوصية.
4.5.4 جودة ودقة الشيفرة المولدة. كما أعرب المستجيبون عن مخاوف بشأن جودة ودقة الشيفرة المولدة بواسطة نماذج اللغة الكبيرة (13% تكرار). علق المستجيب R-49، “نماذج اللغة ليست مثالية، لذا سأكون خائفًا من أنها قد تسبب أخطاء.” إن ضمان موثوقية ودقة الشيفرة المولدة أمر ضروري لاعتماد نماذج اللغة الكبيرة [81]. لمعالجة هذه القضية، يجب على المطورين وضع أفضل الممارسات لمراجعة الشيفرة والتحقق منها، بالإضافة إلى الاستثمار في تحسين أداء النماذج [115].
4.5.5 الاعتبارات الأخلاقية والقانونية. تم تحديد الاعتبارات الأخلاقية والقانونية، مثل حقوق التأليف وحقوق الملكية الفكرية، من قبل من المستجيبين. ذكر المستجيب R-28 ببساطة، “حقوق المؤلف من الصعب نسبها.” يجب على المنظمات النظر في الآثار الأخلاقية لاستخدام نماذج اللغة الكبيرة ووضع إرشادات لاستخدامها لضمان الامتثال للقوانين واللوائح الحالية [64].
4.5.6 التحيز وقابلية التفسير. أشار بعض المستجيبين ( التكرار) إلى مخاوف بشأن التحيزات المحتملة في النتائج وغياب قابلية التفسير في عمليات اتخاذ القرار الخاصة بهم. أعرب المستجيب R-62 عن رأيه، “يمكن أن يكون للتحيزات في النموذج عواقب غير مقصودة.” من الضروري معالجة هذه القضايا لضمان الاستخدام المسؤول لنماذج اللغة الكبيرة في هندسة البرمجيات. يمكن للمنظمات الاستثمار في البحث لتقليل التحيزات وتحسين قابلية تفسير نماذج اللغة الكبيرة لتعزيز موثوقيتها واعتمادها [7].
4.5.7 التكامل والتوافق. تم ذكر قضايا التكامل والتوافق من قبل المستجيبين، الذين أعربوا عن مخاوف بشأن قدرة نماذج اللغة الكبيرة على العمل بسلاسة مع أدوات وممارسات تطوير البرمجيات الحالية. صرح المستجيب R-21، “قد يكون من الصعب دمج النموذج في سير العمل الحالي.” لتسهيل اعتماد نماذج اللغة الكبيرة، يجب على المطورين التأكد من أن هذه النماذج متوافقة مع الأدوات الحالية ويمكن دمجها بسهولة في عملية تطوير البرمجيات.

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

الميزة النسبية لنماذج اللغة الكبيرة في هندسة البرمجيات هي عامل رئيسي في اعتمادها، كما افترضت نظرية انتشار الابتكار [85]. يبرز تحليل بياناتنا النوعية، المستند إلى منهجية جيويا، الجوانب المختلفة لنماذج اللغة الكبيرة التي تسهم في فوائدها المدركة مقارنة بالطرق الحالية. تقدم الفقرات الفرعية التالية الأبعاد المجمعة المستمدة من تحليلنا وتناقش آثارها فيما يتعلق بمفهوم الميزة النسبية (الجدول 6).
4.6.1 كفاءة الوقت. كان موضوعًا متكررًا في تحليلنا هو كفاءة الوقت التي توفرها نماذج اللغة الكبيرة، كما أفاد من المستجيبين. قدر المستجيبون قدرة نماذج اللغة الكبيرة على إكمال المهام بسرعة، والبحث عن المعلومات ذات الصلة، وتقديم حلول لمشكلات البرمجة. على سبيل المثال، أشار R-25 إلى أن نماذج اللغة الكبيرة قللت بشكل كبير من الوقت المستغرق في البحث عن المعلومات: “أعتقد أن أفضل شيء هو أن الوقت المستغرق في البحث عن أشياء معينة أقل بكثير مما كان عليه من قبل.” يمكن أن تُعزى هذه الكفاءة الزمنية إلى قدرات معالجة اللغة الطبيعية لنماذج اللغة الكبيرة، والتي تمكن المستخدمين من التواصل بشكل أكثر فعالية والحصول بسرعة على حلول مخصصة [14].
4.6.2 جودة الكود. ظهرت تحسينات في جودة الكود كميزة رئيسية أخرى لنماذج اللغة الكبيرة، حيث أشار من المستجيبين إلى التأثير الإيجابي على عملهم. أفاد المستجيبون أن نماذج اللغة الكبيرة قدمت كودًا أكثر وضوحًا وفهمًا، مما قلل من الأخطاء وحسن من متانة الكود بشكل عام. صرح R-37: “إنها تولد كودًا أبسط وأكثر فهمًا، وتعمل بطريقة أكثر تنظيمًا وتقلل من الأخطاء.” هذا التحسين في جودة الكود هو نتيجة لقدرة نماذج اللغة الكبيرة على تحليل والتعلم من كميات هائلة من كود المصدر، مما يسمح لها بتقديم حلول مثلى بناءً على أفضل الممارسات [31].
4.6.3 تجربة المستخدم. لوحظ أن نماذج اللغة الكبيرة تعزز تجربة المستخدم العامة، حيث أشار من المستجيبين إلى سهولة الاستخدام والتواصل مع النماذج. علق R-67 على التفاعل الشبيه بالبشر: “نماذج اللغة أسهل في الاستخدام وأسرع لأنك تستطيع إرسال رسائل كما لو كنت تتحدث إلى إنسان.” يمكن أن تُعزى تجربة المستخدم المحسنة إلى قدرات فهم اللغة الطبيعية لنماذج اللغة الكبيرة، والتي تسمح لها بتفسير والرد على مدخلات المستخدم بشكل أكثر فعالية من الطرق التقليدية [78].
4.6.4 التعلم وتطوير المهارات. وُجد أيضًا أن نماذج اللغة الكبيرة تسهل التعلم وتطوير المهارات، كما أفاد من المستجيبين. قدر المستجيبون قدرة نماذج اللغة الكبيرة على تبسيط عملية التعلم وتقليل الوقت المستغرق في إتقان المفاهيم التقنية. أوضح R-23: “أعتقد أنه مع نماذج اللغة الكبيرة لا تحتاج إلى قضاء الكثير من الوقت في تعلم الأشياء ‘التقنية’.” يمكن ربط ذلك بقدرات الفهم السياقي والاحتفاظ بالمعرفة لنماذج اللغة الكبيرة، والتي تسمح لها بتقديم إرشادات ودعم مخصص للمستخدمين بمستويات خبرة متنوعة.
4.6.5 التخصيص والتخصيص الشخصي. أخيرًا، تم تسليط الضوء على التخصيص والتخصيص الشخصي كميزات من قبل من المستجيبين. تم الإشادة بنماذج اللغة الكبيرة لقدرتها على تقديم معلومات أكثر قابلية للهضم وتكييف الردود وفقًا لتفضيلات المستخدم. وصف R-94 مرونة نماذج اللغة الكبيرة: “إنها تقدم معلومات أكثر هضمًا، ويمكننا ‘تشكيل’ المعلومات كما نريد (مثل، طلب من نموذج اللغة الرد باستخدام جمل قصيرة، أو الشرح بالتفصيل حول مواضيع معينة، إلخ).” يمكن أن يُعزى هذا الجانب من نماذج اللغة الكبيرة إلى قدرتها على فهم السياق وتفضيلات المستخدم، مما يسمح لها بتوليد ردود أكثر صلة وتخصيصًا [72].

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

تتأثر اعتماد نماذج اللغة الكبيرة في هندسة البرمجيات بعوامل مختلفة. أحد العوامل الرئيسية هو التأثير الاجتماعي من الأقران والزملاء، كما اقترحت نظرية الإدراك الاجتماعي [9]. تهدف التحليل الحالي إلى تقديم مبرر حول كيفية تفسير البيانات لـ “التأثير الاجتماعي” فيما يتعلق باعتماد نماذج اللغة الكبيرة في هندسة البرمجيات وكيف يرتبط بالإطار النظري لنظرية الإدراك الاجتماعي. كشف تحليلنا (الجدول 7) عن أربعة أبعاد مجمعة تمثل نطاق التأثيرات الاجتماعية في اعتماد نماذج اللغة الكبيرة: لا تأثير، تأثير منخفض، تأثير معتدل، وتأثير عالي.
4.7.1 لا تأثير. كشف تحليلنا أن من المستجيبين أفادوا بعدم وجود تأثير من زملائهم أو أقرانهم على قرارهم باستخدام نماذج اللغة الكبيرة (مثل: R-66، R-24، R-58). تشير هذه النتيجة إلى أن نسبة كبيرة من مهندسي البرمجيات يتخذون قرارات مستقلة بشأن ما إذا كانوا سيعتمدون نماذج اللغة الكبيرة. يتماشى هذا مع الأدبيات حول الوكالة الفردية والكفاءة الذاتية في نظرية الإدراك الاجتماعي [10]. قد يعتمد هؤلاء المهندسون على تقييمهم الخاص للتكنولوجيا والتفضيلات الشخصية، بدلاً من آراء أو تجارب زملائهم.
4.7.2 تأثير منخفض. تم الإبلاغ عن تأثير منخفض من قبل من المستجيبين (مثل: R-45، R-99). يشير هذا إلى أن بعض مهندسي البرمجيات قد يتأثرون قليلاً بأقرانهم، لكنهم يحتفظون في النهاية بدرجة عالية من الاستقلالية في اتخاذ القرار. تشير هذه النتيجة إلى أنه بينما قد يلعب التأثير الاجتماعي دورًا في اعتماد نماذج اللغة الكبيرة، فإن العوامل الفردية، مثل الاهتمام الشخصي والفائدة المدركة، قد تساهم أيضًا بشكل كبير في عملية اتخاذ القرار [5].
4.7.3 تأثير معتدل. كشف تحليلنا أن من المستجيبين أفادوا بتأثير معتدل من أقرانهم وزملائهم (مثل: R-9، R-82). يشير هذا إلى أن نسبة كبيرة من مهندسي البرمجيات يقدرون مدخلات وتعليقات أقرانهم عند اتخاذ قرار بشأن اعتماد

نماذج اللغة الكبيرة. تتماشى هذه النتيجة مع نظرية الإدراك الاجتماعي، التي تؤكد على دور التعلم بالملاحظة والتجارب غير المباشرة في تشكيل سلوك الأفراد [9]. في سياق اعتماد نماذج اللغة الكبيرة، قد ينتج هذا التأثير المعتدل عن مزيج من العوامل الفردية وتجارب الزملاء.
4.7.4 تأثير عالي. أخيرًا، أفاد 26% من المستجيبين بتأثير عالي من أقرانهم وزملائهم (مثل: R-97، R-79، R-27). تشير هذه النتيجة إلى أن نسبة كبيرة من مهندسي البرمجيات تتأثر بشدة بالاستخدام الجماعي والحماس لنماذج اللغة الكبيرة ضمن دوائرهم المهنية. تتماشى هذه النتيجة مع تركيز نظرية الإدراك الاجتماعي على التفاعلات المتبادلة بين الأفراد وبيئتهم الاجتماعية، فضلاً عن الأدبيات حول اعتماد التكنولوجيا في المنظمات [85]. في هذه الحالة، قد ينبع مستوى التأثير العالي من الفوائد المدركة لنماذج اللغة الكبيرة، والتعاون، والحماس المشترك لاستكشاف إمكانيات التكنولوجيا.

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

تشير الكفاءة الذاتية، وهي بناء أساسي ضمن نظرية الإدراك الاجتماعي، إلى اعتقاد الفرد في قدرته على أداء مهام معينة وتحقيق النتائج المرغوبة [10]. في سياق هندسة البرمجيات، يمكن أن تؤثر الكفاءة الذاتية للمطورين الذين يستخدمون نماذج اللغة الكبيرة على اعتمادهم واستخدامهم الفعال. بناءً على تحليلنا الموضوعي، حددنا ثلاثة أبعاد مجمعة تساهم في فهم الكفاءة الذاتية فيما يتعلق باعتماد نماذج اللغة الكبيرة: (1) أهمية أن يُنظر إليك على أنك متقدم، (2) التركيز على العملية والكفاءة، و(3) أهمية منخفضة لأن يُنظر إليك على أنك
يُنظر إليك على أنك متقدم. ستتم مناقشة هذه الأبعاد بالتفصيل في الفقرات الفرعية التالية، مع تسليط الضوء على دورها في تشكيل كفاءة المطورين الذاتية وسلوك اعتمادهم لنماذج اللغة الكبيرة في هندسة البرمجيات. يمكن العثور على هيكل البيانات في الجدول 8.
4.8.1 أهمية أن يُنظر إليك على أنك متقدم. كما هو موضح في الجدول، أشار عدد من المستجيبين إلى أهمية أن يُنظر إليهم كشخص يستخدم التكنولوجيا المتطورة في عمله. تتماشى هذه النظرة مع مفهوم الكفاءة الذاتية، حيث يميل المطورون الذين يعتبرون أنفسهم بارعين في أحدث التقنيات إلى أن يكون لديهم ثقة أعلى في قدراتهم [24]. على سبيل المثال، أعرب R-2 عن أن البقاء على اطلاع بأحدث التقنيات أمر حاسم في مجاله، وذكر R-30 الخوف من أن يتم استبداله بشخص يُنظر إليه على أنه أكثر كفاءة في التكنولوجيا المتطورة. قد يشجع هذا التركيز على البقاء على اطلاع بالتطورات التكنولوجية المطورين على اعتماد نماذج اللغة الكبيرة لإظهار خبراتهم والحفاظ على ميزة تنافسية في الصناعة [110].
4.8.2 التركيز على العملية والكفاءة. كشفت تحليلاتنا أن عدد من المستجيبين أبرزوا أهمية العملية والكفاءة في عملهم، مما يدل على تفضيل استخدام التقنيات التي تحل المشكلات أو تلبي احتياجات العملاء بشكل فعال، بدلاً من أن تكون ببساطة متطورة. يعكس هذا التركيز كفاءة ذاتية أكثر توجهاً نحو المهام، حيث يركز المطورون على إيجاد الأدوات الأكثر ملاءمة للوظيفة. على سبيل المثال، أكد R-10 على أهمية البقاء في المقدمة وتقديم حلول مبتكرة لتلبية احتياجات العملاء المتطورة، بينما ذكر R-19 وR-100 التوازن بين اعتماد التقنيات المتطورة وضمان الكفاءة في عملهم. يشير هذا إلى أن المطورين الذين يركزون على العملية والكفاءة سيتبنون نماذج اللغة الكبيرة فقط عندما يرون أن هذه النماذج توفر فوائد ملموسة لعملهم.
4.8.3 أهمية منخفضة لأن يُنظر إليهم على أنهم متطورون. مجموعة أصغر من المستجيبين ( ) أعطت أهمية منخفضة لأن يُنظر إليهم على أنهم يستخدمون التكنولوجيا المتطورة في عملهم. يفضل هؤلاء المطورون الاستقرار والفعالية أو عوامل أخرى على اعتماد أحدث التقنيات، مما قد يؤثر على كفاءتهم الذاتية من حيث اعتماد نماذج اللغة الكبيرة [104]. على سبيل المثال، أعرب R-21 عن تفضيله للاستقرار على تنفيذ التكنولوجيا المتطورة، وذكر R-66 أن تركيزه هو على استخدام الأدوات الأكثر فعالية للمهام المطروحة، بغض النظر عما إذا كانت متطورة. تشير هذه النتيجة إلى أن المطورين الذين يركزون بشكل منخفض على التكنولوجيا المتطورة قد يكونون أقل ميلاً لاعتماد نماذج اللغة الكبيرة ما لم تظهر فوائد واضحة مقارنة بالأدوات الحالية.

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

يتأثر اعتماد نماذج اللغة الكبيرة في هندسة البرمجيات بعدة عوامل بيئية تشكل سلوكيات المؤسسات وعمليات اتخاذ القرار. استنادًا إلى إطار نظرية التعلم الاجتماعي [9]، تحقق هذه الدراسة في كيفية تأثير العوامل البيئية على مدى دعم المؤسسات لاعتماد نماذج اللغة الكبيرة كتكنولوجيا قياسية. تقدم الأقسام التالية نتائج تحليلنا الموضوعي، الذي كشف عن خمسة أبعاد مجمعة تتعلق بالعوامل البيئية: الموقف الداعم، الموقف المحايد، الدعم المشروط، الدعم المحدود، وغياب الدعم. يتم مناقشة كل بعد بالتفصيل مع الإشارة إلى البيانات المقدمة في الجدول 9.

4.9.1 الموقف الداعم. البعد المجمع الأكثر انتشارًا في بياناتنا، الموقف الداعم، يلتقط الموقف الإيجابي والاستباقي للمؤسسات في تعزيز اعتماد نماذج اللغة الكبيرة ( التكرار). يشمل هذا البعد تشجيعًا قويًا من المؤسسات واستثمارًا في التكنولوجيا لتسهيل دمجها في ممارسات هندسة البرمجيات [85]. يبرز المستجيب R-5، على سبيل المثال، الترويج النشط لنماذج اللغة الكبيرة من قبل مؤسستهم، مشيرًا إلى أنهم “يدفعون مقابلها ويشجعوننا على استخدامها.” وبالمثل، يذكر R-45 موقفًا “داعمًا جدًا”، مما يوضح مدى أولوية بعض المؤسسات لاعتماد نماذج اللغة الكبيرة.
4.9.2 الموقف المحايد. يعكس بعد الموقف المحايد المؤسسات التي لا تدعم ولا تعارض بنشاط اعتماد نماذج اللغة الكبيرة ( التكرار). قد يُعزى هذا الموقف إلى نقص الوعي أو المعرفة حول نماذج اللغة الكبيرة، أو نهج الانتظار والترقب لتقييم الفوائد والعيوب المحتملة للتكنولوجيا [54]. يصف المستجيب R-84 موقف مؤسستهم بأنه “محايد، يعود إلى الموظف”، مما يعني أن القرار باستخدام نماذج اللغة الكبيرة يُترك لتقدير الأفراد بدلاً من أن يكون موجهًا بسياسة المؤسسة.
4.9.3 الدعم المشروط. تظهر بعض المؤسسات في عيّنتنا بعد الدعم المشروط ( التكرار)، الذي يتميز باستعدادها لاعتماد نماذج اللغة الكبيرة بشرط تلبية معايير معينة، مثل أن تُظهر التكنولوجيا فوائد واضحة أو تتماشى مع أهداف مؤسسية محددة [85]. في هذا السياق، يشير R-26 إلى أن مؤسستهم تدعم اعتماد نماذج اللغة الكبيرة “إذا جلبت مزيدًا من المزايا للفريق وطريقة عملنا، وجعلت الأمور أسرع.”
4.9.4 الدعم المحدود. يمثل بعد الدعم المحدود ( التكرار) المؤسسات التي تدعم فقط استخدام نماذج اللغة الكبيرة في سياقات معينة أو لمهام معينة. قد تنشأ هذه المقاربة الانتقائية من مخاوف تتعلق بالأمان أو الخصوصية أو الاعتبارات الأخلاقية. على سبيل المثال، يوضح R-64 أن مؤسستهم “تعارضها عند العمل على ميزات جديدة ولكنها يمكن أن تكون مفيدة جدًا في تصحيح الأخطاء.”

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

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

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

تتأثر النية السلوكية لتبني نماذج اللغة الكبيرة في هندسة البرمجيات بالمنفعة المدركة، وسهولة الاستخدام المدركة، والتأثير الاجتماعي، والظروف الميسرة. تساهم هذه العوامل مجتمعة في خلق بيئة ملائمة للتكامل الناجح لنماذج اللغة الكبيرة في ممارسات هندسة البرمجيات.

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

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

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

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

في هذا القسم، نقدم إطار التعاون والتكيف بين الإنسان والذكاء الاصطناعي (HACAF)، وهو نموذج نظري مبتكر مصمم لفهم وتوقع اعتماد أدوات الذكاء الاصطناعي التوليدي في هندسة البرمجيات. يستمد HACAF مكوناته من عدة نظريات راسخة بما في ذلك نموذج قبول التكنولوجيا، نظرية انتشار الابتكار، النظرية الاجتماعية المعرفية، النظرية الموحدة لقبول واستخدام التكنولوجيا (UTAUT)، وبناء الابتكار الشخصي.

بينما توفر النظريات الأصلية TAM و DOI و SCT أسسًا نظرية قوية لفهم قبول التكنولوجيا واعتمادها، أظهرت تحقيقاتنا النوعية ضرورة وجود نموذج أكثر دقة. لذلك، فإن HACAF ليس مجرد دمج لهذه النظريات، بل هو أيضًا تطور، حيث يتضمن جوانب إضافية تم الكشف عنها في بحثنا.

إن تضمين المفاهيم من نموذج UTAUT يعالج الحاجة إلى تركيز أكبر على التأثير الاجتماعي وظروف التيسير، وهما عنصران ظهرا كعوامل مؤثرة بشكل كبير في نتائجنا النوعية. إن الدمج الإضافي لمفهوم الابتكار الشخصي في نموذج HACAF مدفوع بالتباين الملحوظ في سلوكيات التبني بين مهندسي البرمجيات، حتى ضمن نفس البيئة السياقية، مما يشير إلى دور الفروق الفردية في الاتجاهات الابتكارية.

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

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

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

تؤكد العوامل الاجتماعية، مستندة إلى نموذج UTAUT ومفهوم الكفاءة الذاتية في استخدام الحاسوب، على تأثير البيئة الاجتماعية واعتقاد الفرد في قدراته على استخدام نماذج اللغة الكبيرة (LLMs). تدعم نتائج التحقيق هذا البناء من خلال الإشارة إلى أن أهمية الظهور بمظهر متقدم وأن كفاءة المطور الذاتية يمكن أن تدفع إلى اعتماد نماذج اللغة الكبيرة. وقد برز دور موافقة الأقران والاعتقاد في كفاءة الفرد في إتقان نماذج اللغة الكبيرة كعوامل مؤثرة هامة، مما يعزز أهمية هذا البناء في نموذج HACAF.

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

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

تشكل الأسس النظرية في القسم السابق، المدعومة بالتحقيق النوعي، قاعدة لتفعيل إطار التعاون والتكيف بين الإنسان والذكاء الاصطناعي (HACAF). نقوم الآن بترجمة هذه المفاهيم النظرية إلى أربعة محددات رئيسية لنية استخدام نماذج اللغة الكبيرة (LLMs): التصورات حول التكنولوجيا، عوامل التوافق، العوامل الاجتماعية، والعوامل الشخصية والبيئية، ونضع فرضيات بناءً على هذه المفاهيم، كما هو موضح بشكل بياني في الشكل 1.

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

الفرضية. H1: ستؤدي التصورات الإيجابية حول التكنولوجيا (PT)، التي تشمل الفائدة المدركة، وسهولة الاستخدام، والميزة النسبية، إلى زيادة النية لاستخدام (IU) نماذج اللغة الكبيرة (LLMs) في سياق هندسة البرمجيات.

تتناول عوامل التوافق مدى توافق نماذج اللغة الكبيرة مع القيم والخبرات والاحتياجات الحالية للمستخدمين المحتملين. كما يبرز التحقيق النوعي، فإن نماذج اللغة الكبيرة

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

الفرضية. H2: ستعزز التصورات الإيجابية حول التكنولوجيا (PT) عوامل التوافق (CF). H3: ستؤدي عوامل التوافق المعززة (CF) بدورها إلى زيادة النية لاستخدام (IU) نماذج اللغة الكبيرة (LLMs).

تلعب العوامل الاجتماعية، التي تشمل التأثير الاجتماعي والفعالية الذاتية، دورًا مهمًا في قرارات التبني. أكدت دراستنا النوعية أن موافقة الأقران واعتقاد الفرد في قدرته على استخدام نماذج اللغة الكبيرة يمكن أن تؤثر بشكل كبير على نية استخدام هذه التقنيات. استنادًا إلى ذلك ونظرية القبول والاستخدام الموحدة للتكنولوجيا (UTAUT) ومفهوم الفعالية الذاتية في استخدام الكمبيوتر، نفترض:

الفرضية. H4: ستؤدي التصورات الإيجابية حول التكنولوجيا (PT) إلى زيادة العوامل الاجتماعية (SF). H5: ستعزز زيادة العوامل الاجتماعية (SF) النية لاستخدام (IU) نماذج اللغة الكبيرة (LLMs).

أخيرًا، تساهم العوامل الشخصية والبيئية، بما في ذلك الابتكار الشخصي والدعم التنظيمي، في تعقيد النموذج. كما أكدت تحقيقاتنا، فإن استعداد الفرد للتجربة مع نماذج اللغة الكبيرة (LLMs) والشعور بالدعم من المنظمة يمكن أن يكون حاسمًا في اعتماد نماذج اللغة الكبيرة. وبالتالي، نفترض:

الفرضية. H6: ستؤثر العوامل الشخصية والبيئية (PEF)، وبشكل خاص الابتكار الشخصي والدعم التنظيمي، على العلاقة بين التصورات حول التكنولوجيا.
وتعزيز التأثير الإيجابي لتصورات حول التكنولوجيا على نية استخدام نماذج اللغة الكبيرة.

في المرحلة التالية من بحثنا، انتقلنا من الرؤى النوعية التي تم الحصول عليها في الدراسة الأولية إلى التحقق الكمي. لعبت النتائج النوعية من دراستنا الأولية دورًا أساسيًا في تشكيل المراحل اللاحقة من بحثنا. كما استخدمنا هنا معيار SIGSOFT التجريبي لاستطلاعات الاستبيانات والبحث متعدد المنهجيات والطرق المختلطة [79].

النمذجة الهيكلية باستخدام المربعات الصغرى الجزئية (PLS-SEM): تم اختيار هذه الطريقة بناءً على قدرتها على التحقق من صحة النماذج المعقدة، خاصة عندما يكون البحث في مرحلة استكشافية، كما هو الحال في دراستنا حول ديناميات اعتماد أدوات الذكاء الاصطناعي التوليدي في هندسة البرمجيات.

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

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

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

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

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

النمذجة الهيكلية باستخدام المربعات الصغرى الجزئية (PLS-SEM) هي فحص إحصائي متعدد الأوجه مصمم لدعم المتغيرات الكامنة وغير المرئية (أو البنى) من خلال مؤشرات قابلة للرصد متعددة. هذه الطريقة مفيدة بشكل خاص لدراسات تطوير النظرية وتزداد اعتمادًا في هندسة البرمجيات التجريبية [91]. يمكن أن تتناول PLS-SEM استفسارات بحثية متعددة مترابطة في تحليل شامل واحد، مما يجعلها خيارًا شائعًا في مجالات أخرى مثل الإدارة، وبحوث نظم المعلومات، وسلوك المنظمات. كما يقترح جيفن وآخرون، يتم استخدام SEM عادةً للتحقق من صحة الأدوات والتحقق من الروابط بين البنى [37]. تلتزم التقييمات والتحليلات اللاحقة لنموذج PLS-SEM بأحدث الإرشادات والتوصيات للبحث في هندسة البرمجيات من قبل روسو وستول [91].
6.1.1 تطوير المقياس. تم إعداد الاستبيان بمساعدة نظرية إضافية. قمنا بتنظيم استبياننا من خلال تكييف الأدوات من الأبحاث السابقة. جميع العناصر المستخدمة لتعريف كل بنية والمراجع المستخدمة لتشكيل الأسئلة ملخصة في الجدول 20. تم تقييم كل بنية من خلال عناصر أحادية البعد على مقياس ليكرت من 7 نقاط تشير إلى مستويات الاتفاق.

في البداية، تم إجراء اختبار مسبق مع ثلاثة مستجيبين محتملين (مهندسي برمجيات) لتقييم قابلية استخدام الاستبيان، والتفكير، وصياغة الأسئلة. تلقت قابلية الاستخدام تعليقات إيجابية، وتم تحديد بعض القضايا الطفيفة في التفكير والصياغة وتم معالجتها لاحقًا.
6.1.2 جمع بيانات الاستبيان. تم تحديد الحد الأدنى لحجم العينة من خلال إجراء تحليل قوة مسبق باستخدام G*Power. مع حجم تأثير قدره ، مستوى دلالة عند ، وقوة قدرها ، فإن أصغر حجم مطلوب لسبعة متنبئين هو 153.

تم استخدام استراتيجية أخذ عينات عنقودية لجمع البيانات، تم تسهيلها من خلال منصة جمع البيانات الأكاديمية، Prolific. تم تسليم الاستبيان عبر Qualtrics، مع عشوائية ترتيب الأسئلة داخل كتلها لتقليل انحياز الاستجابة.

تم تنفيذ عملية فحص متعددة المراحل لضمان سلامة البيانات المجمعة. تم جمع البيانات بين أبريل ويونيو 2023.

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

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

فحص الجودة والكفاءة. لضمان دقة مجموعتنا، أضفنا سؤال فحص واحد فقط في استبياننا من دانيلوفا وآخرون [28]، يسأل “أي من هذه المواقع تستخدمه بشكل متكرر كوسيلة مساعدة عند البرمجة؟” مع ‘Stack Overflow’ كالسؤال الصحيح. بالإضافة إلى ذلك، أضفنا ثلاثة فحوصات عشوائية لضمان جودة البيانات. تم استلام ما مجموعه 220 استبيانًا مكتملًا، ولكن تمdiscard 36 بسبب الفشل في اجتياز فحص واحد على الأقل من فحوصات الانتباه. وهذا ترك لنا 184 استجابة صالحة وكاملة، متجاوزة الحد الأدنى لحجم العينة.
6.1.3 ديموغرافيات المشاركين. شمل استبياننا مجموعة متنوعة من 184 مستجيبًا، تتكون من ذكور، إناث، أفراد غير ثنائيين، و الذين فضلوا عدم الكشف عن جنسهم. تم اختيار المستجيبين من مجموعة جغرافية واسعة تمتد عبر 27 دولة فريدة، مع أكبر عدد من الاستجابات القادمة من المملكة المتحدة ( )، جنوب أفريقيا ( )، بولندا ( )، ألمانيا ( )، والولايات المتحدة الأمريكية ( ).

فيما يتعلق بمدة العمل، كانت الخبرة المتوسطة بين المشاركين ثلاث سنوات. كان الغالبية، 125 مستجيبًا، في بداية مسيرتهم المهنية، مع خبرة تتراوح بين 1 إلى 5 سنوات. أفاد أربعون مشاركًا بخبرة عمل أكبر تتراوح بين 6 إلى 15 عامًا. كان لدى 14 مشاركًا آخرين خبرة عمل واسعة تتراوح بين 16 إلى 30 عامًا، ويمتلك عدد قليل من المستجيبين، 5 في المجموع، أكثر من 30 عامًا من الخبرة.

تميزت عينتنا بشكل بارز بأفراد من قطاع تطوير البرمجيات، مما يشكل من جميع المستجيبين. بالإضافة إلى ذلك، من المستجيبين شغلوا أدوار تحليل البيانات أو الهندسة أو العلوم. كانت هناك شريحة أصغر، ، شغلت أدوار قيادية مثل قادة الفرق أو مديري المعلومات. شمل المستجيبون المتبقون مهندسي اختبار / ضمان الجودة (6%)، مهندسي DevOps / البنية التحتية (3%)، المعماريين (2%)، مصممي UX/UI (2%)، وأدوار أخرى (2%).

من أجل ضمان صلاحية وموثوقية نموذجنا الهيكلي، من الضروري تقييم موثوقية المتغيرات الكامنة. وبالتالي، نقوم بتحليل الصلاحية التمييزية، وموثوقية الاتساق الداخلي، والصلاحية التقاربية في البداية.
6.2.1 الصلاحية التمييزية. في هذا السياق، تشير الصلاحية التمييزية إلى تميز أو تفرد متغير كامن واحد مقارنة بآخر. هذا يعد معلمة أساسية لتحديد ما إذا كانت بنى معينة هي في الأساس نفس الشيء وتمثل جوانب مختلفة من المعرفة. لتقييمها، استخدمنا نسبة الارتباطات بين المتغيرات المختلفة (HTMT) المعروفة بأدائها المتفوق على اختبارات أخرى مثل معيار فورنل-لاركر. يجب أن تكون قيم HTMT مثالية أقل من 0.90.

يكشف الجدول 10 أن جميع المعاملات تقع تحت العتبة المحددة مسبقًا، مما يشير إلى أن كل بنية في النموذج تمثل ظاهرة متميزة.
6.2.2 موثوقية الاتساق الداخلي. يسعى هذا الاختبار إلى تأكيد أن العناصر تقيس المتغيرات الكامنة بطريقة متسقة وموثوقة. على هذا النحو، نشير إلى قيم ألفا كرونباخ، وrho_a، وrho_c المعروضة في الجدول 11، والتي يجب أن تتجاوز جميعها 0.60 [70]. يمكننا أن نستنتج أن اختباراتنا تلبي معايير الموثوقية.

6.2.3 الصلاحية التقاربية. التقييم النهائي للصلاحية يفحص مدى الارتباطات بين العناصر المختلفة وبنيتها المقابلة. من الجدير بالذكر أن متغيراتنا الكامنة تقاس بشكل انعكاسي (الوضع A) . نتيجة لذلك، يجب أن تظهر هذه المؤشرات نسبة تباين كبيرة من خلال التقارب على متغيراتها الكامنة. تم استخدام اختبارين للتحقق من هذا الافتراض.

يتضمن الاختبار الأول متوسط التباين المستخرج (AVE)، والذي يجب أن يسجل قيمة تتجاوز 0.5 [46]. يتضمن الاختبار الثاني ضمان أن الأحمال الخارجية لكل قياس

النموذج للمتغير الكامن تمثل على الأقل تباين. يتم اختبار ذلك من خلال تقييم موثوقية المؤشر، والتي يجب أن تتجاوز الجذر التربيعي لـ ، أي 0.7.

الجدول 12 يلخص نتائج موثوقية المؤشر باستخدام التحميلات المتقاطعة. العناصر التي لم تسهم بشكل كبير في التباين وتم استبعادها لاحقًا من نموذجنا خلال مرحلة التحليل (يمكن العثور على قائمة كاملة بالعناصر المستبعدة في الجدول 20). وبالتالي، لوحظ تحسن في متوسط التباين المستخرج، مما يعزز قوة النموذج.

بعد التأكد من موثوقية جميع نماذجنا من خلال تقييم نموذج القياس، يمكننا الآن تحويل تركيزنا نحو تقييم النموذج الهيكلي، الممثل بيانياً في الشكل 2. هذا التقييم هو محور النقاش حول القوة التنبؤية لنموذجنا والتحقق من فرضيات بحثنا.
6.3.1 تحليل التداخل. في البداية، نقوم بتحليل العلاقة بين المتغير الخارجي (العوامل الشخصية والبيئية) وبقية المتغيرات الداخلية. يجب أن تكون هذه المتغيرات مستقلة لتجنب أي تحيز محتمل في تقديرات المسار. يجب أن تكون قيمة اختبار عامل تضخم التباين (VIF) أقل من خمسة [63]، والذي يكشف عن التعدد الخطي (أي، درجة متطرفة من التداخل). قيم VIF لدينا أقل من هذا العتبة، حيث تتراوح من 4.710 (للعنصر IU_3) إلى 2.034 (PEF_4). وبالتالي، نستنتج أن نموذجنا لا يعاني من مشاكل التعدد الخطي.
6.3.2 علاقات المسار: الأهمية والملاءمة. تمثل معاملات المسار العلاقات المفترضة بين المتغيرات الكامنة. إنها موحدة، مما يعني أن قيمها يمكن أن تتراوح

من -1 إلى +1. لا تتطلب PLS-SEM افتراضات توزيع، مما يعني أننا لا يمكننا استخدام الاختبارات المعلمية لتقييم الأهمية. كحل بديل، نستخدم طريقة البوتستراب ذات الجانبين التي تتضمن 5,000 عينة فرعية مع الاستبدال.

تفاصيل نتائج التمهيد موضحة في الجدول 13، الذي يتضمن معاملات التمهيد، المتوسط، الانحراف المعياري، إحصائيات T، والقيم p المرتبطة بكل واحدة من فرضياتنا السبع.

تحليلنا يكشف أن الغالبية العظمى من فرضياتنا ذات دلالة إحصائية. على وجه التحديد، هناك أربع علاقات قد -قيم أقل من 0.05 ، و الإحصائيات تتجاوز 1.96، مما يدل على مستوى الدلالة كما أشار إليه هير وآخرون.

6.3.3 تقييم معاملات التحديد. بعد التأكد من أهمية الغالبية العظمى من فرضياتنا، ننتقل الآن إلى المرحلة النهائية من دراستنا، التي تركز على القوة التنبؤية للبنى الداخلية. يتم عرض ذلك في الجدول 14. يتم قياس القدرة التنبؤية من خلال التباين المفسر ( ) بواسطة البنى الداخلية. يشير إلى نسبة التباين في المتغير التابع الذي يمكن التنبؤ به من المتغيرات المستقلة. كما يزداد مع عدد المتنبئين (المزيد من المتنبئين يعادل ارتفاع) من الحكمة أن نأخذ في الاعتبار التعديل أيضًا، الذي يأخذ في الاعتبار كمية المتنبئين في النموذج. تتراوح قيم هذه المقاييس بين 0 و 1. تحديد معيار لـ يمكن أن يكون ذلك تحديًا حيث أن أهميته تعتمد بشكل كبير على الموضوع المطروح [46]، ولكن يُقبل عمومًا أنه يجب أن يتجاوز 0.19 [17].

6.3.4 تقييم الفعالية التنبؤية. نظرًا لأن الهدف الرئيسي لدراستنا هو تحديد التنبؤات بدلاً من السببية، قمنا بإجراء تقييم للنتائج التنبؤية باستخدام PLSpredict [95]. تختبر هذه الطريقة ما إذا كان نموذج (تم تطويره باستخدام عينة تدريبية) يمكنه التنبؤ بالنتائج من عينة اختبار. تم تقسيم عينتنا إلى عشرة أجزاء، وتم استخدام عشرة تكرارات لاشتقاق إحصائيات PLSpredict. تم تفسير النتائج بناءً على الإرشادات المقترحة من قبل شموئيل وآخرون [96]. توضح الجدول 15 دقة التنبؤ للمتغيرات الكامنة. ومن الجدير بالذكر أن جميع المتغيرات تظهر ” إيجابية قوية. تنبؤ يشير إلى أداء قوي للنموذج.

6.3.5 تقييم الاتساق التنبؤي. تركز امتحاننا النهائي على الاتساق التنبؤي لنموذجنا، حيث نقوم بفحص أحجام التأثير ( ) كما هو موضح في الجدول 16. يتضمن هذا التقييم فهم تأثيرات العلاقات المختلفة داخل النموذج. تم تحديد قيم العتبة لحجم التأثير عند 0.35، والتي تت correspond إلى التأثيرات الصغيرة والمتوسطة والكبيرة، على التوالي [23]. هنا، العلاقة ذات التأثير الأقوى هي عوامل التوافق مع نية استخدام نماذج اللغة الكبيرة. .

تستكشف هذه الدراسة المركزة العناصر التي تؤثر على اعتماد واستخدام أدوات الذكاء الاصطناعي التوليدي في مجال هندسة البرمجيات. باستخدام منهجية تحليل خريطة الأهمية والأداء (IPMA)، قمنا بدمج تحليل كل من أبعاد الأهمية والأداء المستمدة من تحقيق PLS-SEM. تتيح لنا هذه الطريقة تحديد مدى مساهمة الهياكل المختلفة في تعزيز الهيكل المستهدف – في هذه الحالة، النية لاستخدام (IU) واعتماد أدوات الذكاء الاصطناعي التوليدي. توفر رؤى استراتيجية من خلال تحديد الهياكل الأكثر أهمية وتلك التي تتطلب تحسينات في الأداء.

تظهر الجدول 17 أن جميع العوامل المحددة، وهي عوامل التوافق (CF) والعوامل الشخصية والبيئية (PEF) والتصورات حول التكنولوجيا (PT) والعوامل الاجتماعية (SF)، تظهر أداءً قويًا، حيث تتجاوز جميعها ، حيث تجاوزت PT و CF حتى علامة. هذه النتيجة جديرة بالملاحظة، خاصةً بالنظر إلى أن النماذج المعتمدة مثل نموذج قبول التكنولوجيا عادةً ما تظهر نطاق أداء البنى بين و [80].

تتوافق أهمية البنى الفردية كما هو موضح في الجدول 18 مع تلك الخاصة بالنماذج الناضجة، حيث تتراوح القيم بين 0.110 و 0.767. على وجه الخصوص، تبرز PT و CF كأهم البنى التي تؤثر على IU. تؤكد هذه النتيجة على دور التصورات حول التكنولوجيا وعوامل التوافق في نية الاستخدام والتبني النهائي لأدوات الذكاء الاصطناعي التوليدي في هندسة البرمجيات.

توفر الشكل 3 تصورًا لتفاعل أهمية وأداء هذه البنى. على سبيل المثال، فإن زيادة وحدة واحدة في أداء PT (من، لنقل، 85.138 إلى 86.138) ستؤدي إلى تحسين IU من خلال التأثير الكلي لـ PT على IU، والذي هو 0.540. وهذا يشير إلى أنه إذا كان الهدف هو زيادة IU و Adoption، يجب أن يتم التركيز على تعزيز PT، نظرًا لأهميته العالية. وبالمثل، تلعب CF أيضًا دورًا حاسمًا لدعم اعتماد الذكاء الاصطناعي. من ناحية أخرى، تبدو البنى مثل SF و PEF، على الرغم من دورها، أقل أهمية بالنسبة للنية في استخدام أدوات الذكاء الاصطناعي التوليدي.

في تحقيقنا حول اعتماد الذكاء الاصطناعي التوليدي في هندسة البرمجيات، طورنا إطار التعاون والتكيف بين الإنسان والذكاء الاصطناعي (HACAF) لتفكيك التفاعل بين التصورات حول التكنولوجيا، وعوامل التوافق، والعوامل الاجتماعية، والعوامل الشخصية والبيئية. لم نقم بتقييد دراستنا بنموذج ذكاء اصطناعي توليدي محدد، مثل ChatGPT-4 أو ChatGPT3.5. كان هذا القرار مدفوعًا بهدفنا لالتقاط فهم شامل لديناميات الاعتماد، مع الاعتراف بأن مشهد الذكاء الاصطناعي التوليدي يتطور بسرعة. الالتزام بنموذج واحد كان يمكن أن يحد من قابلية تعميم ودوام نتائجنا. من خلال اعتماد نهج أوسع، نفترض أن إطارنا قد يقدم رؤى قيمة، وقد يظل ذا صلة مع ظهور تكرارات ونسخ جديدة من نماذج الذكاء الاصطناعي التوليدي في المجال، على الرغم من أن هذا الافتراض يدعو إلى مزيد من التحقق التجريبي. كشفت النتائج عن مشهد معقد، مع انحرافات مفاجئة عن نظريات قبول التكنولوجيا التقليدية. يلخص الجدول 19 النتائج الرئيسية والتداعيات.

كانت دراستنا النوعية أساسية في تطوير إطارنا، الذي يبرز تأثير التصورات حول التكنولوجيا وعوامل التوافق في تشكيل النية

لاستخدام LLMs. ومع ذلك، فإن الدراسة الكمية اللاحقة قلبت التوقع بأن هذه التصورات تؤثر مباشرة على النية في الاستخدام، مما يتعارض مع نموذج قبول التكنولوجيا التقليدي [29]. وهذا يشير إلى أنه عند اعتماد LLMs، فإن التوافق مع العمليات الحالية يؤثر بشكل كبير على التصورات حول التكنولوجيا.

يتماشى الدور المركزي لعوامل التوافق مع النتائج السابقة [65] ويؤكد الحاجة الأساسية للتوافق التكنولوجي مع الممارسات الحالية. كشفت دراستنا أن مهندسي البرمجيات يميلون أكثر إلى اعتماد LLMs عندما تتناسب التكنولوجيا بسلاسة مع سير العمل الحالي لديهم، وهو ما يتماشى مع الأبحاث السابقة [32].

على عكس التوقعات، أشارت التحقيقات الكمية إلى أن العوامل الاجتماعية لم تسهم بشكل كبير في النية في استخدام LLMs. يبرز هذا الانحراف عن الدراسات السابقة [111] التأثيرات الدقيقة للجوانب الاجتماعية وكفاءة الذات على عملية الاعتماد.

العوامل الشخصية والبيئية، على الرغم من تأثيرها في تشكيل التصورات حول التكنولوجيا، لم تؤثر بشكل مباشر على النية في الاستخدام. تدعم هذه الملاحظة التأكيد من قبل [2] بأن الابتكارية الشخصية قد تشكل التصورات حول التكنولوجيا ولكنها لا تضمن بالضرورة الاعتماد.

تقدم الرؤى المستمدة من استكشافنا لاعتماد LLM باستخدام نظرية HACAF تباينًا وتوسعًا عن الأطر النظرية المعمول بها مثل TAM و DOI و SCT، مما يسلط الضوء على الديناميات المعقدة التي تلعب دورًا. تحمل هذه النتائج تداعيات أكاديمية وعملية، مما يبرز ضرورة استراتيجيات شاملة تأخذ في الاعتبار التصورات الفردية وعوامل التوافق لتعزيز اعتماد LLM.

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

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

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

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

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

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

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

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

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

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

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

تمت مناقشة تهديداتنا للصلاحية فيما يتعلق بتطبيق كل من أطر الصلاحية النوعية والكمية، كما نصت الأبحاث السابقة [86، 87]. وبالتالي، نبدأ حديثنا عن المصداقية، وقابلية النقل، والتأكيد للصياغة النوعية [45].

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

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

علاوة على ذلك، نناقش الاستنتاج الإحصائي، والداخلية، والبناء، وصلاحية الخارجية لتقييم التحقيق الكمي.

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

الخارجية. كانت تعميم نتائجنا مصدر قلق كبير خلال تحليل PLS-SEM حيث أن دراسات العينة هي الأنسب لتعميم النظرية. جمعنا 184 استجابة، وهو حجم كافٍ بالنظر إلى دراسة القوة الأولية التي أجريناها قبل جمع البيانات.

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

الاستنتاج الإحصائي. قمنا بمعالجة نتائج الاستطلاع باستخدام نمذجة المعادلات الهيكلية – المربعات الصغرى الجزئية باستخدام برنامج SmartPLS الإحصائي الشهير (4.0.9.5)، الذي تم استخدامه في أكثر من 1000 مقال تمت مراجعتها من قبل الأقران. جميع الأساليب والاختبارات الإحصائية المستخدمة في تحليل PLS-SEM تتماشى مع أحدث الإرشادات في مجالنا.

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

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

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

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

الجداول الحسابية لـ PLS-SEM، والبيانات الخام، وأدوات الاستطلاع، وتحليل الإفراط في التخصيص متاحة علنًا بموجب ترخيص CC BY 4.0 على Zenodo، DOI: https://doi.org/10.5281/zenodo. 8124332.

تم دعم هذا العمل من قبل مؤسسة الصناعة الدنماركية بمشروع Sb3D – الأمان من خلال التصميم في الدنمارك الرقمية.

تم استخدام ChatGPT-4 لضمان الدقة اللغوية وتعزيز قابلية قراءة هذه المقالة.

[1] Ritu Agarwal and Jayesh Prasad. 1998. A conceptual and operational definition of personal innovativeness in the domain of information technology. Information Systems Research 9, 2 (1998), 204-215.
[2] Ritu Agarwal and Jayesh Prasad. 1999. Are individual differences germane to the acceptance of new information technologies? Decision Sciences 30, 2 (1999), 361-391.
[3] AI, B. 2023. BLACKBOX AI – useblackbox.io. https://www.useblackbox.io/ Accessed: October 17, 2023.
[4] Icek Ajzen. 1991. The theory of planned behavior. Organizational Behavior and Human Decision Processes 50, 2 (1991), 179-211.
[5] Icek Ajzen. 2020. The theory of planned behavior: Frequently asked questions. Human Behavior and Emerging Technologies 2, 4 (2020), 314-324.
[6] Amazon Web Services. 2023. Code-Whisperer – Amazon Web Services. https://aws.amazon.com/es/codewhisperer/ Accessed: October 17, 2023.
[7] Alejandro Barredo Arrieta, Natalia Díaz-Rodríguez, Javier Del Ser, Adrien Bennetot, Siham Tabik, Alberto Barbado, Salvador Garcia, Sergio Gil-Lopez, Daniel Molina, Richard Benjamins, et al. 2020. Explainable Artificial Intelligence (XAI): Concepts, taxonomies, opportunities and challenges toward responsible AI. Information Fusion 58 (2020), 82-115.
[8] S. Baltes and P. Ralph. 2020. Sampling in Software Engineering Research: A Critical Review and Guidelines. arXiv:2002.07764 (2020).
[9] Albert Bandura. 2014. Social cognitive theory of moral thought and action. In Handbook of moral behavior and development. Psychology press, 69-128.
[10] Albert Bandura, W. H. Freeman, and Richard Lightsey. 1999. Self-Efficacy: The Exercise of Control. Fournal of Cognitive Psychotherapy 13, 2 (1999), 158-166.
[11] Shraddha Barke, Michael B James, and Nadia Polikarpova. 2023. Grounded copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages 7 (2023), 85-111.
[12] James Bessen. 2019. Automation and jobs: When technology boosts employment. Economic Policy 34, 100 (2019), 589-626.
[13] Christian Bird, Denae Ford, Thomas Zimmermann, Nicole Forsgren, Eirini Kalliamvakou, Travis Lowdermilk, and Idan Gazit. 2022. Taking Flight with Copilot: Early insights and opportunities of AI-powered pair-programming tools. Queue 20, 6 (2022), 35-57.
[14] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners. Advances in Neural Information Processing Systems 33 (2020), 1877-1901.
[15] Javier Cámara, Javier Troya, Lola Burgueño, and Antonio Vallecillo. 2023. On the assessment of generative AI in modeling tasks: an experience report with ChatGPT and UML. Software and Systems Modeling (2023), 1-13.
[16] Ruijia Cheng, Ruotong Wang, Thomas Zimmermann, and Denae Ford. 2022. “It would work for me too”: How Online Communities Shape Software Developers’ Trust in AI-Powered Code Generation Tools. arXiv preprint arXiv:2212.03491 (2022).
[17] W. W. Chin. 1998. The partial least squares approach to structural equation modeling. Modern Methods for Business Research 295, 2 (1998), 295-336.
[18] Clayton M. Christensen. 1997. The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press.
[19] Michael Chui et al. 2023. The economic potential of generative AI: The next productivity frontier. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier. [Accessed 03-Jul-2023].
[20] Victoria Clarke, Virginia Braun, and Nikki Hayfield. 2015. Thematic analysis. Qualitative psychology: A practical guide to research methods 3 (2015), 222-248.
[21] CodeComplete. 2023. CodeComplete: AI Coding Assistant for Enterprise. https://codecomplete.ai/ Accessed: October 17, 2023.
[22] Codeium. 2023. Codeium • Free AI Code Completion and Chat. https://codeium.com/ Accessed: October 17, 2023.
[23] J. Cohen. 1988. Statistical Power Analysis for the Behavioral Sciences. Routledge.
[24] Deborah R Compeau and Christopher A Higgins. 1995. Computer self-efficacy: Development of a measure and initial test. MIS Quarterly (1995), 189-211.
[25] J. Corbin and A. Strauss. 1990. Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative Sociology 13, 1 (1990), 3-21.
[26] J. Creswell. 2013. Research design: Qualitative, quantitative, and mixed methods approaches. Sage.
[27] Arghavan Moradi Dakhel, Vahid Majdinasab, Amin Nikanjam, Foutse Khomh, Michel C Desmarais, and Zhen Ming Jack Jiang. 2023. Github copilot ai pair programmer: Asset or liability? 7ournal of Systems and Software 203
(2023), 111734.
[28] Anastasia Danilova, Alena Naiakshina, Stefan Horstmann, and Matthew Smith. 2021. Do you really code? Designing and Evaluating Screening Questions for Online Surveys with Programmers. In International Conference on Software Engineering. IEEE, 537-548.
[29] F. Davis. 1989. Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly 13, 3 (1989), 319-340.
[30] Fred D Davis, Richard P Bagozzi, and Paul R Warshaw. 1989. User acceptance of computer technology: A comparison of two theoretical models. Management science 35, 8 (1989), 982-1003.
[31] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805 (2019).
[32] Paul Dourish. 2003. The appropriation of interactive technologies: Some lessons from placeless documents. Computer Supported Cooperative Work 12 (2003), 465-490.
[33] Christof Ebert and Panos Louridas. 2023. Generative AI for software practitioners. IEEE Software 40, 4 (2023), 30-38.
[34] Neil A Ernst and Gabriele Bavota. 2022. Ai-driven development is here: Should you worry? IEEE Software 39, 2 (2022), 106-110.
[35] Carl Benedikt Frey and Michael A Osborne. 2017. The future of employment: How susceptible are jobs to computerisation? Technological Forecasting and Social Change 114 (2017), 254-280.
[36] Yanjie Gao, Xiaoxiang Shi, Haoxiang Lin, Hongyu Zhang, Hao Wu, Rui Li, and Mao Yang. 2023. An Empirical Study on Quality Issues of Deep Learning Platform. In International Conference on Software Engineering: Software Engineering in Practice. IEEE, 455-466.
[37] D. Gefen, D. Straub, and M.-C. Boudreau. 2000. Structural equation modeling and regression: Guidelines for research practice. Communications of the Association for Information Systems 4, 1 (2000), 7.
[38] D. Gioia, K. Corley, and A. Hamilton. 2013. Seeking qualitative rigor in inductive research: Notes on the Gioia methodology. Organizational Research Methods 16, 1 (2013), 15-31.
[39] D. Gioia, J. Thomas, S. Clark, and K. Chittipeddi. 1994. Symbolism and strategic change in academia: The dynamics of sensemaking and influence. Organization Science 5, 3 (1994), 363-383.
[40] B. Glaser and A. Strauss. 2017. Discovery of grounded theory: Strategies for qualitative research. Routledge.
[41] Dale L Goodhue and Ronald L Thompson. 1995. Task-technology fit and individual performance. MIS quarterly (1995), 213-236.
[42] Roberto Gozalo-Brizuela and Eduardo C Garrido-Merchán. 2023. A survey of Generative AI Applications. arXiv preprint arXiv:2306.02781 (2023).
[43] F. J. Gravetter and L.-A. B. Forzano. 2018. Research methods for the behavioral sciences. Cengage Learning.
[44] Stine Grodal, Michel Anteby, and Audrey L Holm. 2021. Achieving rigor in qualitative analysis: The role of active categorization in theory building. Academy of Management Review 46, 3 (2021), 591-612.
[45] E. Guba. 1981. Criteria for assessing the trustworthiness of naturalistic inquiries. Educational Communication and Technology fournal 29, 2 (1981), 75-91.
[46] J. F. Hair Jr, G T. M Hult, C. Ringle, and M. Sarstedt. 2016. A primer on partial least squares structural equation modeling (PLS-SEM). Sage.
[47] Douglas M Hawkins. 2004. The problem of overfitting. Journal of chemical information and computer sciences 44, 1 (2004), 1-12.
[48] Ari Holtzman, Jan Buys, Li Du, Maxwell Forbes, and Yejin Choi. 2019. The curious case of neural text degeneration. arXiv preprint arXiv:1904.09751 (2019).
[49] Saki Imai. 2022. Is github copilot a substitute for human pair-programming? an empirical study. In Proceedings of the ACM/IEEE International Conference on Software Engineering: Companion Proceedings. 319-321.
[50] L. Isabella. 1990. Evolving interpretations as a change unfolds: How managers construe key organizational events. Academy of Management Journal 33, 1 (1990), 7-41.
[51] Mateusz Jaworski and Dariusz Piotrkowski. 2023. Study of software developers’ experience using the Github Copilot Tool in the software development process.
[52] Jared Kaplan, Sam McCandlish, Tom Henighan, Tom B Brown, Benjamin Chess, Rewon Child, Scott Gray, Alec Radford, Jeffrey Wu, and Dario Amodei. 2020. Scaling laws for neural language models. arXiv preprint arXiv:2001.08361 (2020).
[53] Ron Kohavi. 1995. A study of cross-validation and bootstrap for accuracy estimation and model selection. In Ijcai, Vol. 14. 1137-1145.
[54] Rajiv Kohli and Nigel P Melville. 2019. Digital innovation: A review and synthesis. Information Systems 7ournal 29, 1 (2019), 200-223.
[55] U. Kulkarni, S. Ravindran, and R. Freeze. 2006. A knowledge management success model: Theoretical development and empirical validation. Journal of Management Information Systems 23, 3 (2006), 309-347.
[56] W. Lewis, R. Agarwal, and V. Sambamurthy. 2003. Sources of influence on beliefs about information technology use: An empirical study of knowledge workers. MIS Quarterly (2003), 657-678.
[57] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. D. Lago, T. Hubert, P. Choy, C. de Masson d’Autume, I. Babuschkin, X. Chen, P.-S. Huang, J. Welbl, S. Gowal, A. Cherepanov, J. Molloy, D. J. Mankowitz, E. S. Robson, P. Kohli, N. de Freitas, K. Kavukcuoglu, and O. Vinyals. 2023. AlphaCode alphacode.deepmind.com. https://alphacode.deepmind.com/ Accessed: October 17, 2023.
[58] Jenny T Liang, Chenyang Yang, and Brad A Myers. 2023. Understanding the Usability of AI Programming Assistants. arXiv preprint arXiv:2303.17125 (2023).
[59] Y. Lincoln and E. Guba. 1985. Naturalistic inquiry. Sage.
[60] Mai Skjott Linneberg and Steffen Korsgaard. 2019. Coding qualitative data: A synthesis guiding the novice. Qualitative Research fournal 19, 3 (2019), 259-270.
[61] K. Locke. 1996. Rewriting the discovery of grounded theory after 25 years? Journal of Management Inquiry 5, 3 (1996), 239-245.
[62] Antonio Mastropaolo, Luca Pascarella, Emanuela Guglielmi, Matteo Ciniselli, Simone Scalabrino, Rocco Oliveto, and Gabriele Bavota. 2023. On the robustness of code generation techniques: An empirical study on github copilot. arXiv preprint arXiv:2302.00438 (2023).
[63] J. Miles. 2014. Tolerance and Variance Inflation Factor. American Cancer Society.
[64] Brent Daniel Mittelstadt, Patrick Allo, Mariarosaria Taddeo, Sandra Wachter, and Luciano Floridi. 2016. The ethics of algorithms: Mapping the debate. Big Data & Society 3, 2 (2016).
[65] Geoffrey A Moore and Regis McKenna. 1999. Crossing the chasm. (1999).
[66] Hussein Mozannar, Gagan Bansal, Adam Fourney, and Eric Horvitz. 2022. Reading between the lines: Modeling user behavior and costs in AI-assisted programming. arXiv preprint arXiv:2210.14306 (2022).
[67] mutable.ai. 2023. AI Accelerated Software Development. – mutable.ai. https://mutable.ai/ Accessed: October 17, 2023.
[68] Nhan Nguyen and Sarah Nadi. 2022. An empirical evaluation of GitHub copilot’s code suggestions. In Proceedings of the International Conference on Mining Software Repositories. 1-5.
[69] Oded Nov and Chen Ye. 2008. Users’ personality and perceived ease of use of digital libraries: The case for resistance to change. Journal of the American Society for Information Science and Technology 59, 5 (2008), 845-851.
[70] J. Nunnally. 1978. Psychometric methods. McGraw-Hill.
[71] General Assembly of the World Medical Association et al. 2014. World Medical Association Declaration of Helsinki: ethical principles for medical research involving human subjects. The 7ournal of the American College of Dentists 81, 3 (2014), 14.
[72] OpenAI. 2023. GPT-4 Technical Report. arXiv:2303.08774 [cs.CL]
[73] Ipek Ozkaya. 2023. The next frontier in software development: AI-augmented software development processes. IEEE Software 40, 4 (2023), 4-9.
[74] Stefan Palan and Christian Schitter. 2018. Prolific.ac–A subject pool for online experiments. Journal of Behavioral and Experimental Finance 17 (2018), 22-27.
[75] Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of ai on developer productivity: Evidence from github copilot. arXiv preprint arXiv:2302.06590 (2023).
[76] Anthony Peruma, Steven Simmons, Eman Abdullah AlOmar, Christian D Newman, Mohamed Wiem Mkaouer, and Ali Ouni. 2022. How do i refactor this? An empirical study on refactoring trends and topics in Stack Overflow. Empirical Software Engineering 27, 1 (2022), 11.
[77] James Prather, Brent N Reeves, Paul Denny, Brett A Becker, Juho Leinonen, Andrew Luxton-Reilly, Garrett Powell, James Finnie-Ansley, and Eddie Antonio Santos. 2023. ” It’s Weird That it Knows What I Want”: Usability and Interactions with Copilot for Novice Programmers. arXiv preprint arXiv:2304.02491 (2023).
[78] Alec Radford, Karthik Narasimhan, Tim Salimans, and Ilya Sutskever. 2019. Language models are unsupervised multitask learners. OpenAI blog 1, 8 (2019), 9.
[79] Paul Ralph et al. 2020. Empirical standards for software engineering research. arXiv preprint arXiv:2010.03525 (2020).
[80] M. Ramkumar, T. Schoenherr, S. Wagner, and M. Jenamani. 2019. Q-TAM: A quality technology acceptance model for predicting organizational buyers’ continuance intentions for e-procurement services. International fournal of Production Economics 216 (2019), 333-348.
[81] Baishakhi Ray, Daryl Posnett, Vladimir Filkov, and Premkumar Devanbu. 2014. A large scale study of programming languages and code quality in github. In International Symposium on Foundations of Software Engineering. ACM, 155-165.
[82] replit. 2023. Ghostwriter – Code faster with AI – replit.com. https://replit.com/site/ghostwriter Accessed: October 17, 2023.
[83] C. M. Ringle and M. Sarstedt. 2016. Gain more insight from your PLS-SEM results: The importance-performance map analysis. Industrial Management & Data Systems 116, 9 (2016), 1865-1886.
[84] C. M. Ringle, S. Wende, and J.-M. Becker. 2015. SmartPLS 3.
[85] Everett M. Rogers. 2010. Diffusion of Innovations. Simon and Schuster.
[86] Daniel Russo. 2021. The agile success model: a mixed-methods study of a large-scale agile transformation. ACM Transactions on Software Engineering and Methodology 30, 4 (2021), 1-46.
[87] D. Russo, P. Ciancarini, T. Falasconi, and M. Tomasi. 2018. A Meta Model for Information Systems Quality: a Mixed-Study of the Financial Sector. ACM Transactions on Management Information Systems 9, 3 (2018).
[88] Daniel Russo, Paul H P Hanel, Seraphina Altnickel, and Niels van Berkel. 2021. The daily life of software engineers during the covid-19 pandemic. In International Conference on Software Engineering. IEEE, 364-373.
[89] Daniel Russo, Paul H P Hanel, Seraphina Altnickel, and Niels van Berkel. 2021. Predictors of Well-being and Productivity among Software Professionals during the COVID-19 Pandemic-A Longitudinal Study. Empirical Software Engineering 26, 62 (2021), 1-64. https://doi.org/10.1007/s10664-021-09945-9
[90] Daniel Russo and Klaas-Jan Stol. 2020. Gender Differences in Personality Traits of Software Engineers. IEEE Transactions on Software Engineering 48, 3 (2020), 16.
[91] Daniel Russo and Klaas-Jan Stol. 2021. PLS-SEM for software engineering research: An introduction and survey. Comput. Surveys 54, 4 (2021), 1-38.
[92] Mahadev Satyanarayanan. 2001. Pervasive computing: Vision and challenges. IEEE Personal Communications 8, 4 (2001), 10-17.
[93] Albrecht Schmidt. 2023. Speeding Up the Engineering of Interactive Systems with Generative AI. In ACM SIGCHI Symposium on Engineering Interactive Computing Systems. 7-8.
[94] AH Segars and V Grover. 1993. Re-examining perceived ease of use and usefulness: A confirmatory factor analysis. MIS Quarterly 17, 4 (1993), 517-525.
[95] Galit Shmueli, Soumya Ray, Juan Manuel Velasquez Estrada, and Suneel Babu Chatla. 2016. The elephant in the room: Predictive performance of PLS models. Journal of Business Research 69, 10 (2016), 4552-4564.
[96] G. Shmueli, M. Sarstedt, J. F. Hair, J Cheah, H. Ting, S. Vaithilingam, and C. M. Ringle. 2019. Predictive model assessment in PLS-SEM: guidelines for using PLSpredict. European fournal of Marketing 53, 11 (2019).
[97] Dominik Sobania, Martin Briesch, and Franz Rothlauf. 2022. Choose your programming copilot: A comparison of the program synthesis performance of github copilot and genetic programming. In Proceedings of the Genetic and Evolutionary Computation Conference. 1019-1027.
[98] Klaas-Jan Stol and Brian Fitzgerald. 2018. The ABC of software engineering research. ACM Transactions on Software Engineering and Methodology 27, 3 (2018), 11.
[99] A. Strauss and J. Corbin. 1990. Basics of qualitative research: Grounded theory procedures and techniques. Sage.
[100] Tabnine. 2023. AI Assistant for software developers – Tabnine. https://www.tabnine.com/ Accessed: October 17, 2023.
[101] Emmanuel Tenakwah. 2021. What do employees want?: Halting record-setting turnovers globally. Strategic HR Review 20, 6 (2021), 206-210.
[102] Ronald L Thompson, Christopher A Higgins, and Jane M Howell. 1991. Personal Computing: Toward a Conceptual Model of Utilization. MIS Quarterly 15, 1 (1991), 125-143.
[103] Haoye Tian, Weiqi Lu, Tsz On Li, Xunzhu Tang, Shing-Chi Cheung, Jacques Klein, and Tegawendé F Bissyandé. 2023. Is ChatGPT the Ultimate Programming Assistant-How far is it? arXiv preprint arXiv:2304.11938 (2023).
[104] Gholamreza Torkzadeh, Jerry Cha-Jan Chang, and Didem Demirhan. 2006. A contingency model of computer and Internet self-efficacy. Information & Management 43, 4 (2006), 541-550.
[105] Louis G. Tornatzky and Katherine J. Klein. 1982. Innovation characteristics and innovation adoption-implementation: A meta-analysis of findings. IEEE Transactions on Engineering Management 29, 1 (1982), 28-45.
[106] Andreas Tsamados, Luciano Floridi, and Mariarosaria Taddeo. 2023. The Cybersecurity Crisis of Artificial Intelligence: Unrestrained Adoption and Natural Language-Based Attacks. Available at SSRN 4578165 (2023).
[107] Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman. 2022. Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models. In International Conference on Human Factors in Computing Systems. 1-7.
[108] J. Van Maanen. 1979. The fact of fiction in organizational ethnography. Administrative Science Quarterly 24, 4 (1979), 539-550.
[109] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. Advances in Neural Information Processing Systems 30 (2017).
[110] Viswanath Venkatesh and Fred D Davis. 2000. A theoretical extension of the technology acceptance model: four longitudinal field studies. Management science 46, 2 (2000), 186-204.
[111] Viswanath Venkatesh, Michael G Morris, Gordon B Davis, and Fred D Davis. 2003. User acceptance of information technology: toward a unified view. MIS quarterly (2003), 425-478.
[112] Viswanath Venkatesh, James YL Thong, and Xin Xu. 2016. Unified theory of acceptance and use of technology: A synthesis and the road ahead. Journal of the Association for Information Systems 17, 5 (2016), 328-376.
[113] Vv.AA. 2023. The widespread adoption of AI by companies will take a while. https://www.economist.com/leaders/ 2023/06/29/the-widespread-adoption-of-ai-by-companies-will-take-a-while
[114] Ruotong Wang, Ruijia Cheng, Denae Ford, and Thomas Zimmermann. 2023. Investigating and Designing for Trust in AI-powered Code Generation Tools. arXiv preprint arXiv:2305.11248 (2023).
[115] Bolin Wei, Ge Li, Xin Xia, Zhiyi Fu, and Zhi Jin. 2019. Code generation as a dual task of code summarization. In International Conference on Neural Information Processing Systems. 6563-6573.
[116] Michel Wermelinger. 2023. Using GitHub Copilot to solve simple programming problems. In Proceedings of the ACM Technical Symposium on Computer Science Education. 172-178.
[117] C. Wohlin, P. Runeson, M. Höst, M. Ohlsson, B. Regnell, and A. Wesslén. 2012. Experimentation in Software Engineering. Springer Science & Business Media.
[118] Burak Yetistiren, Isik Ozsoy, and Eray Tuzun. 2022. Assessing the quality of GitHub copilot’s code generation. In Proceedings of the International Conference on Predictive Models and Data Analytics in Software Engineering. 62-71.
[119] Beiqi Zhang, Peng Liang, Xiyu (Thomas) Zhou, Aakash Ahmad, and Muhammad Waseem. 2023. Practices and Challenges of Using GitHub Copilot: An Empirical Study. arXiv preprint arXiv:2303.08733 (2023).
[120] Daniel Zhang, Saurabh Mishra, Erik Brynjolfsson, John Etchemendy, Deep Ganguli, Barbara Grosz, Terah Lyons, James Manyika, Juan Carlos Niebles, Michael Sellitto, et al. 2021. The AI index 2021 annual report. arXiv preprint arXiv:2103.06312 (2021).
[121] Q. Zheng, X. Xia, X. Zou, Y. Dong, S. Wang, Y. Xue, Z. Wang, L. Shen, A. Wang, Y. Li, T. Su, Z. Yang, and J. Tang. 2023. GitHub – THUDM/CodeGeeX: CodeGeeX: An Open Multilingual Code Generation Model. https: //github.com/THUDM/CodeGeeX Accessed: October 17, 2023.

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

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

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

ومع ذلك، لتقييم خطر الإفراط في التكيف بشكل أكثر شمولاً، استخدمنا منهجيتين رئيسيتين: تقسيم البيانات إلى مجموعة تدريب واختبار، والتحقق المتقاطع [53]. في تقسيم مجموعة التدريب والاختبار، قمنا بتقسيم بياناتنا إلى مجموعة تدريب ( من البيانات) ومجموعة اختبار ( من البيانات). تم تدريب نموذجنا على بيانات التدريب ثم تم تقييمه على بيانات الاختبار غير المرئية.

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

لفحص مشكلة الإفراط في التكيف بشكل أعمق، قمنا بتنفيذ تقنية التحقق المتقاطع باستخدام k -fold مع تعيين k إلى 5، وهو خيار شائع لهذه المعلمة [53]. في هذا النهج، تم تقسيم البيانات إلى 5 مجموعات فرعية، و

تم تدريب النموذج واختباره 5 مرات، في كل مرة على مجموعة فرعية مختلفة من البيانات. تم تقييم أداء النموذج مرة أخرى باستخدام متوسط مربع الخطأ (MSE). كان متوسط MSE من التحقق المتقاطع حوالي 0.676، وهو قريب بشكل معقول من MSE الاختبار، مما يشير إلى أن نموذجنا لا يعاني من مشكلة الإفراط في التكيف مع البيانات.

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

CCS Concepts: • Social and professional topics Computing industry; Management of computing and information systems; Project and people management.

Additional Key Words and Phrases: Generative AI, Large Language Models, Technology Adaption, Empirical Software Engineering.

Daniel Russo. 2024. Navigating the Complexity of Generative AI Adoption in Software Engineering. ACM Trans. Softw. Eng. Methodol. 37, 4, Article 111 (January 2024), 49 pages. https://doi.org/10.1145/1122445.1122456

The transformational promise of Artificial Intelligence (AI) is becoming increasingly evident across various sectors, with AI models demonstrating human-like competencies in areas as diverse as natural language understanding and image recognition [120]. One domain where this potential is particularly salient is software engineering, a critical function within contemporary organizations. This significance is underscored by the increasing pervasiveness of software in a broad range of products and services, with digital features enhancing their value [92]. From the initial phases of the software development lifecycle, AI tools can serve as valuable allies. Generative AI can sift through vast data sources like user feedback, market trends, and system logs, providing insights for feature ideation. During systems analysis and design, AI-enhanced tools can propose multiple IT architectural designs and swiftly adapt configurations, expediting the design process and product launches. In the coding phase, AI not only assists in generating code but also aids developers by crafting initial code drafts, swiftly detecting patterns, and serving as a knowledge repository. In the testing phase,

AI tools can autonomously generate test cases and automate specific testing functions. During deployment, AI tools streamline the release process, ensuring that software versions are seamlessly integrated into existing systems, while also monitoring for potential deployment anomalies and facilitating rollback strategies if needed. When it comes to maintenance, insights derived from AI can aid software engineers in diagnosing issues, suggesting fixes, and predicting potential areas of improvement. The implications of AI for the field of software development could be momentous, with predictions indicating a surge in productivity ranging from 20 to 45 percent [19]. This substantial increase could be achieved by streamlining traditional tasks like crafting preliminary code drafts, refining existing code structures (refactoring), or conducting thorough root-cause analyses. The integration of AI not only reduces the time commitment for these activities but also enhances the overall efficiency and effectiveness of the software development process [75]. Nonetheless, despite the prospective advantages, the incorporation of language models into software engineering appears to be intricate and fraught with challenges. Indeed, there are even indications that usage of Large Language Models is on the decline, possibly as a result of end-user experimentation that found them to be ill-suited to their requirements [113]. Consequently, a pressing need exists to unravel the core determinants influencing the adoption of Generative AI-driven tools, such as LLM-powered tools. As we know, a diverse range of elements shape the modality and rationale behind software engineers’ decision to employ language models. These incorporate both technical components, such as model quality and performance, and non-technical components, including perceived utility and ease of use [112]. Yet, there has been limited empirical research on the factors that influence language model adoption in software engineering. Hence, we formulate our research questions as follows:

Research Question: What influences the adoption of Generative AI tools in software engineering?
In our endeavor to explore our research question, we have applied a convergent mixed-methods approach, investigating the adoption of Generative AI and Large Language Models within the sphere of software engineering. To frame our understanding of AI adoption, we referenced three principal theoretical frameworks examining individual, technological, and social-level influences. These frameworks included the Technology Acceptance Model (TAM) [110], the Diffusion of Innovation Theory (DOI) [85], and the Social Cognitive Theory (SCT) [9]. By incorporating these well-validated theories, we could thoroughly comprehend the determinants of language model adoption and investigate the distinct ways these variables are operationalized in the software engineering domain. We initiated our research by conducting a questionnaire survey with a cohort of 100 software engineers. The design of these questionnaire survey was influenced by the main dimensions of our selected theories. The collected data was analyzed using the Gioia Methodology [38], facilitating the development of our preliminary theoretical model. This provisional theoretical model was then validation using Partial Least Squares – Structural Equation Modeling (PLS-SEM), supported by data collected from 183 software engineers. The convergence of insights derived from this comprehensive and multifaceted investigation enhances our understanding of AI adoption within software engineering. Moreover, by understanding the adoption dynamics and impact of these disruptive technologies, this research holds potential to guide the design of future AI tools and offer pertinent recommendations for organization-wide implementation strategies. Indeed, generative AI tools represent a disruptive innovation in the software engineering domain, as defined by Christensen’s concept of “disruptive innovation” [18]. These tools, while initially targeting niche applications or underserved market segments, have the potential to revolutionize traditional software engineering practices. Their ability to automate complex tasks, generate code, and offer solutions based on vast datasets challenges the status quo and can lead to a paradigm shift in
how software development is approached. Over time, as these tools become more refined and widely adopted, they could displace established methodologies and tools, much like how disruptive innovations reshape industries. By understanding the adoption dynamics of such transformative technologies, this research offers insights into their potential trajectory and implications, guiding the design of future AI tools and providing recommendations for their strategic implementation across organizations.

The structure of this article unfolds as follows. In Section 2, we present a comprehensive review of related works. Our mixed-methods investigation commences with an initial theory induction, a process we detail thoroughly in Section 3. We then analyze the results of this process in Section 4. From these findings, we craft our theoretical framework in Section 5, elucidating its hypotheses. Our model undergoes a rigorous validation process using Partial Least Squares – Structural Equation Modeling, as reported in Section 6. In the concluding sections, we reflect on the broader implications and potential limitations of our study in Section 7, and sketch out future research trajectories in Section 8.

The software engineering landscape is undergoing a transformation with the introduction of Generative AI, especially through the capabilities of Large Language Models (LLMs). LLMs, such as the Generative Pre-trained Transformer (GPT) series by OpenAI [14], owe their prowess to the foundational role of transformer architectures in natural language processing, which have been influential for several years [109]. Beyond their known proficiency in generating human-like text [48], LLMs, in the realm of software engineering, are poised to offer code suggestions, assist in automated documentation, aid in requirement elicitation, and more. The evolution of LLMs as Generative AI has been further propelled by the integration of transformer architectures, enhancing their understanding and generation of context [52]. As we navigate the confluence of LLMs and software engineering, it becomes evident that their potential extends beyond mere text generation. They are emerging as collaborative tools, set to redefine various facets of the software development lifecycle. Hence, throughout this paper, we use the terms Generative AI and Large Language Models interchangeably, emphasizing their relevance and potential in software engineering

A multitude of academic disciplines are currently exploring the potential implications of such advanced technologies within their respective fields. This section will discuss particular context of software engineering, highlighting the prevalent themes and concerns associated with AI tools.

A prominent strand of inquiry involves assessing the accuracy and quality of code generated by AI systems such as GitHub Copilot. Studies by Nguyen and Nadi, Dakhel et al., and Yetistiren, all conducted empirical assessments to evaluate the correctness of the code generated by Copilot, and found varying degrees of success depending on the programming language and the complexity of the task [27,68,118]. This shared focus on evaluation signifies the importance of assessing the functional integrity of the code generated by AI tools, which is a fundamental concern in software engineering.

While there were commonalities in evaluating Copilot’s performance, the specific aspects of evaluation varied among the studies. Nguyen and Nadi focused on the performance of Copilot across different programming languages [68], while Mastropaolo et al. investigated the robustness of Copilot in relation to semantic-preserving changes in the natural language description [62]. Yetistiren conducted a comprehensive assessment of the generated code in terms of validity, correctness, and
efficiency [118]. These differences underscore the multifaceted nature of AI code generation and the various dimensions that need assessment.

Productivity in software development is positively impacted by the integration of AI tools, with tools like Copilot significantly increasing the speed of code production [49, 75]. While these tools are lauded for their productivity-enhancing capabilities, understanding their performance and limitations is vital to leveraging their potential effectively. Studies by Tian et al. [103] and Camara et al. [15] shed light on the abilities and constraints of Large Language Models, such as ChatGPT. Empirical evaluation suggests that while these models demonstrate aptitude in simpler, well-structured tasks, they tend to struggle with complex tasks involving semantic nuance [103]. Additionally, a significant relationship was identified between the length of the input sequence and the quality of the output, with longer inputs often leading to poorer results [15]. These findings highlight the nuanced role of AI in software development productivity. While they enhance speed, the complexity of tasks and the length of input sequences can serve as limiting factors, pointing to areas for further improvement and optimization in these models.

Distinctly, Sobania et al. embarked on a comparative study between Copilot and genetic programming, another approach in automatic program synthesis. They concluded that, despite comparable performances, genetic programming was not as mature for practical software development as Copilot [97]. This comparative analysis provides a unique perspective on the landscape of automatic programming methodologies.

Pedagogical Concerns have been discussed by both Wermelinger and Dakhel et al.’s studies touched upon the implications of AI tools like Copilot in educational settings. While Wermelinger explored the implications of Copilot on teaching and assessment methods in programming courses [116], Dakhel et al. discussed the potential challenges for novice developers who might fail to filter Copilot’s non-optimal solutions due to lack of expertise [27]. These similarities highlight the significant pedagogical implications of integrating AI tools in education.

Concerns around the integration and security of AI tools like GitHub Copilot are a shared finding between Jaworski and Piotrkowski [51] and Zhang et al. [119]. Both studies illustrate that despite the potential benefits of these tools, developers express hesitation and face challenges when incorporating them into their workflows, due to integration difficulties and security worries. However, these studies diverge when examining developer interactions. Zhang et al. detail more practical aspects like programming languages and IDEs used with Copilot, whereas Jaworski and Piotrkowski focus on the developers’ sentiment towards AI tools. Ernst and Bavota [34], although also discussing the complexities of AI integration, differ by highlighting additional challenges related to legal compliance and bias. This broadens the conversation on AI’s impact on software development beyond technical aspects to include ethical and legal considerations. Another commonality, albeit from a different angle, is found in Bird et al. [13] and Mozannar et al. [66]. Both studies touch on the evolving role of developers as AI tools become more pervasive. Bird et al. suggest a shift towards developers spending more time reviewing AI-generated code, whereas Mozannar et al. provide a structured analysis of developer interactions with AI tools, revealing inefficiencies and time costs. Thus, while the studies largely converge on the transformative
potential and challenges of AI tools in software development, they also bring unique perspectives to the table, expanding the discourse to include aspects like legal concerns, workflow changes, and time costs.

The role of the community in shaping developers’ trust in AI tools is investigated by Cheng et al. [16]. They present a detailed analysis of how online communities, such as forums and discussion groups, influence developers’ perception of AI tools. Their research indicates that shared experiences and collective discussions play a significant role in shaping developers’ trust in AI assistance.

Generative AI’s impact on non-coding activities in software development is multifaceted. A prominent aspect is the surge in productivity and creativity improvements, as noted by Ozkaya [73]. This perspective is echoed by Schmidt [93] who alludes to the potential of AI in swiftly spotting and fixing bugs. However, the two diverge in their emphasis: while Ozkaya focuses on the broader paradigm shifts in software engineering conferences and research dynamics, Schmidt stresses into the challenges of ensuring trustworthiness in AI systems, suggesting a complexity in their deployment. This theme of trust is further expanded upon by Ebert and Louridas [33]. They discuss the evolving nature of software systems as being more adaptive, self-modifying, and learningoriented. Contrasting this with Ozkaya’s perspective [73] on the implications of shifting to AI tools, Ebert and Louridas shed light on the intricate challenges in validating such systems. They suggest that traditional software testing paradigms may no longer suffice, introducing a dimension of complexity in the deployment of AI in software development. Furthermore, the question of data quality enhancement through Generative AI offers another layer of analysis. Ebert and Louridas [33] detail the process of fine-tuning LLMs on specific datasets, emphasizing the resultant increase in output quality. This stands in contrast with the broader shifts and challenges highlighted by Ozkaya, focusing instead on the tactical advantages offered by AI tools. Overall, while there’s a consensus on the transformative potential of Generative AI in software development, the literature also paints a picture of the challenges and nuances. From broader shifts in the research landscape to tactical advantages and validation challenges, the discourse on AI’s role in non-coding activities is both rich and diverse, necessitating a holistic understanding for effective deployment.

The usability of AI programming assistants has been a focal point in the research, with the key motivations for usage identified as reduction in keystrokes, quick task completion, and syntax recall [58, 107]. However, developers often encounter challenges with tool control, output alignment with requirements, and difficulties with understanding, editing, and debugging generated code snippets [58, 107]. For novice programmers, cognitive and metacognitive issues arise while using these tools for assignments, indicating a need for better supportive design [77]. Also, developers exhibit distinct interaction modes, each requiring different forms of tool support [11]. This signifies a necessity for usability improvements in AI programming assistants, focusing on user control, cognitive effort minimization, and support for interaction modes.

In sum, the review of related work underscores the transformative potential and multifaceted challenges posed by Large Language Models in the realm of software engineering. The corpus of research spans areas such as the evaluation of generated code’s accuracy and quality, the augmentation of productivity, contrasting methodologies, pedagogical implications, AI’s influence on software development processes, the role of community in fostering trust, and the usability of

AI programming assistants. Each study contributes uniquely to our understanding of AI’s role in software engineering, highlighting the complexity of the issues at hand. While the field has made significant strides in leveraging AI’s potential, the need for robust evaluation, tailored usability, and mindful integration into educational and professional settings is a recurring theme.

Beyond the aforementioned research, it is crucial to note the existence of other code generators besides Copilot. Tools such as Alphacode [57], Amazon Codewhisperer [6], BlackBox AI [3], CodeComplete [21], CodeGeeX [121], Codeium [22], Mutable AI [67], GhostWriter Replit [82], and Tabnine [100] also play roles in the domain of AI-powered code generation. Interestingly, while these tools are acknowledged in the landscape, there is a glaring lack of empirical research evaluating them. Our research of the literature revealed only three papers that even mention these tools, and solely within the context of related work or discussion sections [16, 42, 114]. This presents a clear gap in the current body of research.

More specifically, while existing research thoroughly investigates the performance, usability, and impact of Generative AI tools in software engineering, it primarily focuses on the tools themselves, largely overlooking the factors influencing their adoption. A notable exception is Cheng et al.’s [16] exploration of community influence on developers’ trust. Yet, this is only one facet of the broader adoption landscape, which includes individual, organizational, technological, and environmental factors. Our research question addresses this clear gap in the literature, aiming to provide a comprehensive understanding of the factors driving or hindering the adoption of these tools.

The multifaceted nature of technology adoption demands the application of comprehensive theoretical frameworks that can sufficiently capture and explain the influencing factors. The Technology Acceptance Model, Diffusion of Innovation Theory, and Social Cognitive Theory together offer a robust approach towards understanding the complexity of language model adoption in software engineering.
3.1.1 Technology Acceptance Model (TAM). TAM has been widely acclaimed for its relevance and efficiency in predicting and explaining the acceptance of various forms of technology [110]. Its core constructs-perceived usefulness and perceived ease of use-serve as an excellent starting point for understanding adoption behavior. For instance, if language models are perceived as beneficial and easy to use, software engineers are more likely to embrace them. Given its robustness and simplicity, TAM provides a foundation for understanding the fundamental determinants of technology adoption and aids in diagnosing the basic barriers to language model adoption.
3.1.2 Diffusion of Innovation Theory (DOI). While TAM primarily focuses on user perceptions, DOI complements TAM by addressing the technological characteristics influencing adoption. Rogers [85] identified key attributes of innovations-relative advantage, compatibility, complexity, trialability, and observability-that significantly affect their adoption rates. As an innovation in software engineering, the acceptance of language models could be shaped by these attributes. For example, the relative advantage of language models over traditional programming methods could be a strong motivator for adoption. The compatibility of language models with existing practices and the complexity of these models might also play crucial roles. Thus, DOI adds depth to our understanding of technology-specific factors influencing language model adoption.
3.1.3 Social Cognitive Theory (SCT). The decision to adopt new technologies does not occur in a vacuum. It is influenced by the social milieu within which individuals operate. SCT comes into play
here by emphasizing the social and environmental factors that influence individual behaviors [9]. Software engineering, like any profession, has its own culture, norms, and shared beliefs that could significantly shape the adoption of language models. For instance, the prevailing norm or the extent of peer usage could encourage or discourage language model use. Moreover, the self-efficacy of indi-viduals-shaped in part by their social environment-might affect their willingness to engage with such a new tool. SCT, therefore, adds a social layer to our understanding of language model adoption.

The selection of TAM, DOI, and SCT over other potential theories was deliberate and informed by the unique challenges and intricacies of technology adoption in the software engineering domain. While there are numerous theories available that address technology adoption, not all are equally suited to capture the nuances of language model adoption in this specific field. TAM’s focus on user perceptions, DOI’s emphasis on technological attributes, and SCT’s consideration of the social environment together provide a holistic view that other theories might not offer in isolation. Furthermore, the combination of these three theories ensures a multi-dimensional approach, capturing the breadth and depth of factors influencing adoption. Other theories might focus too narrowly on one aspect, potentially overlooking critical influencers. By integrating these three well-established theories, we aimed to achieve a more comprehensive and nuanced understanding, ensuring no significant factor was left unaddressed.

In summary, the triadic theoretical framework of TAM, DOI, and SCT provides a comprehensive lens to examine the adoption of language models in software engineering. By addressing the individual perceptions (TAM), technology characteristics (DOI), and social aspects (SCT), this combined framework provides a well-rounded perspective, ensuring we cover the principal aspects influencing the decision to adopt language models. This choice of theories allows us to glean insightful details that not only offer a rich understanding of the current adoption scenario but also inform strategies to expedite future adoption.

Our investigation covers three units of analysis: individual-level factors, technology-level factors, and social-level factors, inspired by the Technology Acceptance Model, the Diffusion of Innovations, and Social Cognitive Theory. We aim to reveal a comprehensive understanding of the acceptance and use of LLM-powered tools in the software engineering context. Here, we detail the final questionnaire survey questions designed to capture these constructs effectively. As a preliminary step, we conducted a pilot interview with a senior engineering manager from a prominent software company based in Central Europe to ensure the clarity and appropriateness of our questions in April 2023. To design this investigation, we used the SIGSOFT Empirical Standard for Questionnaire Surveys [79].

Individual-level factors, derived from the Technology Acceptance Model, focus on perceived usefulness, perceived ease of use, and behavioral intention:

Technology-level factors, drawing from the Diffusion of Innovations, include compatibility, relative advantage, and complexity:

The data collection was executed via Prolific Academic [74], a well-regarded academic data collection platform often utilized by the software engineering community [28,88-90]. We solicited the input of 100 software engineers, who were asked to answer a series of nine open-ended questions founded on theoretical principles. The compensation for participants ( 10 minutes) exceeded the US federal minimum wage . The survey was conducted on the Qualtrics platform.

Participants were meticulously chosen through a two-step screening process. Initially, a prescreening phase was conducted where participants were filtered based on specific self-reported characteristics, including proficiency in computer programming, full-time employment in the software industry, a negative student status, a degree in computer science, and a approval rate. Following this, a competence screening was performed, as per the methods described by Danilova et al. [28]. This second screening involved assessing participants’ knowledge and understanding in key areas, including compilers, programming aid websites, and recursive functions. Furthermore, professionals affirmed their familiarity with Generative AI tools and confirmed their use to a certain extent.

Our data collection methodology complied strictly with the ethical guidelines of the Declaration of Helsinki [71]. The Research Ethics Committee at Aalborg University approved this research project in March 2023. All participants were older than 18, gave informed consent prior to participating in the study, and were notified of their right to withdraw their participation at any point. Additionally.

the author have completed formal training in research ethics for engineering and behavioral sciences.

In terms of participant demographics, men made up of the sample, women accounted for , and non-binary individuals represented . Geographically, the participants came from various regions: Portugal ( ), South Africa ( ), Italy ( ), United Kingdom ( ), Poland ( ), and other countries ( ).

The professional experience of the participants ranged across various stages in the software industry: had years of experience, had years, had years, had years, and had over 10 years of experience.

As for their roles in the industry, the majority were software developers or programmers ( ). This was followed by testers or QA engineers ( ), data analysts, data engineers, or data scientists ( ), team leads ( ), and UX/UI designers ( ).

Data analysis was implemented within the naturalistic inquiry paradigm [59] context, complemented by the constant comparison method [40]. The crucial role these strategies play in qualitative data acquisition and examination is significant. This iterative process facilitates initial theory development by identifying patterns and broader dimensions [39], derived from continual data comparison and analysis, and refining it in accordance with the participants’ input [50].

The Thematic Analysis approach was utilized to process the data. Thematic Analysis is a commonly employed method in qualitative research, which involves identifying, analysing, and reporting patterns or themes within the data, while providing a rich, detailed, and complex account of the data [20]. The structured methodology proposed by Gioia et al. [38] served as the analytical framework. Recent trends within the Management Science community have seen the adoption of this methodology, emphasizing its potential in reinforcing scientific rigour [44, 60]. The approach is structured and dedicated to encouraging comprehensive theoretical progression [38].

The Gioia methodology segments data processing into three stages. The inaugural stage revolves around recognizing first-order concepts, or in-vivo codes [99], which align closely with the participants’ own words, with minimal researcher-imposed categorization. These codes were then collated into broader themes, a process known as open coding [108].

In the subsequent stage, similarities and differences are identified, and emergent themes from these comparisons contribute to the explanation and depiction of the phenomena under investigation. We explored the associations between the concepts to create our high-level themes, employing axial coding. These are the second-order themes.

The final stage amalgamates similar second-order themes into aggregate dimensions, representing the apex of theoretical contribution. This process was iterative and process-oriented [61], and was perpetuated until theoretical saturation was accomplished [25].

The outcome of this investigation is the data structure, which encapsulates first-order terms, second-order themes, and aggregate dimensions for each of the nine theoretical dimensions of our investigation. Notably, the aggregate dimensions were not preconceived categories defined prior to the analysis; rather, they are the end product of a refined and iterative analytical process.

For example, in Table 1, which details the Data Structure of Perceived Usefulness of LLMs in Software Engineering, a clear progression from first-order concepts to second-order themes and aggregate dimensions is demonstrated. Consider the quote from participant R-15, which is categorized under first-order concepts as “Automating tasks, reducing time and effort, manual coding, documentation.” These concepts are then synthesized into the second-order theme of “Taskspecific efficiency improvements,” indicating a broader category of improvements in efficiency related to specific tasks. Subsequently, this second-order theme is aggregated into the dimension of
“Efficiency Improvement,” representing a generalized area of impact in software engineering through the use of LLMs. This example illustrates the analytical progression from specific participant quotes to broader thematic categories, demonstrating the methodology of our study.

The presentation of the data structure with their respective second-order themes and first-order concepts are reported in Tables 1-9.

The Technology Acceptance Model has been widely used in the study of technology adoption, focusing on two key predictors of acceptance: perceived usefulness and perceived ease of use [29]. In the context of software engineering, the perceived usefulness of Large Language Models can be examined by evaluating how they contribute to efficiency, productivity, and performance enhancement. Table 1 provides a summary of software engineers’ perceptions of LLMs in their work.
4.1.1 Efficiency Improvement. One of the main perceived benefits of LLMs is their ability to improve efficiency. As shown in Table 1, efficiency improvement is the most frequently mentioned aggregate dimension (55%). Engineers recognize that LLMs can automate certain tasks, reduce time and effort, and simplify monotonous tasks. For example, R-15 highlighted that LLMs can “increase my efficiency by automating certain tasks and reducing the time and effort it takes for manual coding and documentation.” This finding aligns with the TAM’s emphasis on perceived usefulness, which posits that users will adopt technology if they perceive it to be useful in enhancing their performance [29].
4.1.2 Task-Specific Benefits. Another aspect of perceived usefulness is the task-specific benefits LLMs provide, such as debugging, learning new features, and generating code snippets. As R-30 mentioned, LLMs have significantly increased their efficiency by helping them “debug code faster, learn about new features without scanning the whole documentation, and providing useful code snippets for work.” This category represents of the aggregate dimensions and supports the notion that perceived usefulness is an important predictor of LLM adoption [111].
4.1.3 Complementary Tool. LLMs are also viewed as a complementary tool to human expertise and judgment. R-17 pointed out that “language models have the potential to enhance productivity and efficiency in software engineering, but they should be used as a tool alongside human expertise and judgment.” This perception highlights the importance of balancing the benefits of LLMs with the need for human oversight, an aspect that may influence the overall perceived usefulness of the technology.
4.1.4 Limited Applicability and Quality Concerns. While many respondents reported positive perceptions of LLMs, some expressed concerns about their limited applicability ( ) and quality concerns (9%). For instance, R-21 mentioned that LLMs are “nice for generic tasks, but the models have zero knowledge about our internal APIs so they’re really hard to apply.” R55 also noted that while LLMs may help, “you have to review and understand the code anyway. So I don’t know if it makes you more efficient.” These concerns suggest that while LLMs can offer benefits in certain situations, their usefulness may be limited by the need for review and adaptation to specific contexts. This finding is consistent with the TAM literature, which highlights that the perceived usefulness of a technology is not only determined by its benefits but also by its limitations [111].

The perceived usefulness of LLMs in software engineering, as reflected in the efficiency improvement, task-specific benefits, and complementary nature of the technology, supports the potential for
widespread adoption. However, the concerns related to limited applicability and quality highlight the importance of addressing these limitations to enhance the perceived usefulness and, consequently, the acceptance of LLMs. This analysis aligns with the TAM framework, which emphasizes that perceived usefulness is a critical determinant of technology acceptance [29].

In this subsection, we present the results of our qualitative analysis of the questionnaire survey statements, highlighting the key factors that influence the perceived ease of use of Large Language Models in software engineering. Our analysis draws upon the Technology Acceptance Model framework [29], which posits that the perceived ease of use and perceived usefulness are essential determinants of technology adoption. We have identified several aggregate dimensions that explain the perceived ease of use of LLMs and present them in separate subsubsections, providing empirical evidence from the questionnaire survey statements (Table 2).
4.2.1 Learning Process. Our analysis reveals that the learning process is a crucial factor influencing the perceived ease of use of LLMs in software engineering. As shown in Table 2, R-54 reported that “once I got familiar with the technology, it became much easier to use.” This finding aligns with the Technology Acceptance Model proposed by [29], which suggests that the perceived ease of use of a technology is directly related to its adoption. Moreover, prior research has emphasized the role of
learning in the adoption of new technologies [110]. In this context, the learning curve associated with LLMs appears to be an essential determinant of their perceived ease of use.
4.2.2 Prior Experience. The questionnaire survey data also underscore the importance of prior experience in shaping the perceived ease of use of LLMs. For example, R-20 stated that “I think it is easy when you know the different concepts.” This observation is consistent with the literature on technology adoption, which suggests that individuals with prior experience in related technologies are more likely to perceive a new technology as easy to use [24]. In the case of LLMs, having a background in programming languages or natural language processing (NLP) could facilitate their adoption in software engineering.
4.2.3 Individual Differences. Another key theme that emerged from our analysis is the role of individual differences in shaping the perceived ease of use of LLMs. As R-9 noted, “it depends on the person and how they are used to work.” This finding supports the notion that individual characteristics, such as cognitive style and personal innovativeness, can influence the perceived ease of use of a technology [94]. In the context of LLMs, the extent to which software engineers perceive them as easy to use may depend on their unique preferences, learning styles, and problem-solving approaches.
4.2.4 Intuitiveness and User Interface. The intuitiveness of LLMs and their user interface design also emerged as important factors in our analysis. For instance, R-89 mentioned that “they were pretty much made for ease of use by the average consumer.” This observation aligns with the work of [69], who argued that a well-designed user interface can significantly enhance the perceived ease of use of a technology. In the case of LLMs, an intuitive and user-friendly interface could facilitate their adoption among software engineers.
4.2.5 Task Complexity. Finally, the complexity of the tasks that LLMs are used for in software engineering appears to influence their perceived ease of use. As R-53 noted, “the difficulty to learn how to use them effectively can vary as it depends on how you’re using it, but for the most part, it ranges from not too hard to very hard.” This finding is consistent with the Task-Technology Fit model [41], which posits that thefit between the technology and the task it is intended for affects the technology’s perceived ease of use and, ultimately, its adoption. In the context of LLMs, it seems that software engineers may find them easier to use for certain tasks, while others might require a higher level of expertise and knowledge.

In summary, our analysis identified several aggregate dimensions that explain the perceived ease of use of LLMs in software engineering, including the learning process, prior experience, individual differences, intuitiveness and user interface, and task complexity. These factors provide a nuanced understanding of the adoption of LLMs in software engineering and their connection to the theoretical framework of the Technology Acceptance Model. By incorporating the empirical evidence from the questionnaire survey statements and drawing on relevant literature, our findings contribute to the ongoing conversation about the role of LLMs in software engineering and the factors that influence their adoption.

The Technology Acceptance Model has been widely used to understand the factors influencing the adoption of new technologies in various contexts, such as software engineering [30,110]. According to the TAM, behavioral intention, which reflects the likelihood of an individual to use a specific technology, is influenced by two main factors: perceived usefulness and perceived ease of use [30]. In this subsection, we explore the behavioral intention of software engineers in relation to the

adoption of Large Language Models, focusing on the aggregate dimensions emerged from the performed analysis (Table 3).
4.3.1 Code Improvement and Maintenance. A significant portion of software engineers indicated their intention to use LLMs to improve and maintain their codebase. This finding aligns with the TAM’s concept of perceived usefulness, as using LLMs for code refactoring, adherence to design patterns, and implementation of SOLID principles can enhance software quality and maintainability [76]. For instance, R-8 mentioned, “I am considering purchasing a ChatGPT-4 subscription, mainly to refactor (legacy) code or to make it adhere to certain design patterns. It could also help refactoring code to make it more SOLID.” This quote highlights the potential value of LLMs in addressing common software engineering challenges.
4.3.2 Efficiency and Automation. LLMs were perceived to be useful for automating repetitive tasks and increasing efficiency. This perception corresponds to both perceived usefulness and perceived ease of use in the TAM, as task automation can lead to time savings and streamline the development process [110]. R-35 stated, “I believe I may start using a language model more and more, especially to automate tasks which can be performed by a language model and which take a significant amount of time.” The adoption of LLMs for task automation can potentially improve software engineers’ productivity.
4.3.3 Learning and Problem Solving. The use of LLMs for learning and problem solving was another theme identified, which is in line with the TAM’s perceived usefulness. Software engineers expressed the intention to use LLMs for tasks such as finding documentation, clarifying confusing code, and seeking information on programming-related questions. As R-25 stated, “Very likely. Mostly to find documentation for libraries, refactor and clarify confusing code.” LLMs can serve as a valuable learning and problem-solving tool for software engineers, supporting continuous professional development.
4.3.4 Specialized Applications. Respondents mentioned the potential use of LLMs for specific tasks, such as writing basic functionalities, defining tasks, and composing emails. This theme is related to the perceived usefulness of LLMs in addressing particular software engineering needs. R-62, for example, mentioned, “Very likely. For writing basic functionalities, defining tasks, for emails.” The
adoption of LLMs for specialized applications can provide targeted benefits to software engineers in their daily work.
4.3.5 Adoption Barriers and Concerns. Despite the potential benefits of LLMs, some software engineers expressed concerns and barriers to adoption, such as cost, dependency on third-party services, and potential ethical issues. These concerns align with the TAM’s concept of perceived ease of use, as they can hinder the adoption of LLMs [110]. For instance, R-60 stated, “The cost and dependency on a third-party service might be a concern.” Understanding and addressing these concerns is essential for promoting LLM adoption in software engineering.

In conclusion, our analysis reveals several factors that influence the behavioral intention of software engineers to adopt LLMs, aligning with the theoretical framework of the TAM. LLMs are perceived as useful for code improvement and maintenance, efficiency and automation, learning and problem-solving, and specialized applications, while some adoption barriers and concerns persist. By understanding these factors, we can better support the integration of LLMs into software engineering practices and promote their adoption to enhance productivity and software quality.

The compatibility of Large Language Models in software engineering is a crucial factor in understanding their adoption and impact on software development practices. Compatibility refers to the degree to which an innovation is perceived as being consistent with existing values, past experiences, and the needs of potential adopters [85]. This subsection presents a thematic analysis of the compatibility of LLMs in software engineering based on the responses of software engineers, which are summarized in Table 4. We have identified four aggregate dimensions, as detailed in the following sub-subsections: Improved Efficiency, Assistance and Support, Similarity to Current Practices, and Adaptation and Learning.
4.4.1 Improved Efficiency. Improved Efficiency was the most frequently occurring theme in the data, with of the responses reflecting this aspect of compatibility. The use of LLMs in software engineering tasks is perceived to speed up the development process, automate mundane tasks, and ultimately improve overall efficiency. One respondent (R-19) highlighted that LLMs “can be used to automate certain tasks in software engineering,” thus reducing the time and effort spent on repetitive tasks. Similarly, R-35 noted that using a language model “will speed up the tasks of going to look for specific pieces of code from multiple websites.” These findings align with the literature, where compatibility is a key factor for technology adoption [105].
4.4.2 Assistance and Support. Assistance and Support emerged as the second most frequent theme in the data, representing of the responses. Respondents highlighted the value of LLMs in providing help and support, particularly in situations where traditional search methods fail to deliver desired results. R-1 mentioned that LLMs can provide an “extra hand and assistance for things I don’t know and can’t find with a traditional search.” This demonstrates that LLMs’ ability to offer contextually relevant and targeted assistance is seen as an important aspect of their compatibility with software engineering practices.
4.4.3 Similarity to Current Practices. Similarity to Current Practices was reported by of the respondents. This theme suggests that the adoption of LLMs in software engineering is facilitated by their perceived similarities to existing tools and practices. R-15 noted that there is “not much of a difference as the language model is just used to assist my current software engineering practices.” R-5 similarly stated that using LLMs is “like Googling but I don’t need to filter as much information.” The perceived similarity to current practices can influence the adoption of LLMs as it reduces the barriers to their integration into existing workflows [85, 105].
4.4.4 Adaptation and Learning. Adaptation and Learning was reported by of the respondents. This theme highlights the importance of learning and adapting to new tools and techniques in the software engineering domain. R-46 expressed that using LLMs is “something new: you have to learn how to use it.” Similarly, R-87 mentioned that using a language model “represents a new paradigm for .” This theme indicates that the compatibility of LLMs in software engineering can be enhanced by promoting learning and adaptation among software engineers. The adoption of LLMs can thus be facilitated by providing resources and training to help engineers understand and integrate these tools into their daily work.

In conclusion, this subsection has explored the compatibility of LLMs in software engineering by analyzing the aggregate dimensions derived from the responses of software engineers. These dimensions-Improved Efficiency, Assistance and Support, Similarity to Current Practices, and Adaptation and Learning-provide a comprehensive understanding of the factors that influence the compatibility of LLMs in software engineering. By linking these dimensions to the Diffusion of Innovation theory [85], this analysis offers valuable insights into the factors that contribute to the adoption and integration of LLMs into software engineering practices. This understanding can help inform the development of LLMs that are more compatible with existing workflows and practices, ultimately leading to more widespread adoption and use in the software engineering domain.

The complexity of adopting Large Language Models in software engineering is a critical aspect of understanding their diffusion and impact on the industry. According to the Diffusion of Innovation theory, the complexity of an innovation influences its adoption rate, with more complex innovations facing a slower adoption [85]. The thematic analysis of the questionnaire survey data (Table 5)

reveals several aggregate dimensions that contribute to the perceived complexity of LLMs in software engineering. In this subsection, we discuss each of these dimensions and their implications for the adoption of LLMs, linking them to the relevant literature and the Diffusion of Innovation theory.
4.5.1 Job Security Concerns. The fear of job loss and skill devaluation emerged as a significant concern among respondents ( frequency). Respondent R-15 stated, “I’m concerned that it can automate a lot of tasks and make most of my work obsolete.” This perspective aligns with research on the potential disruptive effects of AI and automation on the job market [35]. According to the Diffusion of Innovation theory, innovations that are perceived to threaten job security are likely to face resistance [85]. To mitigate this challenge, organizations should communicate the benefits of LLMs and focus on upskilling and reskilling employees [12,101].
4.5.2 Dependence and Complacency. Some respondents ( frequency) expressed concerns about junior programmers relying too much on LLMs, leading to a decline in code understanding and increased reliance on these models. Respondent R-34 explained, “My concern is other junior programmers using it without understanding the code and causing bugs (more work for me).” This challenge can be addressed by promoting the responsible use of LLMs and ensuring that programmers have a strong foundation in coding concepts.
4.5.3 Data Security and Privacy. Data security and privacy concerns were identified by of respondents. They expressed concerns about LLMs being trained on sensitive data, potentially leading to privacy breaches. Respondent R-17 mentioned, “In terms of privacy, as language models can be trained on sensitive or personal data, such as emails, messages, or documents. This may raise privacy and data protection concerns.” To address this issue, developers should ensure that LLMs are trained on secure, anonymized datasets and that privacy regulations are followed.
4.5.4 Quality and Accuracy of Generated Code. Respondents also raised concerns about the quality and accuracy of code generated by LLMs (13% frequency). Respondent R-49 remarked, “Language models aren’t perfect, so I would be afraid that they would cause errors.” Ensuring the reliability and accuracy of generated code is essential for LLM adoption [81]. To address this issue, developers should establish best practices for code review and validation, as well as invest in improving the models’ performance [115].
4.5.5 Ethical and Legal Considerations. Ethical and legal considerations, such as authorship and intellectual property rights, were identified by of respondents. Respondent R-28 simply stated, “Author rights are tricky to attribute.” Organizations should consider the ethical implications of using LLMs and establish guidelines for their use to ensure compliance with existing laws and regulations [64].
4.5.6 Bias and Explainability. Some respondents ( frequency) highlighted concerns about the potential biases in outputs and the lack of explainability in their decision-making processes. Respondent R-62 expressed, “The biases in the model can have unintended consequences.” It is essential to address these issues to ensure the responsible use of LLMs in software engineering. Organizations can invest in research to reduce biases and improve the explainability of LLMs to enhance their trustworthiness and adoption [7].
4.5.7 Integration and Compatibility. Integration and compatibility issues were mentioned by of respondents, who expressed concerns about the ability of LLMs to work seamlessly with existing software development tools and practices. Respondent R-21 stated, “Integrating the model into the current workflow might be challenging.” To facilitate the adoption of LLMs, developers should ensure that these models are compatible with existing tools and can be easily integrated into the software development process.

In conclusion, the complexity of LLM adoption in software engineering is multifaceted, encompassing various concerns, such as job security, dependence, data security, code quality, ethical issues, bias, and integration challenges. By addressing these concerns, organizations can facilitate the adoption of LLMs and leverage their potential benefits in software engineering. This discussion, grounded in the thematic analysis of the questionnaire survey data and the Diffusion of Innovation theory, contributes to the understanding of the factors that affect LLM adoption in the software engineering context.

The relative advantage of Large Language Models in software engineering is a key factor in their adoption, as postulated by the Diffusion of Innovation theory [85]. Our qualitative data analysis, based on Gioia’s Methodology, highlights the various aspects of LLMs that contribute to their perceived benefits over current methods. The following sub-subsections present the Aggregate Dimensions derived from our analysis and discuss their implications in relation to the relative advantage construct (Table 6).
4.6.1 Time Efficiency. A recurring theme in our analysis was the time efficiency provided by LLMs, as reported by of respondents. Respondents appreciated the ability of LLMs to quickly complete tasks, search for relevant information, and provide solutions to coding issues. For example, R-25 noted that LLMs significantly reduced time spent searching for information: “I believe the best thing is the time spent searching for certain things is way lower than before.” This time efficiency can be attributed to the natural language processing capabilities of LLMs, which enable users to communicate their needs more effectively and rapidly obtain tailored solutions [14].
4.6.2 Code Quality. Improvements in code quality emerged as another key advantage of LLMs, with of respondents highlighting the positive impact on their work. Respondents reported that LLMs provided clearer, more understandable code, which reduced errors and improved overall code robustness. R-37 stated: “It generates a simpler and more understandable code, working in a more organized way and reducing errors.” This improvement in code quality is a result of LLMs’ ability to analyze and learn from vast amounts of source code, allowing them to provide optimal solutions based on best practices [31].
4.6.3 User Experience. LLMs were noted to enhance the overall user experience, with of respondents mentioning the ease of use and communication with the models. R-67 commented on the human-like interaction: “Language models are easier to use and faster because you can send messages like for human.” The improved user experience can be attributed to the natural language understanding capabilities of LLMs, which allow them to interpret and respond to user inputs more effectively than traditional methods [78].
4.6.4 Learning and Skill Development. LLMs were also found to facilitate learning and skill development, as reported by of respondents. Respondents appreciated the ability of LLMs to simplify the learning process and reduce the time spent on mastering technical concepts. R-23 explained: “I think with language models you don’t have to spend that much time learning ‘technical’ things.” This can be linked to the contextual understanding and knowledge retention capabilities of LLMs, which allow them to provide tailored guidance and support for users with varying levels of expertise.
4.6.5 Customization and Personalization. Finally, customization and personalization were highlighted as advantages by of respondents. LLMs were praised for their ability to provide more digestible information and adapt responses to user preferences. R-94 described the flexibility of LLMs: “It gives more digested information, and we can ‘mold’ the information how we want (e.g., asking the language model to respond using short sentences, or to explain in detail certain topics, etc).” This aspect of LLMs can be attributed to their capacity for understanding context and user preferences, allowing them to generate more relevant and personalized responses [72].

In summary, our thematic analysis revealed several key aspects of LLMs that contribute to their perceived relative advantage in software engineering, including time efficiency, code quality, user experience, learning and skill development, and customization and personalization. These findings align with the Diffusion of Innovation theory, suggesting that the adoption of LLMs in
software engineering can be facilitated by their ability to provide clear benefits over existing methods [85]. Moreover, our results highlight the potential of LLMs to revolutionize the field of software engineering by streamlining processes, enhancing user experience, and fostering continuous learning and improvement.

The adoption of Large Language Models in software engineering is influenced by various factors. One key factor is the social influence from peers and colleagues, as suggested by the Social Cognitive Theory [9]. The current analysis aims to provide a rationale on how the data explains the “social influence” in relation to the adoption of LLMs in software engineering and how it links to the theoretical framework of the Social Cognitive Theory. Our analysis (Table 7) revealed four aggregate dimensions representing the range of social influences in the adoption of LLMs: No Influence, Low Influence, Moderate Influence, and High Influence.
4.7.1 No Influence. Our analysis revealed that of the respondents reported no influence from their colleagues or peers on their decision to use LLMs (e.g., R-66, R-24, R-58). This finding suggests that a considerable proportion of software engineers make independent decisions about whether to adopt LLMs. This aligns with the literature on individual agency and self-efficacy in the Social Cognitive Theory [10]. These software engineers may rely on their own evaluation of the technology and personal preferences, rather than the opinions or experiences of their colleagues.
4.7.2 Low Influence. Low influence was reported by of the respondents (e.g., R-45, R-99). This indicates that some software engineers may be slightly influenced by their peers, but ultimately retain a high degree of autonomy in their decision-making. This finding suggests that while social influence may play a role in the adoption of LLMs, individual factors, such as personal interest and perceived utility, may also significantly contribute to the decision-making process [5].
4.7.3 Moderate Influence. Our analysis revealed that of the respondents reported moderate influence from their peers and colleagues (e.g., R-9, R-82). This suggests that a significant proportion of software engineers value the input and feedback of their peers when deciding whether to adopt

LLMs. This finding is consistent with the Social Cognitive Theory, which emphasizes the role of observational learning and vicarious experiences in shaping individual behavior [9]. In the context of LLM adoption, this moderate influence may result from a combination of individual factors and the experiences of colleagues.
4.7.4 High Influence. Finally, 26% of the respondents reported high influence from their peers and colleagues (e.g., R-97, R-79, R-27). This finding suggests that a considerable proportion of software engineers are strongly influenced by the collective use and enthusiasm for LLMs within their professional circles. This result aligns with the Social Cognitive Theory’s focus on the reciprocal interactions between individuals and their social environment, as well as the literature on technology adoption in organizations [85]. In this case, the high level of influence may stem from the perceived benefits of LLMs, collaboration, and shared enthusiasm for exploring the technology’s possibilities.

In summary, our analysis revealed a diverse range of social influence levels in the adoption of LLMs in software engineering. While some software engineers reported no influence from their colleagues or peers, others indicated low, moderate, or high levels of influence. These findings highlight the complex interplay between individual factors, such as self-efficacy and personal interest, and social influences, as posited by the Social Cognitive Theory. The understanding of these various levels of social influence can inform future research on the adoption of LLMs and other emerging technologies in software engineering, as well as organizational strategies for encouraging their appropriate use.

Self-efficacy, an integral construct within the Social Cognitive Theory, refers to an individual’s belief in their ability to perform specific tasks and achieve desired outcomes [10]. In the context of software engineering, the self-efficacy of developers using Large Language Models can impact their adoption and effective utilization. Based on our thematic analysis, we identified three aggregate dimensions that contribute to understanding self-efficacy in relation to LLMs adoption: (1) Importance of being seen as cutting-edge, (2) Focus on practicality and efficiency, and (3) Low importance of being
seen as cutting-edge. These dimensions will be discussed in detail in the following subsubsections, highlighting their role in shaping developers’ self-efficacy and adoption behavior of LLMs in software engineering. The data structure can be found in Table 8.
4.8.1 Importance of Being Seen as Cutting-edge. As shown in the Table, of respondents emphasized the importance of being seen as someone who uses cutting-edge technology in their work. This perception aligns with the notion of self-efficacy, as developers who consider themselves proficient in the latest technologies tend to have higher confidence in their capabilities [24]. For example, R-2 expressed that being up-to-date with cutting-edge technology is crucial in their line of work, and R-30 mentioned the fear of being replaced by someone perceived as more proficient in cutting-edge technology. This focus on staying current with technological advancements may encourage developers to adopt LLMs to showcase their expertise and maintain a competitive edge in the industry [110].
4.8.2 Focus on Practicality and Efficiency. Our analysis revealed that of respondents highlighted the importance of practicality and efficiency in their work, demonstrating a preference for using technologies that effectively solve problems or meet client needs, rather than simply being cuttingedge. This focus reflects a more task-oriented self-efficacy, where developers concentrate on finding the most appropriate tools for the job. R-10, for instance, emphasized the importance of staying ahead of the curve and delivering innovative solutions to meet evolving customer needs, while R-19 and R-100 mentioned the balance between adopting cutting-edge technologies and ensuring efficiency in their work. This suggests that developers with a focus on practicality and efficiency will adopt LLMs only when they perceive these models to provide tangible benefits to their work.
4.8.3 Low Importance of Being Seen as Cutting-edge. A smaller group of respondents ( ) assigned low importance to being seen as using cutting-edge technology in their work. These developers prioritize stability, effectiveness, or other factors over adopting the latest technologies, which may influence their self-efficacy in terms of LLM adoption [104]. For instance, R-21 expressed a preference for stability over implementing bleeding-edge technology, and R-66 stated that their focus is on using the most effective tools for the task at hand, regardless of whether they are cutting-edge. This finding suggests that developers with a low emphasis on cutting-edge technology may be less inclined to adopt LLMs unless they demonstrate clear benefits over existing tools.

In conclusion, our thematic analysis of self-efficacy in relation to LLM adoption in software engineering has identified three aggregate dimensions that provide valuable insights into developers’ perceptions and behaviors. These dimensions suggest that the importance assigned to cutting-edge technology, along with the focus on practicality and efficiency, plays a critical role in shaping developers’ self-efficacy and their likelihood of adopting LLMs.

The adoption of Large Language Models in software engineering is influenced by various environmental factors that shape organizational behaviors and decision-making processes. Drawing on the Social Cognitive Theory framework [9], this study investigates how environmental factors affect the extent to which organizations are supportive of adopting LLMs as a standard technology. The following sections present the findings of our thematic analysis, which revealed five aggregate dimensions related to environmental factors: Supportive Attitude, Neutral Stance, Conditional Support, Limited Support, and Lack of Support. Each dimension is discussed in detail with references to the data presented in Table 9.

4.9.1 Supportive Attitude. The most prevalent aggregate dimension in our data, Supportive Attitude, captures the positive and proactive stance of organizations in promoting LLM adoption ( frequency). This dimension encompasses strong organizational encouragement and investment in the technology to facilitate its integration into software engineering practices [85]. Respondent R-5, for instance, highlights the active promotion of LLMs by their organization, stating that they “pay for it and encourage us to use it.” Similarly, R-45 reports a “very supportive” attitude, illustrating the extent to which some organizations prioritize the adoption of LLMs.
4.9.2 Neutral Stance. The Neutral Stance dimension reflects organizations that neither actively support nor oppose the adoption of LLMs ( frequency). This stance may be attributed to the lack of awareness or knowledge about LLMs, or a wait-and-see approach to gauge the potential benefits and drawbacks of the technology [54]. Respondent R-84 describes their organization’s position as “neutral, up to the employee,” implying that the decision to use LLMs is left to individual discretion rather than being guided by organizational policy.
4.9.3 Conditional Support. Some organizations in our sample exhibit a Conditional Support dimension ( frequency), characterized by their willingness to adopt LLMs provided certain criteria are met, such as the technology demonstrating clear benefits or aligning with specific organizational objectives [85]. In this context, R-26 notes that their organization supports LLM adoption “if it brings more advantages to the team and the way we work, and make things faster.”
4.9.4 Limited Support. The Limited Support dimension ( frequency) represents organizations that only support the use of LLMs in specific contexts or for certain tasks. This selective approach may stem from concerns related to security, privacy, or ethical considerations. For example, R-64 explains that their organization “opposes them when working on new features but for debugging, they can be quite helpful.”

In summary, our thematic analysis of environmental factors affecting LLM adoption in software engineering has identified five aggregate dimensions, ranging from strong support to active opposition. These dimensions provide valuable insights into the diverse organizational attitudes and contexts that shape the integration of LLMs into software engineering practices, contributing to a deeper understanding of the role of environmental factors in the SCT framework.

Our findings demonstrate the potential benefits of LLMs in software engineering, highlighting their impact on automating repetitive tasks, enhancing problem-solving abilities, facilitating learning and understanding, improving code quality, assisting in debugging and optimization, and increasing overall efficiency. However, concerns about the limitations of LLMs, such as their lack of knowledge about internal APIs and the need for human oversight, emphasize the importance of human expertise in utilizing these tools effectively.

The perceived ease of use of LLMs in software engineering is influenced by factors such as integration with existing tools and workflows, accessibility and comprehensibility of documentation, customizability and adaptability, and support from the developer community. These factors are crucial in facilitating the adoption of LLMs and their seamless integration into the software engineering domain.

The behavioral intention to adopt LLMs in software engineering is shaped by the perceived usefulness, perceived ease of use, social influence, and facilitating conditions. These factors collectively contribute to creating an environment conducive to the successful integration of LLMs into software engineering practices.

Regarding the Diffusion of Innovation theory, the compatibility of LLMs in software engineering is influenced by dimensions such as improved efficiency, assistance and support, similarity to current practices, and adaptation and learning. However, concerns about dependency and skill degradation, privacy, security and data protection, job displacement, and labor market implications, and accuracy, reliability, and explainability underline the complexity of LLM adoption in this domain.

Our findings also reveal the relative advantage of LLMs over traditional methods in software engineering. Factors such as time efficiency, code quality, user experience, learning and skill development, and customization and personalization contribute to the perceived benefits of LLMs in this domain.

From a Social Cognitive Theory perspective, the influence of peers and colleagues on LLM adoption in software engineering varies from no influence to high influence. Self-efficacy is influenced by factors such as the importance of being seen as cutting-edge, a focus on practicality and efficiency, and the low importance of being seen as cutting-edge. Environmental factors, such as supportive organizational culture, uncertainty, security concerns, neutral organizational culture, resistance to change, and limited or marginal support, also play a role in LLM adoption.

In conclusion, the adoption of LLMs in software engineering is a multifaceted phenomenon influenced by a variety of factors and theoretical perspectives. Our study provides valuable insights into the key dimensions and concerns that shape the integration of LLMs in the software engineering domain, paving the way for future research and practice in this area.

In this section, we introduce the Human-AI Collaboration and Adaptation Framework (HACAF), an innovative theoretical model designed to understand and predict the adoption of Generative AI tools in software engineering. The HACAF derives its components from several established theories including the Technology Acceptance Model, Diffusion of Innovation Theory, Social Cognitive Theory, the Unified Theory of Acceptance and Use of Technology (UTAUT), and the personal innovativeness construct.

While the original TAM, DOI, and SCT theories provide robust theoretical foundations for understanding technology acceptance and adoption, our qualitative investigation indicated the necessity for a more nuanced model. The HACAF is, therefore, not merely an amalgamation of these theories, but also an evolution, as it incorporates additional facets revealed in our research.

The inclusion of constructs from UTAUT addresses the need for a greater focus on social influence and facilitating conditions, elements that emerged as significantly influential in our qualitative findings. The additional integration of the personal innovativeness construct into HACAF is motivated by the observed variability in adoption behaviors among software engineers, even within the same contextual environment, implying a role for individual differences in innovative tendencies.

By merging these four main components into the HACAF, we not only leverage the collective strengths of these prominent theories but also account for the additional complexities of technology adoption that surfaced in our qualitative investigation. Consequently, the HACAF represents a tailored approach that reflects the multifaceted nature of LLM adoption in software engineering. This comprehensive framework aims to provide a deeper understanding of the complex dynamics involved in the adoption of LLMs and act as a guide for future research and practice in this rapidly evolving domain.

Perceptions about the technology is a cornerstone of HACAF, rooted in TAM. This construct denotes a software engineer’s evaluation of the usefulness, ease of use, and relative advantage of LLMs. The qualitative data substantiates this construct by revealing that software engineers
assess LLMs based on their potential to streamline coding processes, enhance code quality, and expedite project timelines. Furthermore, the focus on practicality and efficiency found in our study underscores the importance of this construct in influencing the adoption of LLMs.

Compatibility factors, informed by the Diffusion of Innovation theory, illustrate the degree to which LLMs align with the existing values, experiences, and needs of potential adopters. Our qualitative investigation underpins this construct by highlighting the importance of the fit of LLMs within current software development workflows. Developers who perceive a high degree of fit, irrespective of the technology’s cutting-edge nature, are more likely to adopt LLMs, reinforcing the relevance of this construct.

Social factors, drawing on UTAUT and the concept of computer self-efficacy, emphasize the influence of the social environment and an individual’s belief in their abilities to use LLMs. The investigation’s findings lend weight to this construct by indicating that the importance of being seen as cutting-edge and the developer’s self-efficacy could drive LLM adoption. The role of peer approval and the belief in one’s competence to master LLMs surfaced as significant influencers, further establishing this construct’s salience in the HACAF model.

Personal and environmental factors bring into play the role of personal innovativeness and organizational support. Personal innovativeness represents an individual’s predisposition towards new technologies, and organizational support captures the perceived facilitating conditions within an organization for the use of LLMs. Both elements emerged as significant in our investigation. Our data evidenced how individual readiness to experiment with LLMs and the organization’s stance towards LLMs, ranging from active support to outright opposition, directly influence the likelihood of LLM adoption.

In conclusion, the HACAF model, informed and justified by our qualitative investigation and underpinned by established theoretical constructs, offers a nuanced understanding of the interplay of individual and organizational factors influencing the adoption of LLMs in software engineering. By grounding this framework in both empirical evidence and theory, we aim to provide a solid foundation for further empirical scrutiny and contribute to the understanding of AI technology adoption dynamics.

The previous section’s theoretical foundation, bolstered by the qualitative investigation, serves as the basis for operationalizing the Human-AI Collaboration and Adaptation Framework (HACAF). We now translate these theoretical constructs into four main determinants of the intention to use LLMs: perceptions about the technology, compatibility factors, social factors, and personal and environmental factors, and formulate hypotheses based on these constructs, graphically represented in Figure 1.

Perceptions about the technology encapsulate the perceived usefulness, ease of use, and relative advantage of LLMs. As our qualitative data revealed, LLMs’ perceived usefulness and relative advantage, such as streamlining coding processes and enhancing code quality, have a significant bearing on their adoption. The ease of use was another critical factor, as intuitive and user-friendly LLMs are more likely to be adopted by software engineers. Thus, drawing upon the Technology Acceptance Model, we propose:

Hypothesis. H1: Positive perceptions about the technology (PT), encompassing perceived usefulness, ease of use, and relative advantage, will increase the Intention to Use (IU) LLMs in a software engineering context.

Compatibility factors address the extent to which LLMs align with the existing values, experiences, and needs of potential adopters. As the qualitative investigation underlines, LLMs’

compatibility with current software development workflows significantly influences adoption decisions. Software engineers are more likely to adopt LLMs when they perceive a high degree of fit with their work practices. Following this and the Diffusion of Innovation theory, we hypothesize:

Hypothesis. H2: Positive perceptions about the technology (PT) will enhance the Compatibility Factors (CF). H3: Enhanced compatibility factors (CF) will in turn increase the Intention to Use (IU) LLMs.

Social factors, which include social influence and self-efficacy, play an important role in adoption decisions. Our qualitative study emphasized that peer approval and an individual’s belief in their ability to use LLMs could significantly influence the intention to use these technologies. Based on this and the Unified Theory of Acceptance and Use of Technology (UTAUT) and the concept of computer self-efficacy, we posit:

Hypothesis. H4: Positive perceptions about the technology (PT) will increase Social Factors (SF). H5: Increased social factors (SF) will enhance the Intention to Use (IU) LLMs.

Finally, Personal and environmental factors, including personal innovativeness and organizational support, contribute to the complexity of the model. As underscored by our investigation, an individual’s willingness to experiment with LLMs and the perceived supportiveness of the organization can be decisive for LLM adoption. Thus, we hypothesize:

Hypothesis. H6: Personal and Environmental Factors (PEF), specifically personal innovativeness and organizational support, will moderate the relationship between Perceptions about the technology
and IU LLMs, strengthening the positive effect of Perceptions about the technology on Intention to Use LLMs.

In the subsequent phase of our research, we transitioned from the qualitative insights garnered in the initial study to a quantitative validation. The qualitative findings from our initial study played a foundational role in shaping the subsequent phases of our research. Also here, we used the SIGSOFT Empirical Standard for Questionnaire Surveys and Multi-Methodology and Mixed Methods Research [79].

Partial Least Squares – Structural Equation Modeling (PLS-SEM): This method was chosen based on its ability to validate complex models, especially when the research is in an exploratory stage, as is the case with our study on the adoption dynamics of Generative AI tools in software engineering.

Scale Development: The themes and patterns identified in our qualitative findings were instrumental in developing the scales for our quantitative study. These scales were designed not only to encapsulate the core of our qualitative insights but also to render them into measurable metrics. In line with established methodological guidelines [91], we adapted existing scales to ensure robustness and relevance. A detailed breakdown of these scales can be found in Table 20.

Survey Data Collection: The design of our survey was directly informed by the conclusions drawn from our qualitative exploration. Questions were framed to test the hypotheses that emerged from the qualitative study, ensuring a coherent flow between the two research phases.

Participant Demographics: The demographics were chosen based on the insights from the qualitative study to ensure that the quantitative study sample was representative of the broader population of software engineers who might be impacted by the adoption of Generative AI tools.

Evaluation of the Measurement Model: The constructs used in the measurement model were derived from the themes of the qualitative study. This ensured that the quantitative analysis was grounded in the real-world experiences and perceptions of our initial study participants.

Evaluation of the Structural Model: The relationships tested in the structural model were informed by the patterns and relationships identified in the qualitative study. This ensured that our quantitative validation was directly aligned with the insights from our initial exploration.

Partial Least Squares – Structural Equation Modeling (PLS-SEM) is a multifaceted statistical examination designed to substantiate latent and unseen variables (or constructs) through multiple observable indicators. This method is particularly useful for theory development studies and is increasingly adopted in empirical software engineering [91]. PLS-SEM can address multiple interconnected research queries in one extensive analysis, making it a popular choice across other fields such as Management, Information Systems Research, and Organizational Behavior. As Gefen et al. suggest, SEM is commonly employed to authenticate tools and verify connections between constructs [37]. The subsequent evaluation and analysis of the PLS-SEM model adhere to the latest guidelines and recommendations for research in software engineering by Russo & Stol [91].
6.1.1 Scale Development. The survey was crafted with the assistance of supplementary theory. We structured our survey by adapting instruments from previous research. All items utilized to define each construct and the references used to shape the questions are summarized in Table 20. Each construct was assessed through uni-dimensional items on a 7-point Likert scale indicating levels of agreement.

Initially, a pre-test was conducted with three potential respondents (software engineers) to assess the survey’s usability, reasoning, and phrasing. The usability received positive feedback, and some minor issues with the reasoning and phrasing were identified and subsequently addressed.
6.1.2 Survey Data Collection. The minimum sample size was determined by conducting an a priori power analysis with G*Power. With an effect size of , significance level at , and a power of , the smallest size required for seven predictors is 153 .

A cluster sampling strategy was utilized for data collection, facilitated through the academic data collection platform, Prolific. The survey was delivered via Qualtrics, randomizing the order of questions within their blocks to reduce response bias.

A multi-phase screening process was implemented to ensure the integrity of the collected data. Data collection was carried out between April and June 2023.

Pre-screening: During the initial selection phase, participants were chosen based on specific self-reported criteria. These included proficiency in Computer Programming, employment in the Software industry on a Full-time basis, a non-student status, and an Approval rate of . On Prolific, the approval rate represents the percentage of a participant’s submissions that have been approved by researchers, indicating their reliability and consistency in providing quality responses. To emphasize our target demographic, our survey was titled “[SOFTWARE ENGINEERS ONLY] Human-AI Collaboration and Adaptation.” This title was chosen to clearly communicate to professionals who met the pre-screening criteria but were not actively working as software engineers. In total, 831 potential participants met these criteria.

Competence Screening. To ensure the accuracy of our pool, participants were asked to complete a questionnaire containing three competency-based questions about software design and programming. Additionally, they conveyed their familiarity with, and usage of, Generative AI tools, at least to a certain extent. This helped confirm the reliability of their self-reported skills. This process resulted in a reduced pool of 606 participants.

Quality & Competence Screening. To ensure the accuracy of our pool, we added one singleitem screening question in our survey from Danilova et al. [28], asking “Which of these websites do you most frequently use as aid when programming?” with ‘Stack Overflow’ as the correct question. Additionally, we added three random attention checks to further ensure data quality. A total of 220 completed questionnaires were received, but 36 were discarded due to failure on at least one attention check. This left us with 184 valid and complete responses, surpassing the minimum sample size.
6.1.3 Participant Demographics. Our survey encompassed a diverse set of 184 respondents, comprising males, females, non-binary individuals, and who preferred not to disclose their gender. The respondents were drawn from a broad geographic pool spanning 27 unique countries, with the most populous responses originating from the UK ( ), South Africa ( ), Poland ( ), Germany ( ), and the United States of America ( ).

In terms of work tenure, the median experience among participants was three years. The majority, 125 respondents, were relatively early in their careers, with 1 to 5 years of experience. Forty participants reported a more substantial work experience ranging between 6 to 15 years. An additional 14 participants had an extensive work experience of 16 to 30 years, and a handful of respondents, 5 in total, possessed more than 30 years of experience.

Our sample prominently featured individuals from the software development sector, making up of all respondents. Additionally, of respondents held data analysis, engineering, or science roles. A smaller segment, , held leadership roles such as Team Leads or CIOs. The remaining respondents included Tester / QA Engineers (6%), DevOps/Infrastructure Engineers (3%), Architects (2%), UX/UI Designers (2%), and other roles (2%).

In order to ensure the validity and reliability of our structural model, it is paramount to evaluate the reliability of the latent variables. Consequently, we analyze into the discriminant validity, internal consistency reliability, and convergent validity initially.
6.2.1 Discriminant Validity. In this context, discriminant validity refers to the distinctness or uniqueness of one latent variable compared to another. This serves as an essential parameter for determining whether two constructs are essentially the same and represent varying facets of knowledge. For its evaluation, we utilized the Heterotrait-Monotrait ratio of correlations (HTMT) which is recognized for its superior performance over other tests like the Fornell-Larcker criterion. The HTMT values should ideally be below 0.90 .

Table 10 reveals that all coefficients fall beneath the predefined threshold, which suggests that every construct in the model represents a distinct phenomenon.
6.2.2 Internal Consistency Reliability. This test seeks to confirm that the items are gauging the latent variables in a consistent and reliable manner. As such, we refer to the Cronbach’s Alpha, rho_a, and rho_c values showcased in Table 11, all of which should exceed 0.60 [70]. We can conclude that our tests meet the reliability criterea.

6.2.3 Convergent Validity. The final validity assessment examines the extent of correlations between various items and their corresponding construct. It is noteworthy that our latent variables are reflectively measured (Mode A) . As a result, these indicators should demonstrate a substantial variance proportion by converging on their latent variables. Two tests were employed to verify this assumption.

The first test involves the average variance extracted (AVE), which should register a value exceeding 0.5 [46]. The second test involves ensuring that the outer loadings of each measurement

model for the latent variable account for at least variance. This is tested by assessing the indicator’s reliability, which should exceed the square root of , i.e., 0.7 .

Table 12 encapsulates the results of the indicator’s reliability using cross-loadings. The items that did not contribute significantly to the variance and were subsequently excluded from our model during the analyis phase (a complete list of excluded items can be found in Table 20. Consequently, an improvement in the AVE was noted, thereby reinforcing the model’s robustness.

After ensuring the reliability of all our constructs through our Measurement Model assessment, we can now shift our focus towards evaluating the Structural Model, graphically represented in Figure 2. This evaluation is pivotal in discussing the predictive power of our model and validating our research hypotheses.
6.3.1 Collinearity Analysis. Initially, we analyze the correlation between the exogenous variable (Personal and environmental factors) and other endogenous variables. These should be independent to prevent any potential bias in the path estimations. The Variance Inflation Factor (VIF) test, which detects multicollinearity (i.e., an extreme degree of collinearity), should have a value under five [63]. Our VIF values are below this threshold, ranging from 4.710 (for the IU_3 item) to 2.034 (PEF_4). Consequently, we deduce that our model doesn’t suffer from multicollinearity issues.
6.3.2 Path Relations: Significance and Relevance. Path coefficients represent the hypothesized relationships between latent variables. They are standardized, meaning their values can range

from -1 to +1 . PLS-SEM does not require distributional assumptions, which means we can not use parametric tests to assess significance. As a workaround, we use a two-tailed bootstrapping method that incorporates 5,000 subsamples with replacement.

Details of the bootstrapping results are presented in Table 13, which includes the bootstrapping coefficients, mean, standard deviation, T statistics, and p -values corresponding to each of our seven hypotheses.

Our analysis reveals that a majority of our hypotheses are statistically significant. Specifically, four relationships have -values less than 0.05 , and their statistics surpass 1.96 , indicative of a significance level as noted by Hair et al.

6.3.3 Evaluation of Determination Coefficients. After affirmatively determining the significance of the majority of our hypotheses, we now proceed to the final phase of our study, which centers on the predictive power of the endogenous constructs. This is shown in Table 14. The predictive capacity is quantified through the variance explained ( ) by the endogenous constructs. signifies the ratio of the variance in the dependent variable that can be predicted from the independent variables. As increases with the number of predictors (more predictors equate to a higher ), it is prudent to consider the adjusted as well, which takes into account the quantity of predictors in the model. The values for these metrics lie between 0 and 1 . Determining a standard for can be challenging as its significance heavily relies on the topic at hand [46], but it is generally accepted that it should exceed 0.19 [17].

6.3.4 Evaluating Predictive Efficacy. Given that our study’s primary objective is to ascertain predictions rather than causality, we undertook a predictive results evaluation employing PLSpredict [95]. This approach tests if a model (developed using a training sample) can predict the outcomes from a test sample. Our sample was segmented into ten parts, and ten repetitions were utilized to derive the PLSpredict statistics. The results were interpreted based on the guidelines proposed by Shmueli et al. [96]. Table 15 portrays the latent variables’ predictive accuracy. Notably, all variables display a strongly positive predict indicating robust performance of the model.

6.3.5 Assessing Predictive Consistency. Our final examination focuses on the predictive consistency of our model, for which we scrutinize the effect sizes ( ) as illustrated in Table 16. This assessment involves understanding the impacts of various relationships within the model. The threshold values for effect sizes are set at , and 0.35 , corresponding to small, medium, and large effects, respectively [23]. Here, the relationship with the strongest effect are compatibility factors with intention to use LLMs .

This focused study specifically explores the elements influencing the adoption and intended use of Generative AI tools in the field of software engineering. Using the Importance-Performance Map Analysis (IPMA) methodology, we have combined the analysis of both the importance and performance dimensions derived from the PLS-SEM investigation [83]. This approach allows us to determine the extent to which various constructs contribute to the enhancement of the target construct – in this case, the Intention to Use (IU) and Adoption of Generative AI tools. It provides strategic insights by identifying which constructs are most significant and which ones demand improvements in performance.

Table 17 shows that all identified constructs, namely Compatibility Factors (CF), Personal and Environmental Factors (PEF), Perceptions about the Technology (PT), and Social Factors (SF), demonstrate robust performance, all exceeding , with PT and CF even surpassing the mark. This result is noteworthy, especially considering that established models such as the technology acceptance model typically show a constructs’ performance range between and [80].

The importance of individual constructs as shown in Table 18 is consistent with those of mature models, with values between 0.110 and 0.767 . In particular, PT and CF emerge as the most significant constructs influencing IU. This finding emphasizes the role of perceptions about the technology and compatibility factors in the intention to use and the eventual adoption of Generative AI tools in software engineering.

Figure 3 provides a visualization of the interplay between the importance and performance of these constructs. For instance, a unit increase in the performance of PT (from, say, 85.138 to 86.138) would improve the IU by the total effect of PT on IU, which is 0.540 . This suggests that if the goal is to increase IU and Adoption, emphasis should be placed on enhancing PT, given its high importance. Similarly, also CF play a crucial role to support AI adoption. On the other hand, constructs such as SF and PEF, despite their role, appear less critical to the intention to use and adoption of Generative AI tools.

In our investigation of Generative AI adoption in software engineering, we developed the Human-AI Collaboration and Adaptation Framework (HACAF) to dissect the interplay between perceptions about the technology, compatibility factors, social factors, and personal and environmental factors. We did not to restrict our study to a specific generative AI model, such as ChatGPT-4 or ChatGPT3.5. This decision was driven by our aim to capture a holistic understanding of the adoption dynamics, recognizing that the landscape of generative AI is rapidly evolving. Committing to a single model could have limited the generalizability and longevity of our findings. By adopting a broader approach, we hypothesize that our framework may offer valuable insights, potentially remaining relevant as new iterations and variations of generative AI models emerge in the field, though this supposition invites further empirical validation. The results revealed a complex landscape, with surprising deviations from traditional technology acceptance theories. Table 19 summarizes our key findings and implications.

Our qualitative study was foundational in the development of our framework, which stresses the impact of perceptions about the technology and compatibility factors in shaping the intention

to use LLMs. However, the subsequent quantitative study upended the expectation that these perceptions directly influenced intention to use, thus contradicting the traditional Technology Acceptance Model [29]. This suggests that, when adopting LLMs, the compatibility with existing work processes significantly impacts perceptions about the technology.

The central role of compatibility factors aligns with previous findings [65] and reaffirms the essential need for technological alignment with current practices. Our study revealed that software engineers are more inclined to adopt LLMs when the technology fits seamlessly into their existing workflows, a finding in line with prior research [32].

In contrast to expectations, the quantitative investigation indicated that social factors did not significantly contribute to the intention to use LLMs. This deviation from previous studies [111] underlines the nuanced influences of social aspects and self-efficacy on the adoption process.

Personal and environmental factors, while influential in shaping perceptions about the technology, didn’t directly impact the intention to use. This observation supports the assertion by [2] that personal innovativeness might mold perceptions about a technology but does not necessarily guarantee adoption.

The insights derived from our exploration of LLM adoption using the HACAF theory both diverge from and extend beyond established theoretical frameworks like TAM, DOI, and SCT, shedding light on the complex dynamics at play. These findings carry both academic and practical implications, underlining the necessity for holistic strategies that consider individual perceptions and compatibility factors for promoting LLM adoption.

Our research places a clear emphasis on Compatibility Factors as primary drivers in the adoption process of Generative AI technologies. Compatibility factors, in essence, measure how well a new technology fits into an individual or organization’s existing framework-both in terms of practical workflow and broader values. They are essential in determining the successful adoption of technologies, such as Generative AI. The importance of seamless integration within existing workflows is the core driver towards AI adoption. Workflows refer to the defined sequence of tasks that a software engineering team performs regularly, such as, coding, debugging, testing, and deployment. Notably, also hardware plays a crucial role in these processes [36]. If an LLM can integrate smoothly into these steps by e.g., automating certain coding tasks or improving debugging efficiency – it is seen as highly compatible. Conversely, if the integration of LLM disrupts these established procedures or necessitates significant changes to existing operations, it might be deemed less compatible, and its adoption may face resistance. This idea extends beyond workflows to include the broader technological environment. If the LLM requires different operating systems or specific hardware that is not in use, or if it relies on knowledge or skills that the team does not possess, it can make the tool less compatible. Therefore, the technology compatibility and the alignment with existing skills are vital considerations. In other words, even if a tool holds significant potential utility, if an individual or an organization fails to understand how it fits within their existing framework, i.e., workflow, technical environment, or value system – its adoption becomes less likely. This insight brings into focus the critical role of compatibility in designing and promoting new technology. For successful integration within the software engineering industry, Generative AI tools should be designed with a deep understanding of the existing systems, practices, and values in mind.

Another noteworthy aspect of our findings is the non-significant relationship between Social Factors and Intention to Use, despite the positive influence of perceptions about the technology on Social Factors. This unexpected finding could be contextualized by considering the nascent stage of the Generative AI transformation within the industry. Despite the recognition of the potential benefits and enhancements to self-efficacy offered by LLMs, this does not necessarily catalyze immediate widespread adoption, suggesting that mere perceptions about a technology’s potential advantages may not be sufficient to prompt its adoption.

Interestingly, we found that Personal and Environmental Factors did not directly lead to the Intention to Use, stressing the early stage of LLM adoption. In this initial phase, personal innovativeness and organizational support appear to exert limited influence on adoption, placing the emphasis squarely on Compatibility Factors. This suggests that as AI tools are more seamlessly integrated within existing workflows, their likelihood of adoption increases.

It is critical to acknowledge that we are currently in the nascent stages of the Generative AI transformation. As the utilization of these tools gains wider traction over time, we anticipate
that the relationships within HACAF will be further corroborated. The current non-validation of all relationships within our framework model does not detract from its utility but offers initial insights into the factors shaping the adoption of Generative AI tools at this stage.

While our study primarily focused on the adoption dynamics of Generative AI tools in software engineering, it is worth noting that a minority of our informants did touch upon the ethical implications and potential risks associated with their use. Despite the limited number of informants addressing these concerns, the issues they raised are significant. Large language models, while powerful, can produce harmful outputs or inadvertently perpetuate biases present in the data they were trained on. Such outputs can have unintended consequences, especially when integrated into software products that reach a wide audience. Recent research, including that by Tsamados et al. [106], has emphasized the security vulnerabilities inherent to artificial intelligence, especially with LLMs. Their findings suggest a need for a comprehensive understanding of these models’ capabilities and vulnerabilities to ensure a balanced cost-benefit analysis. In the context of our study, it is crucial to recognize that while the compatibility of AI tools within existing development workflows is a significant driver for adoption, this should not overshadow the potential risks. Model providers, in their journey to promote adoption, should be proactive in communicating potential vulnerabilities and offering guidance on best practices to mitigate risks. Given the rapid evolution of LLM technologies, periodic reviews and audits can ensure that models remain transparent and adhere to ethical standards. Platforms integrating LLMs should bolster their security measures, ensuring that they are equipped to handle the unique challenges posed by these models. Furthermore, when integrating or using LLMs, preference should be given to models from established and reputable sources to ensure reliability and security. Open discussions between stakeholders, including developers, users, and regulatory bodies, can foster a more responsible and ethical adoption of Generative AI tools in software engineering. By addressing these concerns, we can ensure a balanced and responsible approach to the integration of Generative AI tools, aligning with the insights and framework provided by our study.

This study’s significance lies not only in its immediate findings but also in establishing a foundation for understanding software developers’ perceptions of AI during this early phase. This insight is indispensable for guiding the design and implementation of these tools to align with user needs and expectations.

Lastly, while this study offers an important snapshot of the current state of Generative AI adoption in software development, a comprehensive assessment of the HACAF model necessitates long-term and longitudinal studies. Such investigations would facilitate a more profound understanding of the evolution and interplay of the factors affecting adoption as the technology matures and gains wider adoption. Longitudinal studies will provide nuanced insights into changing adoption patterns, further refining the HACAF model over time, and contributing to a more sophisticated understanding of technology adoption phenomena.

The findings of this study have far-reaching implications for practitioners and researchers in software engineering and artificial intelligence, offering new insights from the perspective of the Human-AI Collaboration and Adaptation Framework (HACAF). The integration of AI, specifically Generative AI tools like Large Language Models, into software development processes has shown promise, leading to potential advancements in various aspects of the field.

A key implication of our study is the need for organizations to consider investing in AIdriven tools that fit well within existing development workflows. To translate this into actionable steps, we recommend:

Importantly, the successful deployment of AI in software engineering relies heavily on aligning AI techniques with the unique needs and contexts of each organization. A careful assessment of requirements, resources, and constraints should precede the adoption of any AI-driven solution. To ensure that AI tools and techniques are not just adopted, but also effectively integrated, the following steps are crucial:

Our research, while primarily centered on the adoption dynamics of Generative AI tools in software engineering, did highlight the ethical implications and potential risks associated with their use. Large language models, despite their capabilities, can sometimes produce outputs that might be considered harmful or inadvertently mirror biases from their training data. Such unintended outputs can have profound implications, especially when integrated into software products for a vast audience.

Our threats to validity are deliberated in relation to the application of both qualitative and quantitative validity frameworks, as advised by earlier research [86, 87]. Consequently, we commence our discourse on the credibility, transferability, and confirmability for qualitative examination [45].

Credibility. The principal variables of our investigation were informed by the three core theoretical models that assess individual, technological, and social-level influences. These models are the Technology Acceptance Model, the Diffusion of Innovation Theory, and the Social Cognitive Theory. By integrating these thoroughly validated theories into our study, we could deeply understand the factors influencing language model adoption, and further probe how these variables are implemented within the software engineering domain. Moreover, to ensure the credibility of our data, informants underwent a rigorous multistage selection process, verifying their roles as software engineers actively working with Generative AI tools. This meticulous selection process fortified the integrity of our study and the resulting insights.

Transferability and Confirmability. Our qualitative data analysis was performed by a single researcher, applying the Gioia Methodology to the collected data. The utilization of a single researcher for data analysis could be perceived as a limitation due to potential biases and subjectivity. However, employing the Gioia Methodology significantly mitigates these biases, contributing to the trustworthiness of our findings. The Gioia methodology provides a structured approach that emphasizes transparency, iterative categorization, and systematic data processing, which lends itself to limiting subjective bias [38]. Moreover, our research merged qualitative data with a sample study to bolster the transferability of our findings. Transferability, as defined in qualitative research, refers to the extent to which the results can be applied in other contexts or with other respondents [26]. By incorporating a sample study, we provided a broader base from which parallels could be drawn, thereby enhancing the applicability of our research to varied contexts. Despite surveying a broad group of participants, limitations were present as we were unable to conduct follow-up inquiries. This may potentially affect the depth and comprehensiveness of our data. Yet, our utilization of the Gioia Methodology and the combination of qualitative and sample study data have fortified the structure and interpretative robustness of our data.

Furthermore, we disucss statistical conclusion, internal, construct, and external validity to assess the quantitative investigation [117].

Internal. Our research model was validated using a cluster-randomized probability sampling strategy [43]. Because of feasibility issues, we selected a cluster of the global population (i.e., the Prolific community) instead of the entire population. Although less accurate than random sampling, cluster sampling is more cost-efficient. In response to Baltes and Ralph’s call, which noted that less than of software engineering studies in top venues utilize probability sampling [8], we designed our study accordingly. Our data quality was boosted by a multi-stage process in which only 184 carefully selected professionals were chosen out of the 831 potential candidates identified (approximately of the initial candidates). Nevertheless, our sample is not representative of the software engineering population.

External. The generalization of our findings was a significant concern during the PLS-SEM analysis as sample studies are best suited for theory generalization [98]. We gathered 184 responses, an ample size considering the a priori power study we conducted prior to data collection.

Construct. Constructs were gauged via a single-informant approach, embodying a software engineer’s viewpoint. Additionally, we employed self-reported measures, asking participants to express their agreement level on literature-derived indicators. However, these questions might not have been accurately answered. To counteract these limitations, we introduced three random attention checks, which eleven candidates failed. Furthermore, we adjusted our measurement instrument based on pre-existing ones. Lastly, we randomized the questionnaire and tested it for clarity and consistency to manage potential accuracy biases.

Statistical conclusion. We processed the survey results using Partial Least Squares – Structural Equation Modelling with the renowned statistical software SmartPLS (4.0.9.5), which has been utilized in over 1,000 peer-reviewed articles [84]. All statistical methods and tests employed for the PLS-SEM analysis are in line with the most recent guidelines in our field [91].

This study presents a mixed-methods investigation about the adoption of Generative AI tools within the field of software engineering. By developing the Human-AI Collaboration and Adaptation Framework (HACAF), our research provides a nuanced understanding of the complexities involved in the adoption of such technologies, particularly during these nascent stages of the Generative AI transformation.

Our findings shed light on the pivotal role of Compatibility Factors, emphasizing the need for AI tools to fit within existing development workflows to enhance their adoption. This points towards the understanding that adoption is not driven solely by the perceived benefits of the technology, but by its seamless integration into the user’s pre-established work processes.

Beyond its theoretical contributions, this study has significant practical implications. It offers early insights into software developers’ perceptions of AI, providing valuable pointers for the design and refinement of user-focused AI tools. These insights can help foster a more widespread adoption of AI tools by addressing developer concerns and optimizing tool compatibility with existing workflows.

As we look forward, future research in the nascent field of AI and software engineering can build upon the foundation laid by this study. While this study delivers an important snapshot of the current state of Generative AI adoption in software development, it is crucial to recognize that a comprehensive assessment of the HACAF model necessitates long-term and longitudinal studies. Such investigations would permit a deeper understanding of the evolution and interplay of factors influencing adoption as the technology matures and gains broader acceptance. These longitudinal studies would offer nuanced insights into the changing adoption patterns, thus allowing the continuous refinement of the HACAF model and contributing to a more sophisticated understanding of technology adoption phenomena.

The PLS-SEM computational tables, raw data, the survey instruments, and the overfitting analysis are openly available under a CC BY 4.0 license on Zenodo, DOI: https://doi.org/10.5281/zenodo. 8124332.

This work was supported by the The Danish Industry Foundation with the Sb3D project – Security by Design in Digital Denmark.

ChatGPT-4 has been used to ensure linguistic accuracy and enhancing the readability of this article.

[1] Ritu Agarwal and Jayesh Prasad. 1998. A conceptual and operational definition of personal innovativeness in the domain of information technology. Information Systems Research 9, 2 (1998), 204-215.
[2] Ritu Agarwal and Jayesh Prasad. 1999. Are individual differences germane to the acceptance of new information technologies? Decision Sciences 30, 2 (1999), 361-391.
[3] AI, B. 2023. BLACKBOX AI – useblackbox.io. https://www.useblackbox.io/ Accessed: October 17, 2023.
[4] Icek Ajzen. 1991. The theory of planned behavior. Organizational Behavior and Human Decision Processes 50, 2 (1991), 179-211.
[5] Icek Ajzen. 2020. The theory of planned behavior: Frequently asked questions. Human Behavior and Emerging Technologies 2, 4 (2020), 314-324.
[6] Amazon Web Services. 2023. Code-Whisperer – Amazon Web Services. https://aws.amazon.com/es/codewhisperer/ Accessed: October 17, 2023.
[7] Alejandro Barredo Arrieta, Natalia Díaz-Rodríguez, Javier Del Ser, Adrien Bennetot, Siham Tabik, Alberto Barbado, Salvador Garcia, Sergio Gil-Lopez, Daniel Molina, Richard Benjamins, et al. 2020. Explainable Artificial Intelligence (XAI): Concepts, taxonomies, opportunities and challenges toward responsible AI. Information Fusion 58 (2020), 82-115.
[8] S. Baltes and P. Ralph. 2020. Sampling in Software Engineering Research: A Critical Review and Guidelines. arXiv:2002.07764 (2020).
[9] Albert Bandura. 2014. Social cognitive theory of moral thought and action. In Handbook of moral behavior and development. Psychology press, 69-128.
[10] Albert Bandura, W. H. Freeman, and Richard Lightsey. 1999. Self-Efficacy: The Exercise of Control. Fournal of Cognitive Psychotherapy 13, 2 (1999), 158-166.
[11] Shraddha Barke, Michael B James, and Nadia Polikarpova. 2023. Grounded copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages 7 (2023), 85-111.
[12] James Bessen. 2019. Automation and jobs: When technology boosts employment. Economic Policy 34, 100 (2019), 589-626.
[13] Christian Bird, Denae Ford, Thomas Zimmermann, Nicole Forsgren, Eirini Kalliamvakou, Travis Lowdermilk, and Idan Gazit. 2022. Taking Flight with Copilot: Early insights and opportunities of AI-powered pair-programming tools. Queue 20, 6 (2022), 35-57.
[14] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners. Advances in Neural Information Processing Systems 33 (2020), 1877-1901.
[15] Javier Cámara, Javier Troya, Lola Burgueño, and Antonio Vallecillo. 2023. On the assessment of generative AI in modeling tasks: an experience report with ChatGPT and UML. Software and Systems Modeling (2023), 1-13.
[16] Ruijia Cheng, Ruotong Wang, Thomas Zimmermann, and Denae Ford. 2022. “It would work for me too”: How Online Communities Shape Software Developers’ Trust in AI-Powered Code Generation Tools. arXiv preprint arXiv:2212.03491 (2022).
[17] W. W. Chin. 1998. The partial least squares approach to structural equation modeling. Modern Methods for Business Research 295, 2 (1998), 295-336.
[18] Clayton M. Christensen. 1997. The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press.
[19] Michael Chui et al. 2023. The economic potential of generative AI: The next productivity frontier. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier. [Accessed 03-Jul-2023].
[20] Victoria Clarke, Virginia Braun, and Nikki Hayfield. 2015. Thematic analysis. Qualitative psychology: A practical guide to research methods 3 (2015), 222-248.
[21] CodeComplete. 2023. CodeComplete: AI Coding Assistant for Enterprise. https://codecomplete.ai/ Accessed: October 17, 2023.
[22] Codeium. 2023. Codeium • Free AI Code Completion and Chat. https://codeium.com/ Accessed: October 17, 2023.
[23] J. Cohen. 1988. Statistical Power Analysis for the Behavioral Sciences. Routledge.
[24] Deborah R Compeau and Christopher A Higgins. 1995. Computer self-efficacy: Development of a measure and initial test. MIS Quarterly (1995), 189-211.
[25] J. Corbin and A. Strauss. 1990. Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative Sociology 13, 1 (1990), 3-21.
[26] J. Creswell. 2013. Research design: Qualitative, quantitative, and mixed methods approaches. Sage.
[27] Arghavan Moradi Dakhel, Vahid Majdinasab, Amin Nikanjam, Foutse Khomh, Michel C Desmarais, and Zhen Ming Jack Jiang. 2023. Github copilot ai pair programmer: Asset or liability? 7ournal of Systems and Software 203
(2023), 111734.
[28] Anastasia Danilova, Alena Naiakshina, Stefan Horstmann, and Matthew Smith. 2021. Do you really code? Designing and Evaluating Screening Questions for Online Surveys with Programmers. In International Conference on Software Engineering. IEEE, 537-548.
[29] F. Davis. 1989. Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly 13, 3 (1989), 319-340.
[30] Fred D Davis, Richard P Bagozzi, and Paul R Warshaw. 1989. User acceptance of computer technology: A comparison of two theoretical models. Management science 35, 8 (1989), 982-1003.
[31] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2019. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805 (2019).
[32] Paul Dourish. 2003. The appropriation of interactive technologies: Some lessons from placeless documents. Computer Supported Cooperative Work 12 (2003), 465-490.
[33] Christof Ebert and Panos Louridas. 2023. Generative AI for software practitioners. IEEE Software 40, 4 (2023), 30-38.
[34] Neil A Ernst and Gabriele Bavota. 2022. Ai-driven development is here: Should you worry? IEEE Software 39, 2 (2022), 106-110.
[35] Carl Benedikt Frey and Michael A Osborne. 2017. The future of employment: How susceptible are jobs to computerisation? Technological Forecasting and Social Change 114 (2017), 254-280.
[36] Yanjie Gao, Xiaoxiang Shi, Haoxiang Lin, Hongyu Zhang, Hao Wu, Rui Li, and Mao Yang. 2023. An Empirical Study on Quality Issues of Deep Learning Platform. In International Conference on Software Engineering: Software Engineering in Practice. IEEE, 455-466.
[37] D. Gefen, D. Straub, and M.-C. Boudreau. 2000. Structural equation modeling and regression: Guidelines for research practice. Communications of the Association for Information Systems 4, 1 (2000), 7.
[38] D. Gioia, K. Corley, and A. Hamilton. 2013. Seeking qualitative rigor in inductive research: Notes on the Gioia methodology. Organizational Research Methods 16, 1 (2013), 15-31.
[39] D. Gioia, J. Thomas, S. Clark, and K. Chittipeddi. 1994. Symbolism and strategic change in academia: The dynamics of sensemaking and influence. Organization Science 5, 3 (1994), 363-383.
[40] B. Glaser and A. Strauss. 2017. Discovery of grounded theory: Strategies for qualitative research. Routledge.
[41] Dale L Goodhue and Ronald L Thompson. 1995. Task-technology fit and individual performance. MIS quarterly (1995), 213-236.
[42] Roberto Gozalo-Brizuela and Eduardo C Garrido-Merchán. 2023. A survey of Generative AI Applications. arXiv preprint arXiv:2306.02781 (2023).
[43] F. J. Gravetter and L.-A. B. Forzano. 2018. Research methods for the behavioral sciences. Cengage Learning.
[44] Stine Grodal, Michel Anteby, and Audrey L Holm. 2021. Achieving rigor in qualitative analysis: The role of active categorization in theory building. Academy of Management Review 46, 3 (2021), 591-612.
[45] E. Guba. 1981. Criteria for assessing the trustworthiness of naturalistic inquiries. Educational Communication and Technology fournal 29, 2 (1981), 75-91.
[46] J. F. Hair Jr, G T. M Hult, C. Ringle, and M. Sarstedt. 2016. A primer on partial least squares structural equation modeling (PLS-SEM). Sage.
[47] Douglas M Hawkins. 2004. The problem of overfitting. Journal of chemical information and computer sciences 44, 1 (2004), 1-12.
[48] Ari Holtzman, Jan Buys, Li Du, Maxwell Forbes, and Yejin Choi. 2019. The curious case of neural text degeneration. arXiv preprint arXiv:1904.09751 (2019).
[49] Saki Imai. 2022. Is github copilot a substitute for human pair-programming? an empirical study. In Proceedings of the ACM/IEEE International Conference on Software Engineering: Companion Proceedings. 319-321.
[50] L. Isabella. 1990. Evolving interpretations as a change unfolds: How managers construe key organizational events. Academy of Management Journal 33, 1 (1990), 7-41.
[51] Mateusz Jaworski and Dariusz Piotrkowski. 2023. Study of software developers’ experience using the Github Copilot Tool in the software development process.
[52] Jared Kaplan, Sam McCandlish, Tom Henighan, Tom B Brown, Benjamin Chess, Rewon Child, Scott Gray, Alec Radford, Jeffrey Wu, and Dario Amodei. 2020. Scaling laws for neural language models. arXiv preprint arXiv:2001.08361 (2020).
[53] Ron Kohavi. 1995. A study of cross-validation and bootstrap for accuracy estimation and model selection. In Ijcai, Vol. 14. 1137-1145.
[54] Rajiv Kohli and Nigel P Melville. 2019. Digital innovation: A review and synthesis. Information Systems 7ournal 29, 1 (2019), 200-223.
[55] U. Kulkarni, S. Ravindran, and R. Freeze. 2006. A knowledge management success model: Theoretical development and empirical validation. Journal of Management Information Systems 23, 3 (2006), 309-347.
[56] W. Lewis, R. Agarwal, and V. Sambamurthy. 2003. Sources of influence on beliefs about information technology use: An empirical study of knowledge workers. MIS Quarterly (2003), 657-678.
[57] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. D. Lago, T. Hubert, P. Choy, C. de Masson d’Autume, I. Babuschkin, X. Chen, P.-S. Huang, J. Welbl, S. Gowal, A. Cherepanov, J. Molloy, D. J. Mankowitz, E. S. Robson, P. Kohli, N. de Freitas, K. Kavukcuoglu, and O. Vinyals. 2023. AlphaCode alphacode.deepmind.com. https://alphacode.deepmind.com/ Accessed: October 17, 2023.
[58] Jenny T Liang, Chenyang Yang, and Brad A Myers. 2023. Understanding the Usability of AI Programming Assistants. arXiv preprint arXiv:2303.17125 (2023).
[59] Y. Lincoln and E. Guba. 1985. Naturalistic inquiry. Sage.
[60] Mai Skjott Linneberg and Steffen Korsgaard. 2019. Coding qualitative data: A synthesis guiding the novice. Qualitative Research fournal 19, 3 (2019), 259-270.
[61] K. Locke. 1996. Rewriting the discovery of grounded theory after 25 years? Journal of Management Inquiry 5, 3 (1996), 239-245.
[62] Antonio Mastropaolo, Luca Pascarella, Emanuela Guglielmi, Matteo Ciniselli, Simone Scalabrino, Rocco Oliveto, and Gabriele Bavota. 2023. On the robustness of code generation techniques: An empirical study on github copilot. arXiv preprint arXiv:2302.00438 (2023).
[63] J. Miles. 2014. Tolerance and Variance Inflation Factor. American Cancer Society.
[64] Brent Daniel Mittelstadt, Patrick Allo, Mariarosaria Taddeo, Sandra Wachter, and Luciano Floridi. 2016. The ethics of algorithms: Mapping the debate. Big Data & Society 3, 2 (2016).
[65] Geoffrey A Moore and Regis McKenna. 1999. Crossing the chasm. (1999).
[66] Hussein Mozannar, Gagan Bansal, Adam Fourney, and Eric Horvitz. 2022. Reading between the lines: Modeling user behavior and costs in AI-assisted programming. arXiv preprint arXiv:2210.14306 (2022).
[67] mutable.ai. 2023. AI Accelerated Software Development. – mutable.ai. https://mutable.ai/ Accessed: October 17, 2023.
[68] Nhan Nguyen and Sarah Nadi. 2022. An empirical evaluation of GitHub copilot’s code suggestions. In Proceedings of the International Conference on Mining Software Repositories. 1-5.
[69] Oded Nov and Chen Ye. 2008. Users’ personality and perceived ease of use of digital libraries: The case for resistance to change. Journal of the American Society for Information Science and Technology 59, 5 (2008), 845-851.
[70] J. Nunnally. 1978. Psychometric methods. McGraw-Hill.
[71] General Assembly of the World Medical Association et al. 2014. World Medical Association Declaration of Helsinki: ethical principles for medical research involving human subjects. The 7ournal of the American College of Dentists 81, 3 (2014), 14.
[72] OpenAI. 2023. GPT-4 Technical Report. arXiv:2303.08774 [cs.CL]
[73] Ipek Ozkaya. 2023. The next frontier in software development: AI-augmented software development processes. IEEE Software 40, 4 (2023), 4-9.
[74] Stefan Palan and Christian Schitter. 2018. Prolific.ac–A subject pool for online experiments. Journal of Behavioral and Experimental Finance 17 (2018), 22-27.
[75] Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of ai on developer productivity: Evidence from github copilot. arXiv preprint arXiv:2302.06590 (2023).
[76] Anthony Peruma, Steven Simmons, Eman Abdullah AlOmar, Christian D Newman, Mohamed Wiem Mkaouer, and Ali Ouni. 2022. How do i refactor this? An empirical study on refactoring trends and topics in Stack Overflow. Empirical Software Engineering 27, 1 (2022), 11.
[77] James Prather, Brent N Reeves, Paul Denny, Brett A Becker, Juho Leinonen, Andrew Luxton-Reilly, Garrett Powell, James Finnie-Ansley, and Eddie Antonio Santos. 2023. ” It’s Weird That it Knows What I Want”: Usability and Interactions with Copilot for Novice Programmers. arXiv preprint arXiv:2304.02491 (2023).
[78] Alec Radford, Karthik Narasimhan, Tim Salimans, and Ilya Sutskever. 2019. Language models are unsupervised multitask learners. OpenAI blog 1, 8 (2019), 9.
[79] Paul Ralph et al. 2020. Empirical standards for software engineering research. arXiv preprint arXiv:2010.03525 (2020).
[80] M. Ramkumar, T. Schoenherr, S. Wagner, and M. Jenamani. 2019. Q-TAM: A quality technology acceptance model for predicting organizational buyers’ continuance intentions for e-procurement services. International fournal of Production Economics 216 (2019), 333-348.
[81] Baishakhi Ray, Daryl Posnett, Vladimir Filkov, and Premkumar Devanbu. 2014. A large scale study of programming languages and code quality in github. In International Symposium on Foundations of Software Engineering. ACM, 155-165.
[82] replit. 2023. Ghostwriter – Code faster with AI – replit.com. https://replit.com/site/ghostwriter Accessed: October 17, 2023.
[83] C. M. Ringle and M. Sarstedt. 2016. Gain more insight from your PLS-SEM results: The importance-performance map analysis. Industrial Management & Data Systems 116, 9 (2016), 1865-1886.
[84] C. M. Ringle, S. Wende, and J.-M. Becker. 2015. SmartPLS 3.
[85] Everett M. Rogers. 2010. Diffusion of Innovations. Simon and Schuster.
[86] Daniel Russo. 2021. The agile success model: a mixed-methods study of a large-scale agile transformation. ACM Transactions on Software Engineering and Methodology 30, 4 (2021), 1-46.
[87] D. Russo, P. Ciancarini, T. Falasconi, and M. Tomasi. 2018. A Meta Model for Information Systems Quality: a Mixed-Study of the Financial Sector. ACM Transactions on Management Information Systems 9, 3 (2018).
[88] Daniel Russo, Paul H P Hanel, Seraphina Altnickel, and Niels van Berkel. 2021. The daily life of software engineers during the covid-19 pandemic. In International Conference on Software Engineering. IEEE, 364-373.
[89] Daniel Russo, Paul H P Hanel, Seraphina Altnickel, and Niels van Berkel. 2021. Predictors of Well-being and Productivity among Software Professionals during the COVID-19 Pandemic-A Longitudinal Study. Empirical Software Engineering 26, 62 (2021), 1-64. https://doi.org/10.1007/s10664-021-09945-9
[90] Daniel Russo and Klaas-Jan Stol. 2020. Gender Differences in Personality Traits of Software Engineers. IEEE Transactions on Software Engineering 48, 3 (2020), 16.
[91] Daniel Russo and Klaas-Jan Stol. 2021. PLS-SEM for software engineering research: An introduction and survey. Comput. Surveys 54, 4 (2021), 1-38.
[92] Mahadev Satyanarayanan. 2001. Pervasive computing: Vision and challenges. IEEE Personal Communications 8, 4 (2001), 10-17.
[93] Albrecht Schmidt. 2023. Speeding Up the Engineering of Interactive Systems with Generative AI. In ACM SIGCHI Symposium on Engineering Interactive Computing Systems. 7-8.
[94] AH Segars and V Grover. 1993. Re-examining perceived ease of use and usefulness: A confirmatory factor analysis. MIS Quarterly 17, 4 (1993), 517-525.
[95] Galit Shmueli, Soumya Ray, Juan Manuel Velasquez Estrada, and Suneel Babu Chatla. 2016. The elephant in the room: Predictive performance of PLS models. Journal of Business Research 69, 10 (2016), 4552-4564.
[96] G. Shmueli, M. Sarstedt, J. F. Hair, J Cheah, H. Ting, S. Vaithilingam, and C. M. Ringle. 2019. Predictive model assessment in PLS-SEM: guidelines for using PLSpredict. European fournal of Marketing 53, 11 (2019).
[97] Dominik Sobania, Martin Briesch, and Franz Rothlauf. 2022. Choose your programming copilot: A comparison of the program synthesis performance of github copilot and genetic programming. In Proceedings of the Genetic and Evolutionary Computation Conference. 1019-1027.
[98] Klaas-Jan Stol and Brian Fitzgerald. 2018. The ABC of software engineering research. ACM Transactions on Software Engineering and Methodology 27, 3 (2018), 11.
[99] A. Strauss and J. Corbin. 1990. Basics of qualitative research: Grounded theory procedures and techniques. Sage.
[100] Tabnine. 2023. AI Assistant for software developers – Tabnine. https://www.tabnine.com/ Accessed: October 17, 2023.
[101] Emmanuel Tenakwah. 2021. What do employees want?: Halting record-setting turnovers globally. Strategic HR Review 20, 6 (2021), 206-210.
[102] Ronald L Thompson, Christopher A Higgins, and Jane M Howell. 1991. Personal Computing: Toward a Conceptual Model of Utilization. MIS Quarterly 15, 1 (1991), 125-143.
[103] Haoye Tian, Weiqi Lu, Tsz On Li, Xunzhu Tang, Shing-Chi Cheung, Jacques Klein, and Tegawendé F Bissyandé. 2023. Is ChatGPT the Ultimate Programming Assistant-How far is it? arXiv preprint arXiv:2304.11938 (2023).
[104] Gholamreza Torkzadeh, Jerry Cha-Jan Chang, and Didem Demirhan. 2006. A contingency model of computer and Internet self-efficacy. Information & Management 43, 4 (2006), 541-550.
[105] Louis G. Tornatzky and Katherine J. Klein. 1982. Innovation characteristics and innovation adoption-implementation: A meta-analysis of findings. IEEE Transactions on Engineering Management 29, 1 (1982), 28-45.
[106] Andreas Tsamados, Luciano Floridi, and Mariarosaria Taddeo. 2023. The Cybersecurity Crisis of Artificial Intelligence: Unrestrained Adoption and Natural Language-Based Attacks. Available at SSRN 4578165 (2023).
[107] Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman. 2022. Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models. In International Conference on Human Factors in Computing Systems. 1-7.
[108] J. Van Maanen. 1979. The fact of fiction in organizational ethnography. Administrative Science Quarterly 24, 4 (1979), 539-550.
[109] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. Advances in Neural Information Processing Systems 30 (2017).
[110] Viswanath Venkatesh and Fred D Davis. 2000. A theoretical extension of the technology acceptance model: four longitudinal field studies. Management science 46, 2 (2000), 186-204.
[111] Viswanath Venkatesh, Michael G Morris, Gordon B Davis, and Fred D Davis. 2003. User acceptance of information technology: toward a unified view. MIS quarterly (2003), 425-478.
[112] Viswanath Venkatesh, James YL Thong, and Xin Xu. 2016. Unified theory of acceptance and use of technology: A synthesis and the road ahead. Journal of the Association for Information Systems 17, 5 (2016), 328-376.
[113] Vv.AA. 2023. The widespread adoption of AI by companies will take a while. https://www.economist.com/leaders/ 2023/06/29/the-widespread-adoption-of-ai-by-companies-will-take-a-while
[114] Ruotong Wang, Ruijia Cheng, Denae Ford, and Thomas Zimmermann. 2023. Investigating and Designing for Trust in AI-powered Code Generation Tools. arXiv preprint arXiv:2305.11248 (2023).
[115] Bolin Wei, Ge Li, Xin Xia, Zhiyi Fu, and Zhi Jin. 2019. Code generation as a dual task of code summarization. In International Conference on Neural Information Processing Systems. 6563-6573.
[116] Michel Wermelinger. 2023. Using GitHub Copilot to solve simple programming problems. In Proceedings of the ACM Technical Symposium on Computer Science Education. 172-178.
[117] C. Wohlin, P. Runeson, M. Höst, M. Ohlsson, B. Regnell, and A. Wesslén. 2012. Experimentation in Software Engineering. Springer Science & Business Media.
[118] Burak Yetistiren, Isik Ozsoy, and Eray Tuzun. 2022. Assessing the quality of GitHub copilot’s code generation. In Proceedings of the International Conference on Predictive Models and Data Analytics in Software Engineering. 62-71.
[119] Beiqi Zhang, Peng Liang, Xiyu (Thomas) Zhou, Aakash Ahmad, and Muhammad Waseem. 2023. Practices and Challenges of Using GitHub Copilot: An Empirical Study. arXiv preprint arXiv:2303.08733 (2023).
[120] Daniel Zhang, Saurabh Mishra, Erik Brynjolfsson, John Etchemendy, Deep Ganguli, Barbara Grosz, Terah Lyons, James Manyika, Juan Carlos Niebles, Michael Sellitto, et al. 2021. The AI index 2021 annual report. arXiv preprint arXiv:2103.06312 (2021).
[121] Q. Zheng, X. Xia, X. Zou, Y. Dong, S. Wang, Y. Xue, Z. Wang, L. Shen, A. Wang, Y. Li, T. Su, Z. Yang, and J. Tang. 2023. GitHub – THUDM/CodeGeeX: CodeGeeX: An Open Multilingual Code Generation Model. https: //github.com/THUDM/CodeGeeX Accessed: October 17, 2023.

The notably high effect size observed between ‘Perception about the Technology’ and ‘Compatibility Factors’ might raise concerns of potential overfitting, a scenario where the model inadvertently learns noise in the training data, thereby compromising its ability to accurately predict unseen data [47]. Given the potential implications of overfitting on the reliability of our model, it is crucial to thoroughly investigate this issue. The details of this analysis, along with the associated code and data, can be found in the online supplementary materials hosted on Zenodo .

First, we analyzed the residuals of our model, which can provide insights into the appropriateness of the model fit. The residuals represent the difference between the observed and predicted values for the dependent variable. In a well-specified model, we would expect the residuals to be randomly scattered around zero, with no apparent pattern. This would suggest that the model’s errors are random, and that the model is correctly specified.

We plotted the residuals against the predicted values for the ‘Intention to Use’ construct and found that they were indeed mostly randomly scattered, suggesting that our model’s errors are random. Figure 4 shows this residuals plot.

However, to evaluate the risk of overfitting more thoroughly, we employed two key methodologies: a train-test split and cross-validation [53]. In the train-test split, we partitioned our data into a training set ( of the data) and a testing set ( of the data). Our model was trained on the training data and then evaluated on the unseen testing data.

The model’s performance was assessed using the mean squared error (MSE), a metric that calculates the average squared difference between the observed and predicted values. A lower MSE indicates a better fit to the data. The MSE for the test set was approximately 0.523 .

To further examine overfitting, we implemented k -fold cross-validation with k set to 5 , a common choice for this parameter [53]. In this approach, the data was divided into 5 subsets, and the model

was trained and tested 5 times, each time on a different subset of the data. The performance of the model was again assessed using the MSE. The mean MSE from the cross-validation was approximately 0.676 , reasonably close to the test MSE, suggesting that our model is not overfitting the data.

In conclusion, both the train-test split and cross-validation results suggest that our model is generalizing effectively to unseen data and is not overfitting.