‏تیم Kiro Crew چطور هزار PR در هفته رو بدون خراب‌کاری مرج می‌کنه

تیم Kiro Crew قبلاً گفته بود سه مهندس با کمک ایجنت‌ها تو یه هفته هزارتا PR مرج کردن. تو این پست سؤال اصلی رو این‌طوری مطرح می‌کنن: آدم چطور می‌تونه مسئول کدی باشه که نه خودش نوشته و نه خط به خط خونده؟ جواب نویسنده‌ها اینه که حتی قبل از AI هم اعتماد از ریویوی دستی نمی‌اومد، از تست‌های خودکار تو pipeline انتشار می‌اومد. پس سؤال درست اینه که چطور تست‌ها و چک‌هایی بسازیم که بیشتر از چشم خودمون بهشون اعتماد داشته باشیم. این تیم حدود ۲۰ درصد وقتشو صرف همین زیرساخت می‌کنه.

اولش سعی کردن همه تغییرات رو دستی ریویو کنن که کمتر از یه روز دووم آورد. بعد یه قانون سخت گذاشتن که هر کامنت بات ریویو، هر چقدر هم کم‌اهمیت، باید قبل از مرج حل بشه. نتیجه شد یه چرخه بی‌پایان: پنج‌تا کامنت رو درست می‌کردی و چهارتا کامنت جدید روی کدی که اصلاً دست نزده بودی می‌اومد. راه‌حل این بود که کامنت‌ها رو بر اساس شدت دسته‌بندی کنن (فقط موارد blocking تو همون PR درست بشه و بقیه بشه issue بعدی) و یه ریویوئر دوم اضافه کنن که چند دور اسکن می‌کنه تا همه کامنت‌های واقعی رو یه‌جا بده.

با انتقال پروژه به GitHub، هر PR خودکار build، تست واحد و تست end-to-end می‌گیره و یه test pod از فیچرها اسکرین‌شات و ویدیو ضبط می‌کنه. ریویو هم بر اساس نقش تقسیم شد: ریویوئر طراحی، ریویوئر first-principles (یعنی می‌پرسه آیا ریشه مشکل حل شده و کاربر واقعاً لازمش داره)، ریویوئر UX، و ریویوئرهایی از خانواده‌های مدل دیگه، چون مدلی که کد هم‌خانواده خودشو ریویو می‌کنه همون نقاط کوری رو داره. یه finding فقط وقتی blocking حساب می‌شه که محل دقیق، شاهد، trigger و پیامد داشته باشه.

مرحله بعد بستن حلقه بود. یه skill به اسم prepare-pr ساختن که PR رو تا سبز شدن جلو می‌بره و برای این کار به یه چک واحد به اسم PR Readiness تکیه می‌کنه. این چک نتیجه بیش از ۸۰ چک رو تو یه حکم خلاصه می‌کنه و یعنی «همه اجرا شدن و پاس شدن»، نه فقط «هنوز چیزی قرمز نشده». PRهای ساده خودکار تأیید و مرج می‌شن و برای بقیه، ایجنت توضیح PR رو با قالب ثابت و حتی دیاگرام می‌نویسه تا آدم تو چند ثانیه بفهمه چی عوض شده.

بعد از مرج هم کار تموم نمی‌شه: قبل از هر انتشار یه ایجنت اپ واقعی رو نصب می‌کنه و مسیرهای اصلی رو اجرا می‌کنه، چک‌های امنیتی ساعتی و روزانه روی کد مرج‌شده اجرا می‌شه و ریفکتور دوره‌ای هم انجام می‌دن. نویسنده‌ها می‌گن دو مشکل بزرگ داشتن: over-engineering (یعنی هر دور ریویو یه مکانیزم جدید اضافه می‌کرد تا یه فیکس ده‌خطی شد یه زیرسیستم) و افراط تو فیکس‌های امنیتی. برای اولی یه retrospective تو حلقه گذاشتن که رشد بی‌دلیل تغییر رو تشخیص می‌ده و یه ایجنت دوم به اسم conductor که خودش تصمیم اول رو می‌گیره. قانون امنیتی‌شون هم ساده‌ست: مشکل واقعی و قابل دسترس کاربر رو با کوچیک‌ترین تغییر درست کن.

نکات کلیدی:

• Kiro Crew با سه مهندس و ایجنت‌ها هفته‌ای ۱۰۰۰ PR مرج می‌کنه و حدود ۲۰٪ وقت تیم صرف زیرساخت اتوماسیون می‌شه.
• پوشش تست بالای ۹۰ درصده و هدفشون رسیدن به ۱۰۰ درصده.
• کامنت‌های ریویو بر اساس شدت دسته‌بندی می‌شن و فقط موارد blocking جلوی مرج رو می‌گیرن.
• ریویو بین نقش‌های طراحی، first-principles و UX و چند خانواده مدل مختلف تقسیم شده.
• چک PR Readiness نتیجه بیش از ۸۰ چک CI رو تو یه حکم واحد جمع می‌کنه و skill prepare-pr تا سبز شدنش حلقه رو ادامه می‌ده.
• workflowها، promptهای ریویو و skill prepare-pr تو مخزن متن‌باز KiroCrew روی GitHub هستن.