چطور از گلوگاه ریویو کد بیرون بیای
هوش مصنوعیخلاصهٔ کاملتر
خبرنامهٔ PostHog میگه ایجنتها دارن سریعتر از هر آدمی کد مینویسن و طبیعتاً ریویو کد تبدیل شده به گلوگاه. راهحل بدیهی اینه که آدمها سریعتر ریویو کنن، ولی به گفتهٔ نویسنده جواب هوشمندانهتر اینه که تا میتونی کمتر کد ریویو کنی و خودتو از حلقه بکشی بیرون. تو این مقاله چهار تغییر رو از مهندسهای PostHog جمع کردن.
اولی اینه که ایجنتها بهجای تو کد رو ریویو کنن. نکتهٔ کلیدی اینه که ایجنتی که کد رو نوشته نباید ریویوکنندهٔ همون کد باشه، چون مدلها معمولاً نقطهکورهای خودشون رو نمیبینن. بهتره چند ایجنت با دستورالعمل، هدف و حتی مدل و ارائهدهندهٔ متفاوت داشته باشی تا شکاف بیشتری پوشش داده بشه.
تو مثال مقاله، یه اسکیل به اسم qa-swarm چهار ریویوکننده رو همزمان بالا میآره: یکی دنبال مسائل فنی مثل امنیت و دیتابیس و پرفورمنس میگرده، یکی مخصوص آدیت امنیتی و تزریق SQL و پرامپته، و بقیه با لنز شخصی یا اکستریم پروگرمینگ نگاه میکنن. بعدش review-triage نتیجهها رو سه دسته میکنه: actionable که فیکس و پوش میشه، nit که همونجا بسته میشه، و ambiguous که برای آدم کنار گذاشته میشه.
هزینهش هم کم نیست؛ یکی از مهندسها میگه حدود ۶۰٪ مصرف توکنش صرف خودکارکردن همین کارهای تکراری ریویو و CI میشه و یه دلارش هم براش پشیمونی نداشته. اگه اجرای چند ایجنت موازی برای تیمت گرون درمیاد، مقاله پیشنهاد میده سراغ طراحیهای تکایجنتی بری.
دومی سپردن «بچهداری» PR به یه حلقهٔ خودکاره: مانیتور کردن CI، اجرای دوبارهٔ تستهای فلیکی، چک کردن نوتیفیکیشن کامنتها و بهروز نگهداشتن برنچ. اینا کارهاییان که مدام تمرکزت رو میشکنن ولی هیچکدوم واقعاً به قضاوت تو نیاز ندارن.
سومی یه استمپر خودکار برای تأییدهای کمریسکه. مهندسها یه لیبل stamphog روی PR میذارن و ایجنت چندتا گیت قطعی رو چک میکنه: وضعیت PR (بدون کانفلیکت و بدون درخواست تغییر)، شعاع تأثیر بر اساس یه لیست کلیدواژهٔ حساس مثل auth و secrets و billing، اندازهٔ دیف زیر ۵۰۰ خط و ۲۰ فایل، و یه چک سادهٔ مدل برای مشکلهای آشکار. اگه رد نشه، با یکیدو جمله دلیل و سطح ریسک به آدم مناسب ارجاع میده.
نتیجهش به گفتهٔ مقاله اینه که این ایجنت تو یه فصل، تأیید نهایی حدود یکسوم PRهای مرجشده تو ریپوی اصلی رو خودش زده و فقط تو یه ماه ۱۶۰۰ تا PR رو مستقل بسته — یعنی ۱۶۰۰ وقفهٔ کمتر برای مهندسها تو اسلک.
چهارمی شاید مهمترینشون باشه: تأیید با مشاهده، نه با استدلال. ایجنتها خوب توضیح میدن چرا کدشون کار میکنه و توضیحشون هم قانعکنندهست، ولی زیاد پیش میاد که غلط باشه. راهحل پیشنهادی اینه که ایجنت کار رو به یه استک از PRهای کوچیک و تکمنظوره بشکنه تا هر دیف مستقل قابل اجرا و قابل دیدن باشه؛ بعد از پایین به بالا مرج میکنی و هر لایه فقط روی رفتاری سوار میشه که قبلاً با چشم تأیید شده.
نکات کلیدی:
- ایجنتی که کد رو نوشته نباید ریویوکنندهٔ همون کد باشه
- چند ریویوکننده با مدل و دستورالعمل متفاوت، شکافهای بیشتری رو پوشش میدن
- یافتهها رو به actionable / nit / ambiguous تقسیم کن و فقط ambiguousها رو خودت ببین
- تأیید PRهای کمریسک رو با گیتهای قطعی (اندازهٔ دیف، کلیدواژههای حساس) به ایجنت بسپار
- کد رو موقع اجرا ببین؛ استدلال ایجنت جای مشاهده رو نمیگیره
- کار بزرگ رو به استک PRهای کوچیک بشکن تا هر تیکه مستقل قابل تأیید باشه
