خبر تأییدشده
GitHub در ۲۸ اکتبر ۲۰۲۶ دسترسی عمومی Copilot Fusion را اعلام کرد. این قابلیت به‌جای انتخاب دستی یک مدل، مدل‌های مورد نیاز هر کار را انتخاب و هماهنگ می‌کند. سه سطح Standard، High و Max در دسترس است و اجرا می‌تواند با یک مدل، زنجیره ارتقای پاسخ یا بازبینی پاسخ توسط مدل دیگر انجام شود. طبق اطلاعیه، Fusion تنها از مدل‌های مجاز در سیاست سازمان استفاده می‌کند. هزینه براساس مدل‌های مصرف‌شده محاسبه می‌شود و تخفیف اعلام‌شده موقتی است. پشتیبانی اولیه شامل VS Code، برنامه Copilot، خط فرمان Copilot و IDEهای JetBrains است. این خبر، اعلام یک مدل بنیادی جدید نیست؛ یک لایه تصمیم‌گیری روی مدل‌هاست.
تحلیل مستقل IROSG
ارزش این تغییر برای تیم توسعه در جایی روشن می‌شود که انتخاب مدل خودش به یک کار روزمره تبدیل شده باشد. برنامه‌نویس ممکن است برای یک اشکال دشوار مدل پرهزینه‌ای انتخاب کند و سپس اصلاح‌های ساده را نیز با همان تنظیم ادامه دهد. پیشنهاد ما این است که ارزیابی Fusion از مجموعه‌ای از کارهای واقعی شروع شود: تغییر کوچک رابط، رفع خطای تست، بررسی منطق پیچیده و اصلاح مستندات. هر دسته باید جداگانه سنجیده شود تا میانگین کلی، شکست یک سناریوی حساس را پنهان نکند.
عدد مناسب برای تصمیم‌گیری فقط هزینه هر درخواست نیست. هزینه رسیدن به تغییر پذیرفته‌شده، زمان انتظار، تعداد اصلاح‌های انسانی و میزان دوباره‌کاری بعد از ادغام اهمیت بیشتری دارند. پاسخ ارزان که چند بار نیازمند بازنویسی باشد لزوماً اقتصادی‌تر نیست؛ پاسخ گران نیز اگر اختلاف کیفیت آن در پروژه دیده نشود توجیه ندارد. یک آزمایش محدود با ورودی‌های یکسان و معیار پذیرش مشخص، مقایسه روشن‌تری از انتخاب براساس نام مدل فراهم می‌کند.
از نگاه اداره سازمان، مسیریابی خودکار باید با قابلیت توضیح‌دادن صورت‌حساب همراه باشد. بهتر است تیم پیش از فعال‌سازی گسترده مشخص کند چه کسی می‌تواند سطح تلاش را تغییر دهد، چه نوع داده‌ای در این مسیر مجاز است و گزارش مصرف به کدام پروژه منتسب می‌شود. این‌ها توصیه تحریریه برای طراحی آزمایش هستند و به معنای ادعای وجود همه این کنترل‌ها در محصول نیستند.
نکته دیگر، ناپایداری ذاتی یک ارزیابی مقطعی است. مدل‌ها، سیاست مسیریابی و نوع کار تیم می‌توانند تغییر کنند. بنابراین نتیجه امروز بهتر است به‌عنوان خط مبنا ثبت شود و پس از تغییر مهم در ابزار یا پروژه دوباره بررسی شود. برای کارهایی مانند مهاجرت پایگاه داده، موفقیت مدل در نوشتن کد کافی نیست؛ آزمون بازگشت، کنترل خروجی و بازبینی مسئول فنی همچنان بخشی از پذیرش تغییر است.
معیار عملی پیشنهادی ما این است که Fusion زمانی به پیش‌فرض تیم تبدیل شود که کیفیت خروجی پذیرفته‌شده حفظ شود و کاهش قابل اندازه‌گیری در هزینه یا زمان ایجاد کند. در غیر این صورت، حفظ انتخاب دستی برای بعضی دسته‌های کار تصمیم معقولی است. انعطاف در انتخاب ابزار، زمانی ارزش دارد که بتوان نتیجه آن را با شواهد پروژه توضیح داد.
