بازبینی Copilot دیگر نظر مجانی کنار PR نیست؛ ظرفیت CI است

بخش مفید اعلام GitHub، خود جزئیات صورتحساب نیست. اذعان معماری پشت آن است: بازبینی کد Copilot یک مولد کامنت کنار pull request نیست. بار کاری ایجنتی است که روی زیرساخت GitHub Actions اجرا می‌شود، زمینه وسیع‌تری از مخزن می‌خواند، و ظرفیت واقعی رانر را مصرف می‌کند.

طبق همان اعلام، از اول ژوئن ۲۰۲۶ این تمایز برای مخزن خصوصی عملی می‌شود. هر بازبینی هم از مدل اعتبار AI صورتحساب می‌گیرد و هم از سهمیه دقیقه Actions plan موجود کم می‌کند. مخزن عمومی به همان شکل تحت تأثیر نیست، ولی بیشتر تیم پروداکشن در مخزن خصوصی زندگی می‌کند. برای آن‌ها بازبینی AI از «بازخورد اضافه قشنگ» به همان سطل عملیاتی رفته که تست، استقرار پیش‌نمایش، اسکن امنیتی، و اتوماسیون انتشار نشسته‌اند. تاریخ را به‌عنوان اجبار تقویمی تیم خودت چک کن؛ اصل مهندسی به تاریخ بند نیست.

هزینه انتزاعی، عادت بد می‌سازد

تا وقتی هزینه انتزاعی بود، توسعه‌دهنده دکمه را می‌زد، دستیار کامنت می‌گذاشت، و تیم با حس قضاوت می‌کرد: مفید، پرسروصدا، غلط، گاهی عالی. وقتی بازبینی از همان بودجه Actions می‌آید که CI استفاده می‌کند، سؤال عوض می‌شود. دیگر این نیست که Copilot گاهی مسئله پیدا می‌کند یا نه. این است که این بازبینی به اندازه همان ظرفیت محدودی که برای بیلد و تست می‌خواهیم می‌ارزد یا نه.

سؤال سالم‌تری است. سازمان در پذیرش ابزاری که سر نقطه استفاده مجانی به نظر می‌رسد بد عمل می‌کند. همه‌جا روشن می‌کند، نقطه ضعف را دیر می‌بیند، و بعد سیاست می‌گذارد. فشار قیمت این‌جا خودکار بد نیست. تیم را وادار می‌کند تصمیم بگیرد بازبینی AI در سیستم تحویل کجا می‌نشیند، به‌جای اینکه نویز پس‌زمینه نامحدود باشد.

مثل یک job دیگر CI با آن رفتار کن

job جدی CI سیاست اجرا، مالک، بودجه، و حالت شکست دارد. بازبینی Copilot هم باید همین‌ها را داشته باشد. اگر روی هر جهش وابستگی ریز، هر تغییر فایل تولیدشده، هر غلط تایپی سند، و هر PR پیش‌نویس آزمایشی اجرا شود، دستیار نگرفته‌ای. مسیر خرج با ارزش نامعلوم اضافه کرده‌ای.

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

این‌جا تظاهر را کنار بگذار. بازبینی AI جایگزین دروازه کیفیت موجود نیست. type checker نیست، test runner نیست، لینتر نیست، و اسکنر امنیتی نیست. در بهترین حالت بازبین زمینه‌ای است که شاید مورد جاافتاده، رانش معماری، فرض مشکوک، یا تغییر گیج‌کننده را ببیند. اگر ابزار قطعی ضعیف باشد، گذاشتن ایجنت رویش معمولاً مسئله واقعی را قایم می‌کند.

بودجه به ورودی مهندسی نیاز دارد

GitHub توصیه می‌کند قبل از تغییر ژوئن، مصرف Actions، بودجه، متریک استفاده Copilot، متریک Actions، و گزارش صورتحساب را مرور کنید. این کار را فقط به مالی یا ادمین پلتفرم نسپار. کسی که حجم PR، ریسک مخزن، CI ناپایدار، و گلوگاه بازبینی را می‌فهمد باید باشد. جواب فقط «سقف را بالا ببر» یا «خاموش کن» نیست.

با اندازه‌گیری شروع کن، حتی تقریبی. مخزن خصوصی در هفته چند PR باز می‌کند؟ چند تا پیش‌نویس است؟ چند تا خودکار است؟ چند تا به سرویس پرریسک می‌خورد؟ کامنت Copilot چند بار به تغییر واقعی کد منجر می‌شود و چند بار رد می‌شود؟ اگر تیم حتی تقریبی جواب ندارد، آماده اجرای پیش‌فرض روی همه‌چیز نیست.

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

رانر خودمیزبان روزنه نیست

اعلام می‌گوید بازبینی می‌تواند روی رانر خودمیزبان و رانر میزبانی‌شده بزرگ‌تر هم برود، با صورتحساب متفاوت از رانر استاندارد. این دریچه فرار نیست. سؤال ظرفیت را جای دیگری می‌برد. زیرساخت خودمیزبان هنوز هزینه، صف، نگهداری، انزوا، و پیامد امنیتی دارد.

برای خیلی از تیم‌ها رانر میزبانی‌شده پیش‌فرض درست می‌ماند چون بار عملیاتی کم است. برای سازمان بزرگ با الزام انزوا یا حجم خیلی بالا، خودمیزبان می‌تواند معنی داشته باشد. تصمیم را مثل هر تصمیم زیرساخت CI بگیر: توان عملیاتی، مرز امنیتی، مالک نگهداری، و هزینه کل. نه چون کلمه AI بار را متفاوت جلوه داده.

جهت محصول بزرگ‌تر از فاکتور است. ابزار AI دارد جزو بستر تحویل نرم‌افزار می‌شود. روی رانر اجرا می‌شود، در گزارش مصرف می‌آید، بودجه می‌خواهد، و سیاست لازم دارد. واکنش مهندسی دلخوری از مصرف منابع نیست. اتوماسیون مفید همیشه منبع مصرف می‌کند. مرز منبع را صریح کن، جایی که به درد می‌خورد تصمیم بگیر، و با همان انضباط بقیه jobهای CI سیم‌کشی کن.

برای تیم کوچک شاید یعنی بازبینی دستی روی PR پرریسک و هشدار بودجه Actions. برای تیم بزرگ‌تر یعنی سیاست سطح مخزن، رفتار جدا برای پیش‌نویس، رفتار جدا برای به‌روزرسانی وابستگی، و مرور متریک Copilot کنار دقیقه بیلد. برای تیم پلتفرم یعنی دستیار حالا جزو برنامه ظرفیت CI است.

بازبینی AI را زیرساخت نامرئی نکن. اگر می‌ارزد، جای عمدی در سیستم تحویل بده. اگر پرسروصداست، محدودش کن. اگر گران است، با نقص و وقتی که واقعاً از بازبینی انسانی کم می‌کند بسنج. تغییر صورتحساب مفید است چون شکل پنهان ابزار را دیدنی می‌کند: این یک بار CI است و باید مثل همان اداره شود.

پیش‌نویس و ربات را از مسیر پیش‌فرض جدا کن

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

به‌روزرسانی وابستگی را هم جدا کن. اگر از قبل چک قطعی و شاید یک ایجنت باریک برای Dependabot داری، بازبینی عمومی Copilot روی همان PR اغلب تکراری است. استثنا را بنویس، نه اینکه همه‌چیز را خاموش کنی. استثنای نوشته‌نشده هفته بعد فراموش می‌شود و یا همه‌جا روشن می‌ماند یا از فرط سروصدا همه‌جا بسته می‌شود.

شکست این job را مثل شکست تست تعریف نکن. کامنت غلط نباید merge را بلوکه کند، مگر اینکه تیم عمداً این را بخواهد و هزینه اشتباه را پذیرفته باشد. حالت شکست سالم این است: job اجرا نشد یا بودجه تمام شد، و نویسنده می‌داند بازبینی AI غایب است نه اینکه سکوت یعنی تأیید. سکوت ابزار و تأیید ابزار را قاطی نکن.

اگر این سه سیاست را در مخزن بنویسی، صورتحساب ژوئن غافلگیری نمی‌شود. اگر ننویسی، اولین صورتحساب به‌جای تو سیاست را تنظیم می‌کند، و آن سیاست معمولاً یا خاموشی کامل است یا ادامه عادت گران.