کارخونهٔ نرم‌افزار با AI: ایجنت‌ها می‌سازن، آدم‌ها تصمیم می‌گیرن
هوش مصنوعیخلاصهٔ کامل‌تر
تو این مقاله دو مدل از توسعهٔ نرم‌افزار با ایجنت‌های کدنویسی مقایسه شده. اولی dark factory هست، یعنی یه سند کلی مثل توضیح یه release رو به سیستم می‌دی و انتظار داری خودش کارو تقسیم کنه، بسازه، تست کنه و بدون دخالت آدم بفرسته production. این ایده از مفهوم «پنج سطح خودمختاری» Dan Shapiro میاد که سطح پنجش کلاً فرمون رو حذف می‌کنه.
به گفتهٔ نویسنده، مشکل خیلی قبل‌تر از محدودیت توانایی مدل پیدا میشه. مدل‌ها هرچی تو کدنویسی بهتر می‌شن، به همون اندازه تو فهمیدن نیت آدم بهتر نمی‌شن. آدم‌ها معمولاً بار اول دقیق نمی‌گن چی می‌خوان و تقریباً هیچ‌وقت نمی‌گن کدبیس رو چطور می‌خوان نگه دارن. dark factory مجبوره این خلأها رو با حدس پر کنه و حدس زدن تو ده‌ها تیکت، به نرم‌افزاری می‌رسه که کار می‌کنه ولی از چیزی که خواسته شده بود فاصله گرفته. مشکل دوم maintainability هست: بدون نظارت آدم، کدبیس پخش و شلوغ میشه، تست‌های خودش رو پاس می‌کنه ولی نگهداریش سخت‌تر و سخت‌تر میشه.
AI software factory همون حلقهٔ اصلی رو نگه می‌داره، یعنی یه تیکت می‌ره داخل و یه pull request میاد بیرون. فرقش تو scope هست، نه توانایی. قبل از شروع، یه آدم سند برنامه‌ریزی مثل PRD یا architecture doc رو می‌نویسه و مشخص می‌کنه چی تو این release هست و چی نیست. بعد کارخونه سند رو به تیکت می‌شکنه، وابستگی‌ها رو مشخص می‌کنه و ایجنت‌ها رو از حلقهٔ build/validate/review رد می‌کنه. آخرش هم آدم‌ها خروجی رو بازبینی می‌کنن.
برای scope دو تا قاعده هست: تو پروژه‌های greenfield (پروژهٔ از صفر) اولین release باید یه proof of concept باشه، نه کل اپ. تو پروژه‌های brownfield (روی کدبیس موجود) هم باید یه epic کوچیک باشه. هدف منطقی یه epic هست که به ۱۰ تا ۲۰ تیکت شکسته بشه. نویسنده تأکید می‌کنه که بخش «خارج از scope» به همون اندازهٔ لیست فیچرها مهمه، چون جلوی اینو می‌گیره که کارخونه خودش برداشتش از کار رو گسترش بده.
یکی از ایده‌های مهم holdout scenario هست، یعنی تستی که آخر کار اجرا میشه ولی ایجنت سازنده هیچ‌وقت نمی‌بینتش. ایجنت‌ها دنبال هر سیگنالی که ببینن بهینه می‌شن. اگه تست‌ها رو از قبل بدونن، کدی می‌نویسن که فقط همون تست‌ها رو پاس کنه، که یه جور overfitting هست. مخفی نگه داشتن تست‌ها مجبورشون می‌کنه نیت واقعی تیکت رو پیاده کنن. نویسنده می‌گه این کار حتی بیرون از یه کارخونهٔ کامل هم یه راه ساده برای کم کردن رفتار تست‌محور ایجنت‌هاست.
شکستن تیکت‌ها هم فقط تیکه‌تیکه کردن سند نیست. باید معلوم بشه کدوم تیکت‌ها می‌تونن موازی جلو برن، کدوما به هم وابسته‌ن و چطور با برچسب‌هایی مثل GitHub label ترتیب درست به حلقهٔ خودکار گفته بشه. به نظر نویسنده، حتی اگه کارخونهٔ کامل نسازی، جدا کردن برنامه‌ریزی از اجرا، epicهای کوچیک، مرز صریح خارج از scope و مخفی کردن تست‌ها هر کدوم به‌تنهایی ورک‌فلوی agentic رو بهتر می‌کنن.
نکات کلیدی:
- dark factory از یه سند کلی کل اپ رو بدون دخالت آدم تا production می‌بره و معمولاً شکست می‌خوره.
- گلوگاه اصلی انتقال نیت آدم به مدله، نه توانایی کدنویسی مدل.
- software factory هر بار فقط یه release یا epic رو جلو می‌بره و برنامه‌ریزی و بازبینی دست آدم می‌مونه.
- هر epic بهتره به حدود ۱۰ تا ۲۰ تیکت با scope و خارج از scope مشخص شکسته بشه.
- holdout scenario تستیه که ایجنت سازنده نمی‌بینه و جلوی overfitting روی تست‌ها رو می‌گیره.
- maintainability کد یکی از دلیل‌های اصلی نگه داشتن بازبینی انسانی تو این فراینده.
