‏کارخونه نرم‌افزار با ایجنت‌های کدنویسی موازی

نویسنده یه software factory رو توضیح می‌ده، یعنی یه حلقه خودکار که issueها رو از بک‌لاگ (معمولاً GitHub Issues) برمی‌داره، می‌ده به ایجنت‌های کدنویسی، نتیجه رو جدا بررسی می‌کنه و آخرش یه آدم تصمیم می‌گیره مرج بشه یا نه. ساده‌ترین نسخه‌ش یه ایجنته که یه تیکت رو می‌خونه، fix می‌نویسه، تست اضافه می‌کنه و PR باز می‌کنه. این برای یه تیکت خوب جواب می‌ده، ولی وقتی بخوای ده تا ایجنت رو با هم اجرا کنی، مشکل‌ها شروع می‌شن.

به گفته نویسنده، چند تا خرابی تقریباً همون اول پیدا می‌شن. اگه همه ایجنت‌ها تو یه پوشه کار کنن، تغییرهاشون قاطی می‌شه؛ تو یه تست، سه ایجنت یه commit ساختن که شش تا فایل از سه issue بی‌ربط رو عوض کرده بود. راه‌حل اینه که هر ایجنت sandbox جدای خودش رو داشته باشه، یعنی یه کپی جدا از کد روی یه ماشین جدا. دو تا ایجنت هم ممکنه یه issue رو با هم بردارن، که با گذاشتن لیبل «claimed» روی issue حل می‌شه.

مشکل مهم‌تر اینه که نمی‌شه به گزارش خود ایجنت از تست‌هاش اعتماد کرد. ایجنت‌ها هر بار گفتن تست‌ها پاس شده، حتی وقتی یه verifier مستقل دید تست‌ها fail می‌شن. یه مشکل دیگه هم اینه که مدل‌ها فقط APIهایی رو می‌شناسن که تو داده آموزشی‌شون بوده، پس باید یه ابزار برای دیدن مستندات به‌روز داشته باشن. برای سیل PRها هم یه قانون سفت گذاشته شده: فکتوری فقط PR باز می‌کنه و فقط آدم مرج می‌کنه.

طراحی پیشنهادی پنج مرحله داره که هر کدوم تو یه sandbox تازه اجرا می‌شه: Triage که می‌بینه issue به‌اندازه کافی روشن هست یا نه، Worker که کد و تست رو می‌نویسه، Verifier که از یه snapshot تمیز بالا میاد و کل تست‌ها رو خودش دوباره اجرا می‌کنه، Reviewer که diff رو خط به خط می‌خونه، و Integrator که PRها رو یکی‌یکی مرج می‌کنه. تو یه اجرا روی یه پروژه URL shortener با ده issue، مرحله triage یه issue عمداً مبهم رو درست رد کرد.

نویسنده یه مثال جالب از ارزش reviewer میاره: تست‌های worker پاس شدن، verifier هم تأیید کرد و حتی یه تست مخفی هم پاس شد، ولی reviewer باز PR رو رد کرد. دلیلش یه race condition بود، یعنی وقتی دو تا لینک تو یه میلی‌ثانیه ساخته می‌شدن، ترتیب لیست اشتباه برمی‌گشت. تست worker این باگ رو نگرفته بود چون داده‌هاش از قبل مرتب بودن. یعنی تست فقط چیزی رو چک می‌کنه که بهش فکر کردی.

حتی با sandbox جدا هم conflict پیش میاد، چون همه ایجنت‌ها از یه snapshot شروع می‌کنن و فایل‌های مشترک مثل فایل تست رو عوض می‌کنن. تو اون اجرا، از نه PR تأییدشده، هفت تا موقع مرج conflict خوردن. Integrator این‌ها رو یکی‌یکی مرج می‌کنه، conflictها رو طوری حل می‌کنه که هیچ طرفی گم نشه و بعد هر مرج تست‌ها رو دوباره اجرا می‌کنه. نویسنده می‌گه برای یه باگ تنها این همه دردسر نمی‌ارزه، ولی برای بک‌لاگ بزرگ می‌ارزه.

نکات کلیدی:

• خط تولید پنج مرحله داره: Triage، Worker، Verifier، Reviewer و Integrator، هر کدوم تو sandbox جدا.
• گزارش «تست‌ها پاس شد» از خود ایجنت قابل اعتماد نیست و باید یه verifier مستقل تست‌ها رو دوباره اجرا کنه.
• یه reviewer که diff رو می‌خونه یه race condition تو ترتیب لینک‌ها رو گرفت که تست‌ها ندیده بودن.
• از نه PR تأییدشده، هفت تا به‌خاطر فایل تست مشترک conflict خوردن.
• هزینه توکن برای ده issue چند دلار بود و هزینه sandbox کسری از یه سنت.
• ایجنت‌ها فقط PR باز می‌کنن و مرج همیشه دست آدمه.