بعد از نوشتن کد، نوبت کنار گذاشتن ریویو انسانیه؟
هوش مصنوعیخلاصهٔ کامل‌تر
نویسنده با یادآوری یه چرخه شروع می‌کنه که تو انجمن‌های برنامه‌نویسی دیدیم. اولش می‌گفتن کد AI پر از باگه و کار واقعی یعنی خودت بنویسی. بعد همون آدم‌ها گفتن باشه، نوشتنو با AI انجام می‌دم ولی ریویو رو هیچ‌وقت واگذار نمی‌کنم. به گفتهٔ William Martin، یه شیفت سوم هم داره میاد: کنار گذاشتن همون ریویو خط‌به‌خط.
تشبیه مرکزیش اینه: AI میخ رو کوبیده، وقتی کج رفته نمی‌خواد با ناخن درش بیاره وقتی خودِ ابزار اون‌ور چکش نشسته. یعنی همون سیستمی که با سرعت بالا کد می‌نویسه، می‌تونه ریویو و اصلاحش رو هم با همون سرعت انجام بده. نویسنده اعتراف می‌کنه شاید تو زمان‌بندی اشتباه کنه، ولی فکر می‌کنه جهتش همونیه که قبلاً تو نوشتن کد تجربه کردیم.
یه نکتهٔ مهم رو هم صادقانه می‌گه: دفعهٔ قبل ریویو، همون تورِ ایمنی بود. این بار تور باید فرق کنه، یعنی تست و گاردریل و مانیتورینگ. نمی‌گه تورو بردار، می‌گه یه تورِ متفاوت بساز. خودش قانون شخصیشو گذاشته: «یه خط از این کدو نمی‌خونم» رو به‌عنوان نقطهٔ شروع در نظر می‌گیره و از همون‌جا کار می‌کنه.
نویسنده می‌گه باگ‌گیری بدون خوندن هر diff به سه چیز برمی‌گرده. اول، قانون‌ها قبل از کد: گاردریل‌هایی که الگوهای خرابیِ قابل‌پیش‌بینی رو قبل از لند‌شدن می‌گیرن (تکرار کد، پیچیدگی الکی، تست‌های قلابی). خودش یه ابزار کوچیک به اسم slop-mop برای همین ساخته. دوم، ریویوئرهایی که نویسنده نیستن: بات‌هایی مثل Copilot و Bugbot و CodeRabbit، و بهتر از اون ریویوی چندمدلی که یه مدل فقط diff رو می‌بینه، یکی کل ریپو رو و یکی فقط اسپک رو، چون یه مدل که کار خودشو ریویو کنه نقطه‌کورهای خودشو هم داره. سوم، حلقه روی ریل: نوشتن، ریویو، اصلاح و ریویوی دوباره به‌صورت خودکار.
به نظر نویسنده ریویو از بین نمی‌ره، بلکه یه لایه بالاتر می‌ره، از توی diff بیرون میاد و می‌ره توی قانون‌ها و تست‌ها و نیازمندی‌ها. می‌گه باارزش‌ترین کاری که الان می‌تونه بکنه اینه که تست کنه کد چی‌کار می‌کنه، نه اینکه چطوری کار می‌کنه. مثال می‌زنه: برای یه API امتیازات زندهٔ NFL، از user storyها شروع می‌کنه نه از خوندن تابع‌ها؛ آیا امتیاز زنده برمی‌گرده؟ آیا با واقعیت می‌خونه؟ آیا credentialی تو لاگ‌ها لو رفته؟ آیا پاسخ زیر ۲۰۰ میلی‌ثانیه‌ست؟ بعد خودش UAT رو دستی اجرا می‌کنه. می‌گه نیازمندی‌ها و UAT تنها چیزیه که نگه می‌داره و هیچ‌وقت به ایجنت نمی‌سپرشون.
بخش جالب مقاله، تجربهٔ شخصیشه با یه ربات ترید روی Kalshi که با پول خودش کار می‌کنه. حدود ۱۲۷ دلار گذاشته و الان حدود ۱۵۸ دلاره، تو سه هفته نزدیک ۱۵۰۰ ترید زده. اعتراف می‌کنه یه باگ هم بهش ضرر زد: ربات فقط باید بین ۹۶ تا ۹۹ سنت می‌خرید، ولی کد قیمت‌ها رو به سنت کامل گرد می‌کرد، پس ۹۵.۵ می‌شد ۹۶ و رد می‌شد. حدود یک تریدِ از هر ۹تا این‌طوری لیز می‌خورد. می‌گه این یه باگِ نیازمندی بود، نه کد: اسپک هیچ‌وقت نگفته بود با سنت اعشاری چی‌کار کنه. با ریویوی دستی هم که هزاران خط تو ده‌ها فایل بود، بعید بود می‌گرفتش.
جمع‌بندی نویسنده اینه که یه چیز سنگین‌تر میشه و اون مالکیته. AI رو نمی‌شه شکایت کرد، اخراج کرد یا زندانی کرد؛ یکی باید مالک ریلیز و ریسک و حادثه باشه. می‌گه الان بیشتر از وقتی که هر خطو می‌خوندی مالکشی، چون اسمتو داری می‌ذاری پای کدی که اصلاً ندیدیش. به نظرش این تازه همون چیزیه که مهندسی همیشه بوده: تصمیم‌گیری دربارهٔ اینکه نرم‌افزار برای چیه، از کجا می‌فهمی کار می‌کنه و چی هیچ‌وقت نباید بشکنه.
نکات کلیدی:
- ادعای اصلی: بعد از نوشتن کد، نوبت کنار رفتن ریویو خط‌به‌خطِ انسانیه و جاشو تست و گاردریل می‌گیره
- سه جایگزین ریویو: قانون‌های قبل از کد (گاردریل)، ریویوئرهای غیرنویسنده (ترجیحاً چند مدل مختلف)، و حلقهٔ خودکار نوشتن-ریویو-اصلاح
- ریویوی چندمدلی بهتره چون یه مدل که کار خودشو چک کنه نقطه‌کورهای خودشو داره
- نویسنده ابزاری به اسم slop-mop برای گاردریل‌ها ساخته
- تجربهٔ واقعی: ربات ترید Kalshi با ۱۲۷ دلار، یه باگِ گردکردن قیمت (۹۵.۵ → ۹۶) حدود ۳۰ دلار ضرر زد
- اون باگ یه باگِ نیازمندی بود نه کد؛ نگه‌داشتن نیازمندی‌ها و UAT سمت انسان، تنها چیزیه که واگذار نمی‌شه
