AI کد بیشتری تولید می‌کنه، ولی سرعت شیپت عوض نشده
هوش مصنوعیخلاصهٔ کامل‌تر
نویسنده (سوایزک تلر) با یه ادعای تند شروع می‌کنه: هرچقدر هم کد تولید کنی، تا وقتی شیپ نشه صفر ارزش داره. نوشتن کد، ساختن فیچر و جابه‌جا کردن تیکت همه شاخص‌های پوچن؛ هیچ‌کدوم مهم نیستن تا وقتی کاربر بتونه کاری بکنه که قبلاً نمی‌تونست. به گفتهٔ اون با AI میشه سریع‌تر از همیشه کد تولید کرد، ولی این مهم نیست، چون احتمالاً هنوز با همون سرعت قبلی شیپ می‌کنی.
نویسنده می‌گه این تو داده‌ها هم دیده میشه: دستاورد بهره‌وری AI در سطح کلان ناچیزه (مثلاً حدود ۴٪ در میانگین ۱۳۰۰ شرکت اروپایی یا ۰.۸٪ خروجی بیشتر)، در حالی که بهره‌وری فردی بالا رفته؛ آدم‌ها کد رو ۵۰٪ سریع‌تر می‌نویسن و ۲۶٪ تسک کدنویسی بیشتری تموم می‌کنن. سؤالش اینه که پس این‌همه هیاهو چرا به نتیجهٔ سطح‌شرکتی نمی‌رسه؟
جوابش «نظریهٔ محدودیت‌ها»ست؛ نسخهٔ مدیریتیِ قانون امدال. به گفتهٔ اون گلدرات تو کتاب‌هاش گفته «کارخونه‌ات سریع‌تر از کندترین بخشش حرکت نمی‌کنه». صرفِ اینکه تیکه‌های جدا سریع‌تر شدن، یعنی کل سیستم بیشتر کار نمی‌کنه. اون یه تصویر آشنا می‌کشه: بیشتر از همیشه کد تولید می‌کنی، تو پول‌ریکوئست و ریویو غرق شدی، ساعت‌ها و روزها منتظر می‌مونی کسی کدت رو ببینه، و آخرش شاید روزی ۱ تا ۲ تغییر شیپ می‌کنی.
نویسنده می‌گه گلوگاه، کدریویوئه. قبلاً نوشتن و انتشار کد سخت بود و یه عالمه ریویو لازم داشت. با DevOps مدرن و CI، انتشار به چند دقیقه رسید و به‌جای تلاش برای گرفتن همهٔ خطاها، خطاها رو راحت‌الپیدا و راحت‌الاصلاح کردیم؛ لینترها و تست‌های خودکار هم ریویو رو سریع‌تر کردن. ولی وقتی AI رو اضافه می‌کنی، کلی کد تولید میشه که از لینتر و تست رد میشه و حالا ریویو زیر بار له شده، بدون اینکه سرعت شیپ بالا رفته باشه.
نکتهٔ جالب مقاله اینه که نویسنده می‌پرسه اصلاً چرا کدریویو؟ به گفتهٔ اون شواهد نشون می‌ده ریویو باگ یا مشکل امنیتی رو نمی‌گیره (برای گرفتن باگ باید تست بنویسی) و بیشتر یه «تمرین اجتماعی-فنی»ه که سلامت بلندمدت نرم‌افزار رو بهتر می‌کنه، آشنایی همه با کد رو بالا می‌بره و نقص‌های پس از انتشار رو کم می‌کنه؛ ضمن اینکه استاندارد SOC2 هم دو انسان رو ملزم می‌کنه هر خط کدِ پروداکشن رو ببینن.
اون کدریویوِ خوب رو یه «دروازهٔ کیفیت» می‌دونه: جایی برای اجرای تست و لینتر، درخواست ویدیو و اسکرین‌شات از فیچرها (که همه رو مجبور به تست می‌کنه)، پریویو دیپلوی برای لمس کردن نرم‌افزار قبل از مرج، «باغبانی کدبیس» برای هل دادن آدم‌ها به الگوهای بهتر، و پیدا کردن نقض‌های مدل دامنه. تأکیدش اینه که ریویو جای ایراد گرفتن از استایل نیست؛ باید «با کامنت تأیید کنی» و «مانع نشی، به بقیه یاد بدی».
برای حل گلوگاه، نویسنده به توصیهٔ گلدرات اشاره می‌کنه: وقتی گلوگاه رو پیدا کردی، بقیهٔ فرایند رو تابعش کن؛ یعنی وقت کمتری صرف تولید کد و بیشتری صرف ریویوِ کدِ موجود، اونم توسط کل تیم، و یکی‌یکی روی پول‌ریکوئست‌ها کار کن تا کارها واقعاً «تموم» بشن. اون با حرف رایج «به کد نگاه نکن» مخالفه و می‌گه اگه دست از دیدن کد برداریم، مجبور می‌شیم پرامپت‌ها و داک‌های طراحی رو ریویو کنیم؛ مشکل فقط یه لایه بالاتر می‌ره (همون‌طور که آدم‌ها کد کامپایل‌شده رو ریویو می‌کردن تا کامپایلرها خوب شدن).
دربارهٔ ریویوِ خودکار هم می‌گه ایدهٔ اولیه‌اش استفاده از LLM به‌عنوان یه لینتر پیشرفته بوده، ولی این یه چیزی رو از دست می‌ده: آموزش بین مربی و شاگرد یه امر شخصیه و سپردنش به ماشین تقریباً توهین‌آمیزه. به گفتهٔ اون کدریویو پرلوریج‌ترین کاریه که یه مهندس ارشد می‌تونه بکنه، چون می‌تونه کل کدبیس رو هدایت کنه و فرصت‌های ابزار و انتزاع بهتر رو پیدا کنه. حرف آخرش: مانع نشو، یاد بده و استدلالت رو توضیح بده تا ایده‌هات پخش بشن؛ چون بازخورد یه متخصص همون چیزیه که باهاش «سلیقه» یاد می‌گیری.
نکات کلیدی:
- کد تا وقتی شیپ نشه هیچ ارزشی نداره؛ تولید بیشتر کد با AI لزوماً یعنی شیپ بیشتر نیست
- طبق نظریهٔ محدودیت‌ها، سیستم سریع‌تر از کندترین بخشش (گلوگاه) حرکت نمی‌کنه
- گلوگاه کدریویوئه؛ حالا که کد راحت‌تر تولید میشه، ریویو زیر بار له شده
- ارزش واقعی ریویو گرفتن باگ نیست، سلامت بلندمدت کد و انتشار دانش بین تیمه
- راه‌حل: کل تیم وقت کمتری صرف تولید و بیشتری صرف ریویوِ کدِ موجود کنه و یکی‌یکی کارها رو تموم کنه
