یادداشت ویراستار: جنیفر ریگینز این پست را از طرف DX ایجاد کرده است.
به عنوان یک شرکت توسعه نرمافزار متخصص در راهکارهای کارگزاری، Devexperts باید سرعت نوآوری را با احتیاط مورد نیاز یک صنعت بسیار قانونمند متعادل کند.
این شامل بررسی داغترین موضوعات، مانند ابزارهای هوش مصنوعی مولد (GenAI) است. در طول دو سال گذشته، Devexperts در حال ارزیابی ابزارهای هوش مصنوعی برای افزایش بهرهوری توسعهدهندگان، به ویژه تولیدکنندگان کد، بوده است. از آنجا که مهندس هستند، این تیم آزمایشهای بسیار قابل اندازهگیری را با روش علمی اجرا میکند.
ابتدا، آنها GitHub Copilot را با ترکیبی از نتایج عالی و گیجکننده آزمایش کردند. و سپس فرضیهسازی کردند و آزمایش کردند که آیا ویرایشگر کد هوش مصنوعی Cursor عملکرد بهتری خواهد داشت یا خیر.
اکنون آنها به توسعهدهندگان خود حق انتخاب دستیارهای کدنویسی هوش مصنوعی مولد را میدهند. Devexperts در اینجا معیارهای توسعهدهندهای که اساس آزمایشهای GenAI آن بودند را به اشتراک میگذارد، بنابراین شما میتوانید هوش مصنوعی مولد را با تیم خود آزمایش کنید.
آیا میتوانید مانند توسعهدهندگان GitHub عمل کنید؟
در سپتامبر ۲۰۲۲، GitHub مقالهای منتشر کرد که بیان میکرد مهندسان آن با استفاده از Copilot شاهد افزایش ۵۵ درصدی در تکمیل وظایف بودند. این امر Devexperts را بر آن داشت تا Copilot را آزمایش کند تا ببیند آیا توسعهدهندگانش میتوانند به نتایج مشابهی دست یابند یا خیر.
Devexperts با یک آزمایش زنده از ۱ اوت تا ۱ نوامبر ۲۰۲۴، با مشارکت پنج مهندس نرمافزار آغاز کرد. سپس یک تجزیه و تحلیل گذشتهنگر با ۵۰ شرکتکننده دیگر انجام دادند. نتایج برای هر دو با افزایش ۵۵ درصدی Github برای معیارهای زمان، همسانسازی شد ((100%/55%)-1)*100% ˜ 120% به عنوان افزایش توان عملیاتی مورد انتظار.
به طور کلی، این شرکت میخواست سه روند را مشاهده کند:
- مهندسان به طور محسوسی سرعت کدنویسی خود را افزایش میدهند.
- مهندسان به طور محسوسی تعداد وظایف تکمیلشده را افزایش میدهند.
- مهندسان با همان کیفیت کار میکنند.
تیم Devexperts همچنین آزمایشهای کافی از سایر سازمانها خوانده بود تا انتظار داشته باشد که خطر واقعی افزایش قابل توجه اندازه راهحل و تقاضا برای بازنگری وجود دارد، بنابراین میخواست مراقب این موضوع نیز باشد.
هم آزمایش و هم تجزیه و تحلیل پس از وقوع به دنبال اندازهگیری جنبههایی از تجربه توسعهدهنده با معیارهای زیر بود:
- زمان چرخه فردی - زمان از زمانی که اولین commit نوشته میشود تا زمانی که درخواست pull (PR) ادغام میشود.
- زمان باز شدن - زمان بین اولین commit در یک درخواست pull و زمانی که PR باز میشود.
- زمان ادغام - مدت زمان بین زمانی که یک درخواست pull باز میشود و زمانی که ادغام میشود.
- چرخههای بحث - تعداد دفعاتی که یک مکالمه در یک درخواست pull بین افراد رفت و برگشت میکند.
- اندازه درخواست pull - تعداد خطوط کدی که اضافه، تغییر یا حذف شدهاند.
- توان عملیاتی PR - تعداد درخواستهای pull که در یک دوره زمانی در codebase اصلی ادغام میشوند.
- نرخ نوآوری - درصد تغییرات کد که نوشتن کد کاملاً جدید هستند.
- نرخ نگهداری - درصد تغییراتی که کد بهروزرسانی میکنند که بیش از سه هفته قدمت دارد.
- بازنگری - درصد تغییرات کد که در سه هفته گذشته بهروزرسانی شدهاند.
Devexperts با آستانه GitHub خود دریافت که تنها سه مورد از نه مورد از انتظارات آنها - بهبود ۵۵ درصدی - با پایلوت پنج مهندسی آنها برآورده شده است. این شرکت شاهد کاهش ۶۹ درصدی در چرخههای بحث و افزایش ۱۷۶ درصدی در توان عملیاتی PR بود و از این انتظارات فراتر رفت.
تغییرات مثبت دیگری نیز وجود داشت، از جمله کاهش در زمان چرخه و زمان ادغام، اما نه با همان نرخ بهبود که مهندسان GitHub تجربه کردند.
همچنین ۱۴ درصد کاهش در نرخ نوآوری وجود داشت. این بدان معناست که در طول آزمایش سه ماهه، توسعهدهندگان زمان کمتری را صرف حل مشکلات منحصر به فرد میکردند.
آخرین معیار، بازنگری، یک ملاحظه مهم با هوش مصنوعی مولد است، زیرا ۶۷٪ از توسعهدهندگان متوجه میشوند که زمان بیشتری را صرف رفع اشکال کد تولید شده توسط هوش مصنوعی میکنند. Devexperts افزایش ۲۰۰ درصدی در بازنگری و افزایش ۳۰ درصدی در نگهداری را تجربه کرد. از سوی دیگر، در حالی که اکثریت سازمانها شاهد افزایش پیچیدگی و خطوط کد با تولیدکنندگان کد هستند، این پنج مهندس شاهد کاهش شگفتانگیز ۱۵ درصدی در خطوط کد ایجاد شده بودند.
German Tebiev، معمار فرآیند مهندسی نرمافزار که این آزمایش را اجرا کرد، خلاصه کرد: «ما میتوانیم نتیجه بگیریم که، برای آزمایش زنده، GitHub Copilot نتایجی را که میتوان پس از خواندن مقالات آنها انتظار داشت، ارائه نکرد.»
او فکر میکرد که نتایج به اندازه کافی متقاعدکننده هستند تا باور کند که اگر فرآیندهای مناسب در جای خود قرار گیرند، سرعت فعال خواهد شد: «این واقعیت که توان عملیاتی PR رشد قابل توجهی را نشان میدهد به ما میگوید که اگر جریان وظایف به طور موثر مدیریت شود، میتوان به افزایش سرعت مورد نظر دست یافت.»
توسعهدهندگان متفاوت، نتایج متفاوت؟
نتایج حاصل از پایلوت اول خواستار بررسی بیشتر Copilot با یک مخاطب نمونه گستردهتر شد.
برای ۵۰ مهندس دیگر، Devexperts به عقب شمرد و همان معیارها را برای سه ماه قبل از اتخاذ GitHub Copilot و سپس دوباره برای سه ماه پس از آن دوباره بررسی کرد. نتایج بین آزمایش زنده و تجزیه و تحلیل گذشتهنگر بسیار متفاوت بود.
Tebiev گفت: «با GitHub Copilot، ما حجم کار خود را ۲۰٪ کاهش دادیم، وظایف را ۴۵٪ سریعتر به پایان رساندیم و همان سطح کیفیت را حفظ کردیم. مهمترین پیشرفت در مرحله بررسی مشاهده شد.»
با GitHub، این مجموعه بزرگتر سطح نوآوری خود را حفظ کرد، اما به طور قابل توجهی افزایش نداد، در حالی که بازنگری خود را کاهش داد. مهمتر از همه، این تیم کاهش قابل توجهی در توان عملیاتی را تجربه کرد.
در تجزیه و تحلیل گذشتهنگر، این مهندسان کار کمتری را به پایان رساندند اما سریعتر این کار را انجام دادند. با این حال، در آزمایش زنده، آنها افزایش سرعت را مشاهده نکردند، اما افزایش بهرهوری را مشاهده کردند.
از آنجایی که آنها نتایج کمی را خلاف انتظار یافتند، Tebiev پیشبینی میکند که نقصهایی در تجزیه و تحلیل و طراحی گذشتهنگر وجود دارد، بنابراین آزمایشهای بیشتری مورد نیاز است. «در Devexperts، ما نتوانستیم فرآیند توسعه را به اندازه کافی جدا کنیم یا یک انتخاب قدرتمند از مهندسان را جمعآوری کنیم تا نتایج پایداری ارائه دهیم.»
به طور کلی، همه چیز به طور مثبت پیش رفت، و هر گونه تصوری از افزایش بهرهوری برای اکثریت توسعهدهندگان چیزی نیست که بتوان آن را نادیده گرفت. این ممکن است فقط دردهای رشد یا نیاز به بررسی گردش کار و فرآیندهای شرکت باشد.
تجربه کیفی توسعهدهنده
اعداد مهم هستند، اما فقط تا حدی. دادههای کیفی، از جمله احساس توسعهدهندگان، به همان اندازه مهم است. اغلب، حتی تصور بهرهوری میتواند بر واقعیت تأثیر بگذارد.
Devexperts از پلتفرم هوش مهندسی DX برای اجرای نظرسنجیهای بهرهوری توسعهدهنده فصلی به نام Snapshots استفاده میکند. این شامل پرسیدن این سوال بود: به طور متوسط، به لطف GitHub Copilot، هر هفته چقدر در زمان خود صرفهجویی میکنید؟
- ۲+ ساعت در هفته.
- ۱-۲ ساعت در هفته.
- ۳۱-۶۰ دقیقه در هفته.
- ۱-۳۰ دقیقه در هفته.
- هیچ صرفهجویی در زمان.
فقط ۱۷٪ از توسعهدهندگان پاسخ دادند که فکر میکنند Copilot به آنها کمک کرده است حداقل یک ساعت در هفته صرفهجویی کنند، در مقابل ۴۰٪ چشمگیر هیچ صرفهجویی در زمان با استفاده از تولیدکننده کد مشاهده نکردند، که بسیار کمتر از میانگین صنعت است.
توسعهدهندگان همچنین توانستند تجربه حکایتی خود را به اشتراک بگذارند، که بسیار وابسته به موقعیت است. به نظر میرسید Copilot انتخاب بهتری برای تکمیل خطوط کد اساسیتر برای ویژگیهای جدید است، نه چندان زمانی که پیچیدگی کار با یک codebase موجود وجود دارد.
همانطور که الکساندر، مهندس ارشد نرمافزار، بیان کرد: «برای برخی از کارهای روتین ساده اما زننده مانند تولید برخی دادههای آزمایشی، اشیاء، JSON و غیره عالی است. گاهی اوقات در تولید برخی از تستهای واحد خوب است، اما اثربخشی در اینجا به طور جدی محدود است.»
اما حتی اگر Copilot برخی از زحمات او را حذف کرد، او همچنان متقاعد نشده بود که میتواند کدنویسی منظم را انجام دهد، و آن را برای پشته توسعه بکاند معمولی Kotlin-Java "بیفایده" خواند.
چندین توسعهدهنده نیز شکایت کردند که دستیار کدنویسی هوش مصنوعی محبوب اصلاً به رفع اشکال کمک نمیکند زیرا نمیتواند زمینه یک codebase بزرگتر را مدیریت کند. از آنجایی که توانایی جداسازی قطعات در codebaseهای پیچیدهتر دشوارتر میشود، Dmitry Derbenev، رئیس تحقیق و توسعه در Devexperts گفت، برای یک LLM برای درک زمینه برای ارائه توصیههای دقیق، به طور فزایندهای حیاتی خواهد شد.
الکساندر، توسعهدهنده نرمافزار، پاسخ داد: «Copilot نوشتن ویژگیهای جدید را آسانتر میکند و گاهی اوقات جملات را به راحتی کامل میکند. این کلاسها و مدلهای اساسی را به خوبی مدیریت میکند، اما کمک زیادی به رفع اشکال یا پیشنهادات نمیکند، که بخش اصلی کار من در پروژه است. به نظر من، سایر راهحلها مانند ChatGPT و Claude تاکنون در این نقطه عملکرد بهتری داشتهاند. Copilot قطعاً یک تغییردهنده بازی نیست.»
یکی از توسعهدهندگان فرانتاند که Copilot را مفیدترین یافت، پاسخ داد که اگر از او گرفته شود دلتنگ آن خواهد شد، و از اینکه در Android Studio گنجانده نشده است ابراز تاسف کرد.
آیا Cursor بهتر از Copilot است؟
برای آزمایش بعدی خود، از ۳۰ اکتبر ۲۰۲۴ تا ۳۰ ژانویه ۲۰۲۵، ۱۱ توسعهدهنده از Devexperts که قبلاً از Copilot استفاده کرده بودند، شروع به گنجاندن تکمیلکننده کد Cursor در کار خود کردند.
اندازهگیری این گروه Cursor در ابتدا قرار بود بر اساس معیار Cycle Time - اندازهگیری از اولین commit تا ادغام درخواست pull - استوار باشد. با این حال، آنها دریافتند که این یک منبع حقیقت غیرقابل اعتماد است زیرا بیش از حد نوسان داشت و دامنه محدودی داشت، زیرا فقط "به طور جزئی" زمان مورد نیاز برای تکمیل یک کار را ثبت میکرد.
Dmitry Derbenev، رئیس تحقیق و توسعه در Devexperts گفت: «هنگام آزمایش در یک محیط زنده، دشوار است فقط یک عامل - مانند استفاده از Copilot یا Cursor - را جدا کرد. حجم کاری متفاوت، تعطیلات، مدت زمان محدود، codebase متفاوت و عوامل دیگر، طراحی مناسب آزمایش را هم چالش برانگیز و هم مهم میکند. علاوه بر این، مدت زمان کوتاه آزمایش - سه ماه - مشاهده روندهای معنادار را دشوار کرد.»
برخی از نتایج کمی چشمگیر بود. برخلاف Copilot، با Cursor، آنها افزایش ۵ تا ۱۰ درصدی را برای رفع اشکال مشاهده کردند. اما باز هم، بزرگترین برد در توسعه Greenfield با بهبود شگفتانگیز ۸۰ درصدی بود - وظایفی که به طور معمول سه تا چهار روز طول میکشید به یک روز کاهش یافت.
اما از آنجایی که نتایج کمی به اندازه کافی ذهنی نبود، Derbenev گفت که "ما در درجه اول به بازخورد ذهنی توسعهدهندگان تکیه کردیم تا اندازهگیریهای صرفاً کمی برای تجزیه و تحلیل نتایج."
او در پستی در LinkedIn استدلال کرد که اندازهگیریهای عینی هنوز محدودیتهای زیادی در توسعه نرمافزار دارند و حتی میتوانند در دستیابی به اهداف تداخل ایجاد کنند و "مشوقهای پیچیدهای" ایجاد کنند.
بازخورد کیفی Devexperts بر سه سوال متمرکز بود:
- آیا قصد دارید در آینده از Cursor استفاده کنید؟
- آیا به استفاده از Copilot ادامه میدهید؟ اگر بله، همراه با Cursor؟ به تنهایی؟ هیچ کدام.
- هر گونه نظر آزاد؟
حتی با در نظر گرفتن کوتاهی این دوره زمانی، نتایج کیفی کلی Cursor در مقابل Copilot، طبق دادههای کیفی DX بیشتر، به نفع Cursor بود:
- هشت نفر از ۱۱ توسعهدهنده پس از آزمایش به استفاده از Cursor ادامه دادند، در حالی که دو توسعهدهنده احساس نکردند که دوباره از Cursor استفاده خواهند کرد.
- چهار پاسخدهنده تصمیم گرفتند به استفاده از Copilot با یا بدون Cursor ادامه دهند، در حالی که هفت توسعهدهنده Copilot را به نفع Cursor متوقف کردند.
بزرگترین نقطه ضعف Cursor این بود که، به عنوان یک انشعاب از محیط توسعهدهنده یکپارچه VSCode، نیاز به تغییر به یک IDE متفاوت دارد. Derbenev توضیح داد که این برای اکثر توسعهدهندگان فرانتاند خوب بود، اما توسعهدهندگان بکاند ترجیح میدادند از IDEهای دیگری استفاده کنند.
این همچنین به Viktor Isaev، معمار سازمانی، الهام بخشید تا یک اثبات مفهوم با Cursor Agent دستیار کد هوش مصنوعی را اجرا کند، بدون هیچ گونه کمک دستی - فقط اجازه دادن به توسعهدهندگان برای آزمایش. این دوباره در زحمت عالی بود، اما کمتر در کار پیچیدهتر و حل مسئله انسانی.
Isaev گفت: «تصور من این است که به خودکارسازی ۸۰٪ از کاری که ۲۰٪ از زمان را میگیرد کمک میکند. در چیزهای استاندارد و خوشتعریف که نیاز به مقدار زیادی Boiler-plating دارند یا ساختن چیزهایی که به خوبی شناخته شدهاند که چگونه ساخته میشوند، خوب است، این سرعت را بسیار افزایش میدهد.»
اما، مشابه Copilot، با پیچیدهتر شدن وظایف و کد، او متوجه شد که کم و بیش اتلاف وقت است. او گفت که این همان نتیجهای بود که در سراسر وظایفی که شامل «ساخت پروژه از ابتدا، انجام کارهای اضافی، انجام بازسازی، ایجاد تستهای ساخت و معرفی برخی از لایههای معماری مانند احراز هویت [و] مجوز» بود.
بخش اساسی این آزمایشها که باید در نظر گرفته شود این است که هیچ کدام از آنها شامل آموزش در مورد مالکیت معنوی Devexperts یا مشتریان آن نبود. Derbenev گفت: «من معتقدم که سازماندهی کار با زمینه codebase و مستندات به روشی مناسب، ایمن و قابل اعتماد، بزرگترین چالش برای داشتن افزایش بهرهوری مناسب در هنگام استفاده از LLM است.»
در این میان، با در نظر گرفتن همه این نتایج - و با در نظر گرفتن کل هدف که بهبود تجربه توسعهدهنده است - Devexperts اکنون به توسعهدهندگان حق انتخاب ابزارهای توسعهدهنده هوش مصنوعی را میدهد. این شرکت هزینه مجوزهای ممتاز را برای Copilot یا Cursor پرداخت خواهد کرد. و بازخورد مداوم توسعهدهندگان ادامه خواهد یافت.
درباره نویسنده
جنیفر ریگینز یک داستاننویس، روزنامهنگار، نویسنده و میزبان رویداد و پادکست در حوزه فرهنگ فناوری است که به اشتراکگذاری داستانها در جایی که فرهنگ و فناوری با هم برخورد میکنند و ترجمه تأثیر فناوری که میسازیم کمک میکند. او بوده است...
بیشتر از جنیفر ریگینز بخوانید