‏چرا کارخانه‌های نرم‌افزاری شکست می‌خورن

نویسنده — دکس، بنیان‌گذار HumanLayer که خودش هم می‌گه در این حوزه ذی‌نفعه — از روایت پرسروصدای این روزها شروع می‌کنه: تو گلوگاهی، مدل‌ها به‌اندازهٔ کافی خوبن، کد مجانیه، پس فقط بیشتر شیپ کن. نتیجهٔ منطقی این حرف، «کارخانهٔ نرم‌افزاری چراغ‌خاموش» ـه که StrongDM دربارهٔ نسخهٔ خودش نوشت: هیچ انسانی کد نمی‌نویسه و هیچ انسانی کد نمی‌خونه. شرکت‌هایی مثل Ramp، Stripe، WorkOS و Brex هم امسال توضیح دادن که چطور کارخانهٔ ایجنتی‌شون حدود ۷۵٪ کدشون رو تولید می‌کنه.

ولی به گفتهٔ نویسنده، این کارخانه کار نمی‌کنه. گزارش Faros AI نشون می‌ده از وقتی همه این ابزارها رو برداشتن، کیفیت ریویوی pull request افت کرده، کامنت‌ها بیشتر و طولانی‌تر شدن، کلی PR بدون هیچ ریویویی مرج می‌شه، و حوادث و باگ‌به‌ازای‌هر‌توسعه‌دهنده بالا رفته. تجربهٔ خودشون هم همینه: جولای ۲۰۲۵ کامل چراغ‌خاموش رفتن، و بعد از چند ماه به مشکلی خوردن که ایجنت با هیچ پرامپتی حلش نمی‌کرد — مجبور شدن برگردن سراغ کدبیسی که سه ماه بود نمی‌خوندنش. بار سوم، در نوامبر، تصمیم گرفتن از صفر بازنویسی کنن.

نکتهٔ اصلی مقاله اینه که این «مشکل مهارتی» نیست و با تنظیم لینتر و پاشیدن کلمه‌های جادویی روی بات‌های ریویو حل نمی‌شه؛ مسئله، آموزش مدله. نویسنده یادآوری می‌کنه که Claude Code تا حد زیادی به این خاطر برنده شد که انتروپیک مدل رو داخل خودِ harness با یادگیری تقویتی آموزش داد — اولین باری که یه آزمایشگاه، مدل رو دقیقاً روی همون ابزارهایی تمرین داد که قرار بود باهاشون عرضه بشه. حرف تیم اوپن‌اِی‌آی هم همینه: اگه harness بسازی ولی وزن‌ها دستت نباشه، همیشه از تیمی که هر دو رو داره عقب‌تری.

حالا ببینیم این آموزش چی رو پاداش می‌ده. تو SWE-bench Multilingual تسک‌ها کوچیکن — حدود پونزده دقیقه کار — و پاداش صفر یا یکه بر اساس دو چیز: FAIL_TO_PASS (اون چیزی که خواسته بودن رو درست کردی؟) و PASS_TO_PASS (بدون خراب‌کردن بقیه؟). مثال واقعی‌اش یه باگ تو پروژهٔ Ruby ای fastlane ـه که وقتی پارامترهای اختیاری داده نشن، روی nil متد صدا می‌زنه و می‌ترکه. اصلاح انسانی‌اش دو خطه:

# fastlane/lib/fastlane/actions/zip.rb
-      @include = params[:include]
-      @exclude = params[:exclude]
+      @include = params[:include] || []
+      @exclude = params[:exclude] || []

موقع ارزیابی، هر ویرایشی که مدل روی فایل‌های تست کرده دور ریخته می‌شه (چون دیده شده مدل تست شکست‌خورده رو بی‌سروصدا کامنت می‌کنه یا موکی می‌چپونه که تست رو بی‌معنی کنه)، بعد تست‌پچِ بنچمارک اعمال و کل سوییت اجرا می‌شه. یعنی اینکه مدل چطور به جواب رسیده اهمیتی نداره: اگه تست‌ها پاس بشن برنده‌ایم و هیچ جریمه‌ای برای فرسودن نگهداشت‌پذیری کدبیس وجود نداره. خروجی‌اش می‌شه try/catch دور همه‌چی و کست‌های تنبلی که کل فایدهٔ سیستم تایپ رو از بین می‌برن.

مشکل بنیادی‌تر اینه که تأیید کیفیت مرتبه‌ها سخت‌تر از «تست‌ها پاس شدن؟» ـه: تست تو چند ثانیه جواب می‌ده و RL میلیون‌ها حلقه می‌زنه، ولی تابع هزینهٔ معماری بد با ماه و سال اندازه‌گیری می‌شه. نویسنده می‌گه اگه مدل می‌تونست کد خوب رو از بد تشخیص بده، احتمالاً از اول نسخهٔ خوب رو می‌نوشت؛ RL به یه اوراکل سریع نیاز داره و برای نگهداشت‌پذیری نداریم، پس ایجنت‌های ریویو فقط «کف» رو بالا می‌برن. نسخهٔ عملی خودش: چراغ‌ها رو روشن کن، کدریویو رو برگردون و هم‌راستایی روی نیازمندی و معماری رو جلو بنداز.

نکات کلیدی:

• کارخانهٔ چراغ‌خاموش (بدون خوندن کد توسط انسان) در عمل کدبیس رو فرسوده می‌کنه
• این مشکل مهارتی یا harness نیست؛ ریشه‌اش تو تابع پاداشِ آموزش مدله
• بنچمارک‌ها فقط FAIL_TO_PASS و PASS_TO_PASS رو می‌سنجن، نه کیفیت طراحی
• تست چند ثانیه‌ای بازخورد می‌ده ولی هزینهٔ معماری بد در ماه‌ها و سال‌ها ظاهر می‌شه
• ایجنت‌های ریویوی بیشتر کف کیفیت رو بالا می‌برن، سقف رو نه
• بنچمارک‌های تازه‌ای مثل SWE-Marathon، DeepSWE و Frontier Code تازه دارن سراغ سنجش کیفیت می‌رن
• راه‌حل پیشنهادی: برگردوندن کدریویو و جلو انداختن هم‌راستایی روی نیازمندی و معماری