GitHub Copilot: آیا این برنامه نویس هوش مصنوعی واقعاً می تواند بهره وری توسعه دهندگان را بهبود بخشد؟


GitHub مطالعه‌ای منتشر کرده است که نشان می‌دهد ابزار تکمیل کد Copilot اخیراً منتشر شده واقعاً با بهبود بهره‌وری توسعه‌دهندگان مرتبط است.

GitHub Copilot، یک سرویس برنامه‌نویسی جفت هوش مصنوعی، یک ماه پیش با هزینه 10 دلار برای هر کاربر در ماه یا 100 دلار برای هر کاربر در سال در دسترس قرار گرفت.

این یک افزونه برای ویرایشگر کد ویژوال استودیو مایکروسافت است که به توسعه دهندگان کدهایی را پیشنهاد می کند که بتوانند آن را بپذیرند، رد یا ویرایش کنند. پیشنهادات کد توسط مدل هوش مصنوعی زبان طبیعی بر اساس Codex OpenAI که خود نسخه‌ای از GPT-3 است، تولید می‌شود و بر روی میلیاردها خط کد منبع در دسترس عموم، از جمله کد منتشر شده در GitHub، آموزش داده شده است.

Copilot بحث‌هایی را برانگیخته است زیرا همه توسعه‌دهندگان از استفاده از کدشان برای آموزش آن راضی نیستند. اما اکنون GitHub اکنون دارد مطالعه ای را منتشر کرد که با هدف آزمایش نظریه خود مبنی بر اینکه Copilot منجر به نرخ بهره وری بالاتر در میان توسعه دهندگان می شود.

محققان آن 2631 پاسخ نظرسنجی از توسعه دهندگان را با استفاده از Copilot تجزیه و تحلیل کردند و پاسخ های آنها را با اندازه گیری های جمع آوری شده از IDE (محیط توسعه یکپارچه) مطابقت دادند. بخشی از چالش یافتن بهترین روش برای اندازه گیری تأثیر Copilot بر بهره وری توسعه دهندگان بود.

نویسندگان توضیح می‌دهند: «ما دریافتیم که میزان پذیرش پیشنهادات نشان‌داده‌شده، پیش‌بینی‌کننده بهتری برای بهره‌وری درک‌شده نسبت به معیارهای جایگزین است».

به عبارت دیگر، GitHub در تلاش است تعریف کند که چگونه خدماتش باید در هنگام ارزیابی تأثیر آن بر بهره‌وری توسعه‌دهندگان اندازه‌گیری شود.

روش اندازه‌گیری بهره‌وری GitHub با دیگر غیر GitHub متفاوت است مطالعه منتشر شده در آوریل در مورد تأثیر Copilot بر بهره وری توسعه دهندگان که زمان اتمام کارهای تکراری را اندازه گیری می کند. نویسندگان آن به این نتیجه رسیدند که Copilot لزوماً زمان تکمیل کار یا میزان موفقیت را بهبود نمی بخشد، با این حال بیشتر 24 شرکت کننده آن ترجیح می دهند از Copilot استفاده کنند زیرا اغلب نقطه شروع مفیدی را ارائه می دهد و تلاش برای جستجوی آنلاین را کاهش می دهد.

یکی از نویسندگان مطالعه GitHub، آلبرت زیگلر، این سرویس را با “یک برنامه نویس جفت با یک ماشین حساب متصل” مقایسه می کند، که واقعاً در موارد بیهوده خوب است و در عین حال به اندازه کافی قابل اعتماد است که همه براکت ها را به ترتیب درست ببندد. او این ایده را به چالش می‌کشد که توسعه‌دهندگان می‌خواهند با کاهش جستجوهای آنلاین برای تکه‌های کد برای استفاده مجدد، بهره‌وری را افزایش دهند.

“اما کلمه “بهره وری” در توسعه شامل طیف گسترده ای از معانی عملی ممکن است. آیا توسعه دهندگان به طور ایده آل می خواهند ضربه های صفحه کلید را ذخیره کنند یا از جستجو در Google و StackOverflow اجتناب کنند؟” زیگلر در یک پست وبلاگی می پرسد. “آیا GitHub Copilot باید با ارائه راه‌حل‌های بسیار دقیق در مورد کارهای مکانیکی و ماشین‌حساب‌مانند، به آنها کمک کند تا در جریان باقی بمانند؟ یا باید الهام بخش آنها با خرده‌های گمانه‌زنی باشد که ممکن است به رفع انسداد آنها در هنگام گیر کردن کمک کند؟

سه سوال کلیدی که مطالعه GitHub از توسعه دهندگان پرسیده است شامل:

  1. آیا مردم احساس می‌کنند که GitHub Copilot آنها را بهره‌ورتر می‌کند؟
  2. آیا این احساس در هر اندازه گیری استفاده عینی منعکس می شود؟
  3. کدام اندازه‌گیری استفاده به بهترین شکل این احساس را منعکس می‌کند؟

زیگلر خاطرنشان می کند که یافته های این مطالعه نشان می دهد که Copilot “با بهره وری توسعه دهندگان بهبود یافته ارتباط دارد”. با تقسیم تعداد پیشنهادهای پذیرفته شده بر تعداد پیشنهادات نشان داده شده، قوی ترین ارتباط را به دست آورد.

او خاطرنشان می کند: «این میزان پذیرش نشان می دهد که چه تعداد از کدهای پیشنهادی GitHub Copilot تولید می کند که به اندازه کافی امیدوارکننده برای پذیرش هستند.

همچنین، توسعه‌دهندگانی که بیشترین بهره‌وری را با Copilot گزارش می‌کنند، بیشترین تعداد پیشنهاد کد نشان داده شده را نیز می‌پذیرند.

این مطالعه سطوح مختلف پذیرش برای زبان های مختلف را نشان داد.

نویسندگان GitHub خاطرنشان می کنند: “ما می دانیم که تفاوت های قابل توجهی برای نحوه عملکرد GitHub Copilot برای زبان های برنامه نویسی مختلف وجود دارد.” رایج‌ترین زبان‌ها در میان پایگاه کاربران ما عبارتند از TypeScript (24.7٪ از تمام تکمیل‌های نشان داده شده در بازه زمانی مشاهده شده، 21.9٪ برای کاربران در نظرسنجی)، جاوا اسکریپت (21.3٪، 24.2٪) و Python (14.1٪، 14.5٪) نویسندگان در گزارش خاطرنشان می‌کنند که دو مورد آخر از نرخ پذیرش بالاتری برخوردار هستند، که احتمالاً به قدرت نسبی ابزار عصبی در مقابل ابزار قیاسی برای زبان‌های بدون تایپ اشاره دارد. .

نویسندگان GitHub همچنین خاطرنشان می کنند که اقدامات آن برای تداوم – یا تعداد پیشنهاداتی که در طول زمان حفظ شد – با بهره وری گزارش شده همسو نبود.

ما به طور مشترک با کارهای قبلی، اندازه‌گیری‌هایی را درباره پذیرش تکمیل‌ها جمع‌آوری کردیم، اما معیارهای پایداری را نیز توسعه دادیم. این مبتنی بر این ایده بود که برای تکمیل‌های طولانی‌تر، یک توسعه‌دهنده ممکن است پس از پذیرش یک تکمیل، مانند حذف یا تصحیح، اقدامات بیشتری انجام دهد. یک اشتباه

ما متعجب شدیم که متوجه شدیم نرخ پذیرش (تعداد پذیرش عادی شده با تعداد تکمیل‌های نشان‌داده شده) نسبت به معیارهای تداوم ما با بهره‌وری گزارش‌شده همبستگی بهتری دارد.

با این حال، آنها استدلال می کنند که عدم ارتباط با ماندگاری منطقی است زیرا ارزش Copilot در تعداد خطوط کدی که به درستی خودکار می کند نیست، بلکه در دادن الگوی به کاربران برای تغییر دادن است.

اما در گذشته، این منطقی است. کدنویسی تایپ نیست، و ارزش مرکزی GitHub Copilot در این نیست که کاربر بیشترین تعداد ممکن خطوط کد را وارد کند. در عوض، کمک به کاربر برای رسیدن به بهترین پیشرفت در جهت اهدافش نهفته است.”

پیشنهادی که به‌عنوان یک الگوی مفید برای سرهم‌کردن عمل می‌کند، ممکن است به خوبی یا بهتر از یک خط کد کاملاً صحیح (اما واضح) باشد که کاربر را تنها با چند ضربه کلید ذخیره می‌کند. این نشان می‌دهد که تمرکز محدود بر صحت پیشنهادها می‌تواند تمام داستان را برای این نوع ابزارها بیان نکنید.”


منبع: https://www.zdnet.com/article/github-copilot-can-the-ai-programmer-really-improve-developer-productivity/#ftag=RSSbaffb68