پیش‌گفتار
چند باری با یکی از دوستان عزیزم («می مهدی») در مورد تاثیر هوش مصنوعی بر آینده‌ی توسعه‌ی نرم‌افزار صحبت کردیم. این گفتگو بهانه‌ای شد تا کمی بیشتر به آن بپردازم. هفته‌ی گذشته یک سخنرانی بسیار ارزشمند رو به صورت اتفاقی دیدم و بر آن شدم تا خلاصه‌ای از آن را به فارسی برگردانم. امیدوارم برای شما عزیزان مفید باشد.
اصل سخنرانی را می‌تونید در آدرس زیر پیدا کنید.
https://www.youtube.com/watch?v=tbDDYKRFjhk
اهمیت سخنرانی
دستیارهای کدنویسی هوش مصنوعی (AI Coding Assistants) به‌سرعت وارد مهندسی نرم‌افزار شده‌اند، اما تأثیر واقعی آنها همچنان نامشخص است. آیا استفاده از آنها واقعن تحویل نرم‌افزار را سریع‌تر می‌کند یا صرفن باعث می‌شوند کد بیشتری تولید شود که توسعه‌دهندگان مجبور می‌شوند بعدن آن را اصلاح کنند؟ این سوال برای مدیران ارشد فناوری و مدیران مهندسی که مسئول ارزیابی پذیرش هوش مصنوعی هستند، حیاتی است.
یگور دنیسوف-بلانچ (Yegor Denisov-Blanch) در سخنرانی خود در استنفورد، یافته‌هایی از یکی از بزرگ‌ترین مطالعات تجربی درباره بهره‌وری توسعه‌دهندگان ارائه می‌دهد که بر پایه‌ی داده‌های بیش از ۱۰۰,۰۰۰ توسعه‌دهنده است.
دنیسوف-بلانچ، پژوهشگر استنفورد در حوزه مهندسی نرم‌افزار داده‌محور (data-driven software engineering)، مطالعه‌ای چندساله را ارائه کرد که بیش از ۶۰۰ شرکت و میلیاردها خط کد را شامل می‌شود که ۸۰٪ آنها کدهای شرکت‌ها هستند (اهمیت استفاده از کدهای خصوصی (private repositories) به جای کدهای در دسترس عموم ( public repositories) در ارایه توضیح داده شده است).
پژوهش او به این سؤال پاسخ می‌دهد: هوش مصنوعی تا چه اندازه و تحت چه شرایطی بهره‌وری توسعه‌دهندگان را بهبود می‌بخشد؟
استدلال‌های اصلی
۱. چرا مطالعات سنتی شکست می‌خورند
بیشتر مطالعات بهره‌وری که توسط فروشندگان (vendor) انجام یا هدایت می‌شوند، بر مبنای معیارهای ناقصی مانند تعداد کامیت‌ها (commit)، تعداد پی‌آر (PR) یا نظرسنجی‌ها انجام می‌شوند. اما این معیارها با نادیده گرفتن تفاوت‌های اندازه و بزرگی کارها (task size) یا چرخه‌ی رفع اشکال (bug-fix churn)، بهره‌وری را بیش از حد نشان می‌دهند. به گفته دنیسوف-بلانچ: «ارائه کامیت‌های بیشتر لزومن به معنای بهره‌وری بیشتر نیست.». از سوی دیگر، نظرسنجی‌هایی که با مشارکت توسعه‌دهندگان انجام می‌شوند نیز عملکرد بهتری ندارند و آمار نشان می‌دهد که «توسعه‌دهندگان بهره‌وری خود را به‌طور متوسط ۳۰ درصد اشتباه تخمین می‌زنند».
پیامد عملی این واقعیت‌ها این است که رهبران و مدیران باید نسبت به ادعاهای بازاریابی هشیار و محتاط باشند و چارچوب‌های اندازه‌گیری قوی و درستی را اتخاذ کنند.
۲. اندازه‌گیری آنچه اهمیت دارد
تیم استنفورد مدلی طراحی کرده که کارکردهای تحویلی (functionality delivered) را کمی‌سازی می‌کند که در آن، نتایج توسط گروهی از مهندسان متخصص بررسی و اعتبارسنجی می‌شود. این مدل، «خروجی به‌درد بخور و مفید» (useful output) را به جای معیارهایی مانند تعداد خطوط اندازه‌گیری می‌کند. در کل، دستیارهای کدنویسی در ظاهر بهره‌وری را ۳۰-۴۰٪ را افزایش می‌دهند (بهره‌وری ظاهری)، اما بخش زیادی از این بهره‌وری به دلیل «دوباره‌کاری» (rework) و رفع اشتباهات هوش مصنوعی خنثی شده و کاهش پیدا می‌کند. در نتیجه بهره‌وری به صورت خالص و پایدار حدود ۱۵-۲۰٪ افزایش می‌یابد.
پیامد عملی: پذیرش هوش مصنوعی با در نظر گرفتن رفع خطاها، بهره‌وری را افزایش می‌دهد و میزان افزایش، «متوسط» است.
۳. بهره‌وری بر اساس پیچیدگی وظایف متفاوت است
نتایج از ۱۳۶ تیم در ۲۷ شرکت نشان‌دهنده‌ی تفاوت آشکاری در نتایج است:
- کارها با پیچیدگی کم در پروژه‌ها جدید (greenfield): افزایش ۳۰-۴۰٪
- کارها با پیچیدگی زیاد در پروژه‌های جدید (greenfield): افزایش ۱۰-۱۵٪
- کارها با پیچیدگی کم در پروژه‌های موجود (brownfield): افزایش ۱۵-۲۰٪
- کارها با پیچیدگی زیاد در پروژه‌های موجود (brownfield): افزایش ۰-۱۰٪
یادآوری: گرین‌فیلد به پروژه‌ای گفته می‌شود که از صفر شروع می‌شود و براون‌فیلد به پروژه یا کد موجود گفته می‌شود.
این نشان می‌دهد که نه فقط انتخاب ابزار بلکه که نوع کار نیز در نتایج بهره‌وری بسیار تاثیرگذار است.
پیامد عملی: هوش مصنوعی باید برای ایجاد ساختار ابتدایی کد (Scaffolding) (مانند ایجاد فولدرها، فایل‌ها، پیکربندی و کد ابتدایی پروژه)، کدهای تکراری و استاندارد (Boilerplate) (مانند نوشتن مدلهای پایگاه داده یا کدهای CRUD) یا افزودن ویژگی‌های ساده به‌ویژه برای پروژه‌های جدید، هدف‌مند و بهینه شود.
۴. زبان اهمیت دارد
هوش مصنوعی در زبان‌های معروف و اصلی مانند پایتون، جاوا، جاوااسکریپت و تایپ‌اسکریپت بسیار مؤثر است و باعث افزایش ۱۰-۲۰٪ بهره‌وری می‌شود. در زبان‌های کم‌محبوب مانند هسکل، اکسیر یا کوبول (Haskell, Elixir, COBOL)، هوش مصنوعی نه‌تنها مزایای زیادی به همراه ندارد، بلکه می‌تواند با تولید کد بی‌کیفیت، بهره‌وری را کاهش دهد.
پیامد عملی: سرمایه‌گذاری در هوش مصنوعی باید بر اساس زبان برنامه‌نویسی انجام شود ؛ سرمایه‌گذاری روی تکنولوژی‌ها و زبان‌های خاص، ناشناخته و کم‌مصرف ممکن است فایده‌ی چندانی به همراه نداشته باشند.
۵. اندازه پایگاه کد و محدودیت‌های زمینه
هر چه پایگاه کد (code base) بزرگ‌تر و قدیمی‌تر، بازده هوش مصنوعی در آن کمتر است. حتی با پنجره‌های زمینه‌ی بزرگ [پنجره زمینه یا context window به تعداد توکن یا کلمه‌ای گفته می‌شود که یک مدل زبانی یا LLM می‌تواند دریافت کند] هم دقت کدهای تولیدشده با افزایش اندازه ورودی کاهش می‌یابد. به عبارت ساده‌تر، دقت کدنویسی مدلهای زبانی از حدود ۹۰٪ در ۱,۰۰۰ توکن به حدود ۵۰٪ در ۳۲,۰۰۰ توکن افت می‌کند.
پیامد عملی: هوش مصنوعی بهتر است برای زمینه‌های (کانتکست) کوچک‌تر و ماژولار استفاده شود—پروژه‌های با ساختار مونولیت‌ها(monolith)، کیفیت کدهای خروجی آن را به شدت کاهش می‌دهند.
جمع‌بندی نتایج: داده‌ها چه واقعیتی را نشان می‌دهند
جذاب‌ترین بینش (insight) و یافته در این تحقیق این است که شکافی بین بهره‌وری ادراکی و واقعی (perceived and real productivity) وجود دارد:
- افزایش بهره‌وری از جنبه‌ی ادراکی: توسعه‌دهندگان به دلیل تولید سریع‌تر کد احساس سریع‌تر بودن و افزایش بهره‌وری می‌کنند.
- افزایش بهره‌وری از جنبه‌ی واقعی: پس از کسر بهره‌وری به دلیل دوباره‌کاری‌ها، بهره‌وری واقعی به‌طور متوسط ۱۵-۲۰٪ است.
توجه به این نکته بسیار مهم است زیرا هوش مصنوعی نمودارهای بهره‌وری را یک‌دست و متوازن تغییر نمی‌دهد:
- در حوزه‌های عادی (روتین) و با پیچیدگی کم باعث افزایش توان (throughput) می‌شوند.
- در حوزه‌های پیچیده، قدیمی و زبان‌های نامحبوب، نقش چشم‌گیری در افزایش بهره‌وری ندارند و گاه باعث کاهش آن می‌شوند.
- افزایش بهره‌وری سازمانی به میزان هم‌راستایی هوش مصنوعی با نوع کار بستگی دارد.
این تحقیق تأکید می‌کند که هوش مصنوعی شتاب‌دهنده‌ای همه‌گیر و برای همه‌ی شرایط نیست (universal accelerator) بلکه تقویت‌کننده‌ی موقعیتی (situational multiplier) است.
راهنمای پیاده‌سازی
رهبران مهندسی می‌توانند با موارد زیر تأثیر را به حداکثر برسانند:
- تطبیق هوش مصنوعی با نوع کار: برای کارهای با پیچیدگی کم استفاده کنید، نه سیستم‌های حیاتی.
- اندازه‌گیری کارکردها، نه کامیت‌ها: برای بهره‌وری، معیارهای مبتنی بر خروجی و نتایج را اتخاذ کنید.
- اولویت‌بندی زبان‌های محبوب: روی پایتون، جاوا، جاوااسکریپت/تایپ‌اسکریپت قبل از تکنولوژی‌های خاص تمرکز کنید.
- نظارت بر میزان دوباره‌کاری: چرخه‌ی رفع اشکال (باگ‌ها) را کنترل کنید تا اسیر ادعاهای اغراق‌آمیز نشوید.
- استفاده ماژولار: استفاده از هوش مصنوعی را به زیرسیستم‌ها محدود کنید، نه کل پایگاه کد و مونولیت‌ها.
- آموزش توسعه‌دهندگان: انتظارات را هم‌راستا و مبتنی بر واقعیت‌ها کنید—هوش مصنوعی ابزار است، نه جایگزین.
- پذیرش و استفاده‌ی تدریجی و تکراری: معیارهای بهره‌وری را هر سه ماه بازبینی کنید، زیرا مدل‌ها در حال تکامل هستند.
ریسک‌ها و محدودیت‌ها
استفاده از دستیارهای کدنویسی هوش مصنوعی در محیط‌های قدیمی، پیچیده یا خاص با خطر کاهش بهره‌وری همراه است. آنها ممکن است باعث پف‌کردن کد (تولید کد اضافی)، معرفی اشکالات ظریف و مبهم، و کاهش عمق مهارت توسعه‌دهندگان (developer skill depth.) شوند. ریسک‌های سازمانی شامل انتظارات اغراق‌آمیز (مثلاً «جایگزینی مهندسان با هوش مصنوعی») و نگرانی‌های حریم خصوصی به دلیل پایش و نظارت بر خروجی توسعه‌دهندگان است.
نتیجه‌گیری
ابزارهای کدنویسی هوش مصنوعی بهره‌وری را افزایش می‌دهند—اما نه همه‌جا و نه به‌طور یکسان برای همه‌ی موارد. افزایش بهره‌وری در کارهای با پیچیدگی کم و پروژه‌های جدید (گرین‌فیلد) در زبان‌های اصلی بالاتر است و به‌طور متوسط ۱۵-۲۰٪ است. مدیران باید رویکردی گزینشی و داده‌محور اتخاذ کنند و هوش مصنوعی را با تکنیک‌های مهندسی همراه کنند. در ۶ تا ۱۲ ماه آینده، پیشرفت در افزایش بزرگی زمینه (کانتسک) در مدلهای زبانی ممکن است عملکرد آنها را بهبود بخشد، اما پیچیدگی، اندازه پایگاه کد و دوباره‌کاری همچنان محدودیت‌های اساسی خواهند بود.
خلاصه
- ابزارهای کدنویسی هوش مصنوعی پس از کسر دوباره‌کاری‌ها، بهره‌وری را ۱۵-۲۰٪ افزایش می‌دهند.
- بهترین نتایج برابر است با افزایش ۳۰-۴۰٪ در بهره‌وری برای کارهای با پیچیدگی کم و پروژه‌های جدید (گرین‌فیلد) در زبان‌های محبوب.
- ریسک‌های استفاده از آنها عبارتند از بی‌تأثیری یا تاثیر منفی آنها در محیط‌های پیچیده، قدیمی یا با تکنولوژی‌های خاص.
گزیده:
ندارد.
دیدگاهتان را بنویسید