چقدر میشه به کد وایبکد شده اعتماد کرد؟
خلاصهٔ کاملتر
نویسنده که قبلاً تو مقالههای دیگهش منتقد سرسخت اتکا به کد تولیدشده با LLM بوده، تو این پست میگه یه استثناهایی هم داره: موقعیتهایی که واقعاً کد رو بدون خوندنش شیپ کرده. نکتهی مرکزی مقاله اینه که ظاهر و رفتار بیرونیِ یه نرمافزار سیگنال کمی از کیفیت داخلیش میده؛ یه برنامه میتونه دقیقاً همون کاری رو بکنه که ازش خواستی، ولی از نظر کیفیت مشکل داشته باشه و با اولین تغییر بشکنه.
به گفتهی نویسنده، سؤال اصلی اینه که چقدر سختگیری (rigor) در برابر چقدر ریسک منطقیه. با دو مثال این تناسب رو نشون میده: یکی سختگیری بیشازحد (مثل بازرسی بدنی برای خرید همبرگر تو یه دنیای فرضی که همبرگر گرونه) و یکی هم سختگیری خیلی کم (صحنهای از فیلم The Invention of Lying که چون هیچکس دروغ نمیگه، بانک بهسادگی فریب میخوره). نتیجهای که میگیره اینه که صنعت بانکداری هم عمداً یه مقدار تقلب رو تحمل میکنه، چون صفر کردن کامل تقلب خیلی گرونتر از خود ضرره؛ همین منطق دربارهی ریویوی کد هم صادقه.
برای دستهبندی سطح ریسک، نویسنده از طبقهبندی سهتایی برتراند مایر استفاده میکنه: نرمافزار Casual (مصرف شخصی، محدودیت توزیع کم، مثل یه اسکریپت یا اپ داخلی)، Business (نرمافزاری که اگه خراب بشه سازمان ضرر میکنه) و Acute (حیاتی، جایی که خطا میتونه جون آدم یا پول زیادی رو به خطر بندازه). به گفتهی نویسنده، هرچی نرمافزار به سمت Acute بره، لازمه سختگیری در ریویو هم بیشتر بشه؛ نمونههایی مثل زیرساخت بانکی یا نرمافزار دستگاه پزشکی رو مثال میزنه.
نویسنده فهرستی از اپهای شخصیش رو مثال میزنه که بدون خوندن کد شیپشون کرده -- چیزهایی مثل یه اپ مک برای خاموشکردن صفحه بعد از مدتی بیکاری، یا یه CLI برای OCR کردن رسید. همهشون توزیع محدود داشتن. در مقابل، برای پروژههایی با ریسک بالاتر مثل یه اپ بودجهبندی که پول واقعی مردم رو دست میگیره، میگه رویکردش عوض شده: از یه پروژهی تعطیلات کاملاً وایبکد شده شروع کرده، ولی وقتی تصمیم گرفته اونو تبدیل به محصول کنه، همهی کدهای قبلی رو بازبینی و ریفکتور کرده و حالا هر کد تولیدشده با LLM رو قبل از مرج میخونه.
بخش پایانی مقاله به این ایده میپردازه که «بذار خودِ LLM کد رو ریویو کنه» نمیتونه جایگزین ریویوی انسانی بشه. نویسنده میگه اول اینکه این ریویو مستقل نیست -- همون مدلی که کد رو نوشته، حالا داره بازبینیش میکنه، و مدلهای مختلف هم روی دادههای مشابه آموزش دیدن. دوم اینکه از نظر معرفتشناسی، دانش از سه منبع میاد: شهادت (تستیمانی)، استدلال، و تجربه؛ وقتی فقط به گفتهی LLM اعتماد میکنیم بدون اینکه خودمون استدلال یا تست کنیم، برگشتیم به همون دانش شهادتی که هیچ اوراکل واقعیای پشتش نیست.
نکات کلیدی:
- سطح سختگیری در ریویوی کد باید متناسب با ریسک واقعی پروژه باشه، نه یکسان برای همه
- طبقهبندی Casual/Business/Acute کمک میکنه بفهمیم یه پروژه چقدر به ریویوی دقیق نیاز داره
- نویسنده اپهای شخصی کمریسک رو بدون ریویو شیپ میکنه ولی برای پروژهی مالیای که فروخته میشه، همهی کد رو میخونه
- ریویوِ کد توسط خودِ LLM جایگزین ریویوی انسانی نیست، چون نه مستقله و نه از نظر معرفتشناسی دانش واقعی تولید میکنه




