«فقط کدش رو ریویو کن» جواب نمیده
هوش مصنوعیخلاصهٔ کاملتر
توماس دپیر تو این یادداشت خودش رو نسبت به فایدهٔ LLM تو توسعهٔ نرمافزار شکاک معرفی میکنه، ولی دلیلش رو دقیق مشخص میکنه: نه مشکلات مالکیت فکری، نه مصرف منابع و محیطزیست، و نه حتی «همهشون بیکیفیتن». به گفتهٔ او مشکل اینه که با توجه به شواهد علمی موجود نمیتونه ببینه این ابزارها چطور قراره کسی رو در نوشتن کد بهتر یا سریعتر کنن. (خودش هم اشاره میکنه این متن حدود یک سال پیش نوشته شده، برای همین هنوز اصطلاح Coding Assistants توش به کار رفته.)
نقطهٔ تمرکز نقدش چیزیه که «مسئلهٔ کارآموز» صداش میکنه: این ابزارها به دلایل ساختاری و رابطکاربری زیاد اشتباه میکنن — از توهم و تایپو گرفته تا انجام کاری که اصلاً ربطی به تسک نداره. خیلیها میگن حسش «مثل کار با یه کارآموزه»، و جواب رایج طرفدارها هم همینه: مثل کارآموز و جونیور، خودت همهٔ کدش رو ریویو کن؛ آخرش هم که تو مسئول کدی و اصلاً همهٔ کد قبل از ورود به کدبیس ریویو میشه دیگه.
نویسنده اول روشن میکنه منظور از «ریویو» چیه. به نظر او برای این کار نمیشه به همون ریویوهای سبک و پخششدهای که تو صنعت رایجه اکتفا کرد؛ اونها بیشتر برای انتشار دانش تغییرات و اعمال قواعد سطحی خوبن. اینجا به یه code review واقعی و درگیرکننده نیاز هست، چون طرف مقابل «کارآموزی»ه که گاهی کد پیچیده مینویسه.
و دقیقاً همینجاست که به گفتهٔ او شواهد تجربی سر راه سبز میشن. دو یافتهٔ نسبتاً محکم دربارهٔ code review وجود داره: ریویوی بیشتر از یک ساعت زیادی طولانیه و سرعت مؤثر ریویو حدود حداکثر ۴۰۰ خط کد در ساعته. نکتهٔ مهم اینه که افت بازدهی بعد از یک ساعت ربطی به اندازهٔ کد نداره — آدم بعد از یک ساعت تمرکز در اون سطح، خسته و بیحوصله میشه. دربارهٔ زمان لازم برای ریکاوری بین جلسهها هم عملاً پژوهشی پیدا نکرده.
حالا این دو تا رو کنار هم بذارید: برای هر ۴۰۰ خط کدی که ابزار مینویسه، یه توسعهدهندهٔ سنیور باید یک ساعت وقت بذاره — و هفتهای فقط ۱۰ تا ۴۰ تا از این اسلاتها داره، اون هم اگه جلسه و طراحی و اینسیدنت اجازه بدن. نتیجهگیری نویسنده اینه که تو بهترین حالت، خروجی روزانهٔ نوشتن + ریویو + کامیت چند هزار خطه و در حالت واقعبینانهتر کمتر از هزار خط در روز — و این عدد شامل همهچیزه: boilerplate، تست، مایگریشن و کانفیگ.
بعد یه لایه بدتر اضافه میکنه: این شواهد از پژوهش روی ریویو انسان بر کد انسان به دست اومده. هیچ شواهدی نداریم که آدمها موقع ریویو کد تولیدشده با LLM هم به همون اندازه کارآمد باشن، و شواهد مقدماتی برعکسش رو نشون میده: ریویوکنندهها ایراد کمتری پیدا میکنن ولی مطمئنترن که همهٔ ایرادها رو گرفتن. یعنی نهتنها این راهکار سقف بهرهوری میذاره، اصلاً معلوم نیست کار میکنه یا نه. اون هم بدون اینکه هزینهٔ رفع ایرادها اصلاً حساب شده باشه.
نقطهٔ اوج عصبانیت نویسنده اما جای دیگهایه. یکی از مزیتهایی که طرفدارها تبلیغ میکنن اینه که این ابزارها میتونن دردناکترین کدها رو جای شما بنویسن؛ او نقلقولی میآره که ادعا میکنه از این به بعد «۱۰۰٪ کدهای Bash» رو میشه به ابزار سپرد. به نظر او این بدترین مثال ممکنه: شلاسکریپت همون کدیه که پارسینگ سهلگیر و معنای بیشازحد فشرده داره، سختترین کد برای ریویوئه، و یه تایپوی ساده توش میتونه یا کاملاً بیضرر باشه یا کل یه ماشین رو نابود کنه.
در پایان میگه چی نظرش رو عوض میکنه: پژوهش تجربی روی توانایی انسانها در پیدا کردن ایراد در کد تولیدشده با LLM — با چه سرعتی و چقدر در روز — یا نشوندادن اینکه ریویو محتوای LLM اساساً مسئلهٔ متفاوتیه. هرچند خودش تذکر میده شواهد نوپای فعلی به «سختتر بودن» این نوع ریویو اشاره دارن که استدلالش رو قویتر میکنه. حرف آخرش هم گلایه از فرهنگ حرفهایه: مثل بحثهای TDD، سیستم تایپ، CI/CD و دواپس، دادههای حکایتی باز هم بر شواهد تجربی میچربن، و منتقد بهجای پاسخ، برچسب «دیوونه» میگیره.
نکات کلیدی:
- ادعای مرکزی: «فقط ریویو کن» جواب استدلال شکاکان نیست، چون خود ریویو محدودیتهای تجربی سفتوسختی داره
- دو یافتهٔ پژوهشی: ریویو بالای یک ساعت بازدهیاش میافته و سرعت مؤثر حدود حداکثر ۴۰۰ خط در ساعته
- نتیجه: سقف واقعبینانهٔ خروجی روزانه کمتر از هزار خط کد، شامل boilerplate و تست و کانفیگ
- شواهد موجود از ریویو انسان بر کد انسان میآد؛ برای کد LLM دادهای نداریم
- شواهد مقدماتی: ریویوکنندهٔ کد LLM ایراد کمتری پیدا میکنه ولی اعتمادبهنفس بیشتری داره
- نویسنده تبلیغ Bash بهعنوان کاربرد اصلی این ابزارها رو بدترین انتخاب میدونه، چون سختترین کد برای ریویوئه
- چیزی که نظرش رو عوض میکنه: پژوهش تجربی روی ریویو کد تولیدشده با LLM، نه تجربهٔ شخصی و حکایت
