بهرهوری بالا رفت، تجربهٔ توسعهدهنده پایین اومد
هوش مصنوعیخلاصهٔ کاملتر
این پست دومین قسمت از سریایه که نویسنده دربارهٔ یافتههای پژوهش کارشناسی ارشدش روی اثر هوش مصنوعی بر مهندسی نرمافزار مینویسه. سؤال این قسمت اینه: استفاده از دستیارهای کدنویسی چه اثری روی برداشت مهندسها از تجربهٔ توسعه و بهرهوریشون میذاره. خودش تأکید میکنه مطالعه بین اکتبر ۲۰۲۴ تا آوریل ۲۰۲۵ اجرا شده که به مقیاس این حوزه قدیمیه، پس بهتره به چشم یه عکس فوری از همون بازه دیده بشه.
برای سنجش بهرهوری، نویسنده از تعریف DORA استفاده کرده: «میزانی که فرد حس میکنه تو کارش مؤثر و کارآمده». چون خود تعریف بر پایهٔ حسه، مستقیم از شرکتکنندهها خواسته تغییر بهرهوریشون رو ارزیابی کنن. برای تجربهٔ توسعهدهنده اما به ساختار بیشتری نیاز داشته و از چارچوب DevEx استفاده کرده که این حس مبهم رو به سه بُعد میشکنه: حلقههای بازخورد، بار شناختی، و حالت شناوری.
خبر خوب اینه که بهرهوری بالا رفت و بالا موند: ۸۴ درصد شرکتکنندهها تو هر دو نقطهٔ زمانی گفتن هوش مصنوعی بهرهوریشون رو بهتر کرده و بیشتر از سهچهارم افراد منطبق دقیقاً همون امتیاز مثبت رو تکرار کردن. تجربهٔ توسعهدهنده اما نیمهٔ پیچیدهتر ماجراست. نویسنده افراد رو به سه گروه تقسیم کرده — مثبت، منفی و میانه — و جابهجاییشون رو تو شش ماه دنبال کرده. گروه منفی تقریباً دو برابر شد، از ۱۴ به ۲۷ درصد، و از کسانی که مثبت شروع کرده بودن فقط ۳۷ درصد تا آخر کاملاً مثبت موندن.
نکتهٔ نگرانکنندهتر چسبندگی گروه منفیه: هیچکس از اونجا کاملاً به گروه مثبت برنگشت و بهترین حالت رسیدن به خنثی بود. یعنی مهندسها حس میکنن بیشتر کار میکنن ولی حالشون موقع انجامش بدتره. این یافته یه فرض قدیمی رو زیر سؤال میبره: سالها پژوهشها میگفتن تجربهٔ توسعهدهنده و بهرهوری با هم حرکت میکنن، و همین پیشفرضِ DevEx بوده — تجربه رو بهتر کن، بهرهوری دنبالش میاد. دادههای نویسنده نشون میده این پیوند با ورود هوش مصنوعی داره میشکنه.
سه بُعد یکسان حرکت نکردن. حالت شناوری تندترین سقوط رو داشت: سهم کسانی که اون رو بدتر ارزیابی کردن از ۷ به ۲۰ درصد رسید. بار شناختی خیلی ملایمتر بدتر شد، از ۶ به ۹ درصد — همون بخشی که تو دموها نشون داده نمیشه: ارزیابی مداوم و پیشنهادِ «تقریباً درست ولی نه کاملاً» که بررسی و اصلاحش بیشتر از نوشتن از اول خرج برمیداره. در عوض حلقههای بازخورد تنها بُعدی بود که بهتر شد.
نویسنده حدس میزنه بین همین دوتا رابطهای باشه: هوش مصنوعی هر چند ثانیه یه جواب دستت میده، ولی هر جواب یه تصمیم کوچیک هم هست — بخونش، قضاوتش کن، قبولش کن یا درستش کن، بعد دوباره پرامپت بده. این یه تعویض زمینهست که مدام تکرار میشه. جالبتر اینکه تو نقطهٔ اول، بُعدی که بیشترین همراستایی رو با حس بهرهوری داشت حالت شناوری بود؛ تو نقطهٔ دوم جاشو به سرعت حلقهٔ بازخورد داد.
برای توضیح افت شناوری، نویسنده به مفهوم «شناوری تقلبی» اشاره میکنه که جرمی هاوارد تو یه سخنرانی مطرح کرده بود: چیکسنتمیهای، همون روانشناسی که ایدهٔ flow رو داد، یه پسرعموی بدلی هم براش توصیف کرده بود. شناوری واقعی وقتیه که یه چالش واقعی مهارتت رو کش میده و ازش رشد میکنی؛ شناوری تقلبی فقط تو رو به کشیدن اهرم ادامه میده. نویسنده میگه پرامپتزدن به مدل شباهت زیادی به همون اهرم داره — گاهی میزنه تو هدف، گاهی مزخرف تحویل میده، ولی تو دنبال نتیجهٔ خوب بعدی ادامه میدی.
قاب نهایی از فیلسوف السدر مکاینتایر میاد: تمایز «کالاهای درونی» یه حرفه — مهارت، استادی، رضایتی که فقط از انجامدادن خود کار میاد — و «کالاهای بیرونی» مثل پول، جایگاه و خروجی. به گفتهٔ نویسنده هوش مصنوعی برای کالاهای بیرونی درخشانه و برای درونیها بالقوه خورنده. جمعبندیش هم اینه که اگه ساختن داره به ارکستراسیون منتقل میشه، کار ما تعریف این نقش تازه و طراحیشه بهشکلی که ارزش انجامدادن داشته باشه — این یه مسئلهٔ طراحی سیستمه، نه یه شکست فردی.
نکات کلیدی:
- ۸۴ درصد شرکتکنندهها تو هر دو نقطهٔ زمانی گفتن بهرهوریشون بهتر شده
- گروهی که تجربهشون بدتر شده بود از ۱۴ به ۲۷ درصد رسید و برگشت از این گروه تقریباً رخ نداد
- حالت شناوری بیشترین افت رو داشت (۷ به ۲۰ درصد)، حلقهٔ بازخورد تنها بُعد بهترشده بود
- چیزی که حس بهرهوری رو میساخت از «غرقشدن در مسئله» به «سرعت برگشت کد» جابهجا شد
- نویسنده این رو مسئلهٔ طراحی سیستم میدونه، نه ضعف شخصی مهندسها
