GitHub در یک پیشنمایش عمومی، نقش Copilot در بررسی کد را یک مرحله جلوتر برده است. مدیران اکنون میتوانند اجازه دهند Copilot یک درخواست ادغام کد (Pull Request) را رسماً تأیید کند و این تأیید، در صورت پیکربندی، یکی از تأییدهای لازم پیش از ادغام باشد.
این قابلیت بهصورت پیشفرض خاموش است و تصمیم درباره فعال شدن آن میتواند در سطح شرکت، سازمان و هر مخزن جداگانه گرفته شود. در سطح مخزن نیز میتوان مشخص کرد تأیید Copilot فقط برای چه مسیرهایی از کد اعتبار داشته باشد.
اهمیت تغییر فقط در بهتر شدن یک ابزار بررسی کد نیست. وقتی تأیید Copilot بتواند یکی از شروط ادغام را برآورده کند، دیگر فقط با یک نظر کمکی روبهرو نیستیم؛ این تأیید میتواند مستقیماً در تصمیمی اثر بگذارد که اجازه ورود کد به شاخه اصلی را میدهد.
دقیقاً چه چیزی تغییر کرده است؟
در بررسیهای Copilot اکنون بخشی وجود دارد که نظر این ابزار را درباره آماده بودن تغییر برای تأیید نشان میدهد. این ارزیابی بهتنهایی فقط جنبه اطلاعرسانی دارد و شرط ادغام را برآورده نمیکند.
اما اگر مدیران قابلیت تأیید را فعال کنند، Copilot میتواند یک تأیید رسمی ثبت کند. در این حالت، GitHub میتواند آن را درست مانند یکی از تأییدهای لازم در قواعد مخزن محاسبه کند.
اختیار فعالسازی نیز مرحلهبهمرحله است. مدیر سطح شرکت میتواند قابلیت را برای همه ببندد یا فقط در اختیار سازمانهای مشخص بگذارد. مدیران سازمان میتوانند آن را برای همه مخازن، مخازن منتخب یا بنا به تصمیم مدیر هر مخزن فعال کنند. در نهایت، مدیر مخزن مشخص میکند Copilot حق تأیید داشته باشد یا نه و آیا تأییدش واقعاً در شرط ادغام اثر بگذارد.
به این ترتیب، GitHub این اختیار را به یک تصمیم صریح مدیریتی تبدیل کرده است؛ روشن کردن بررسی کد Copilot بهتنهایی باعث نمیشود هوش مصنوعی خودکار حق تأیید پیدا کند.
اعتبار تأیید را میتوان به بخشهای مشخصی از کد محدود کرد
مهمترین ابزار برای کنترل ریسک، محدود کردن مسیر فایلهاست. GitHub اجازه میدهد مدیر مخزن حداکثر ۱۵ الگوی مسیر تعریف کند. تأیید Copilot فقط زمانی میتواند در شروط ادغام حساب شود که تمام فایلهای تغییرکرده در محدوده یکی از این الگوهای مجاز باشند.
این امکان برای سازمانها کاربردی است، چون همه بخشهای یک مخزن حساسیت یکسانی ندارند. ممکن است تیم بخواهد تأیید Copilot را برای مستندات تولیدشده، فایلهای پیکربندی کمخطر یا بخشهای مشخصی از کد مجاز کند، اما مسیرهای مربوط به احراز هویت، پرداخت، زیرساخت یا کنترلهای امنیتی همچنان نیازمند بازبینی مستقل انسانی باشند.
در اینجا محدود کردن مسیر فقط یک تنظیم ظاهری نیست. این تصمیم تعیین میکند رأی Copilot در کجا واقعاً قدرت باز کردن مسیر ادغام را دارد.
با هر تغییر تازه، تأیید قبلی بیاعتبار میشود
GitHub برای جلوگیری از باقی ماندن یک تأیید قدیمی روی کدی که بعداً تغییر کرده، همان منطقی را به کار میگیرد که برای بازبین انسانی دارد. اگر بعد از تأیید Copilot، commit جدیدی به درخواست ادغام اضافه شود، آن تأیید کنار گذاشته میشود و برای نسخه جدید کد باید دوباره بررسی انجام شود.
این نکته کوچک اما مهم است. معیار قابل اتکا این نیست که «Copilot یکبار این درخواست را تأیید کرده»، بلکه این است که نسخه فعلی کد پس از آخرین تغییر بررسی و تأیید شده باشد.
برای تیمهایی که پس از هر push بازبینی خودکار اجرا میکنند، این رفتار میتواند بخشی از یک فرایند پیوسته شود. با این حال، هرچه چرخه بررسی، تأیید و ادغام خودکارتر شود، نیاز به یک کنترل مستقل برای بخشهای حساس بیشتر میشود.
تعداد تأییدها دیگر بهتنهایی معنای قبلی را ندارد
خود GitHub در مستنداتش تأکید میکند Copilot تضمین نمیکند همه مشکلات را پیدا کند، ممکن است اشتباه کند و بهتر است خروجی آن با بررسی انسانی تکمیل شود.
در کنار همین هشدار، اکنون میتوان تأیید Copilot را طوری تنظیم کرد که یکی از شروط رسمی ادغام را برآورده کند.
مسئله اصلی همینجاست. بسیاری از تیمها قانونی مانند «حداقل یک تأیید برای ادغام لازم است» را نشانه وجود یک بررسی مستقل میدانند. اگر آن یک تأیید را Copilot بدهد، قانون روی کاغذ همچنان رعایت شده است، اما دیگر نمیتوان فرض کرد همان نوع بررسی مستقلی که قبلاً وجود داشت حفظ شده است.
بنابراین در طراحی حاکمیت، فقط تعداد تأییدها مهم نیست. باید مشخص باشد چه کسی یا چه سامانهای تأیید را داده و آیا آن بازبین از فرایند تولید تغییر مستقل بوده است.
این موضوع زمانی حساستر میشود که خود تغییر کد را نیز یک عامل هوش مصنوعی ساخته باشد. اگر عامل اول کد را تولید کند و Copilot بدون دخالت انسان آن را تأیید کند، سازمان عملاً میتواند به چرخهای برسد که تولید و اجازه ادغام هر دو کاملاً ماشینی باشند.
برای مخازن حساس چه سیاستی منطقیتر است؟
یک راه عملی این است که Copilot را یک بازبین خودکار با اختیار محدود در نظر بگیریم، نه جایگزین عمومی بازبین انسانی.
برای هر مخزن میتوان روشن کرد که Copilot فقط نظر بدهد، اجازه تأیید داشته باشد ولی تأییدش در شرط ادغام حساب نشود، یا فقط در مسیرهای کمریسک اجازه داشته باشد تأیید مؤثر ثبت کند.
در بخشهای حساس بهتر است یک کنترل مستقل باقی بماند؛ برای نمونه تأیید یک توسعهدهنده دیگر، الزام مالک کد از طریق CODEOWNERS، یا یک قاعده فنی جداگانه که Copilot نتواند بهتنهایی آن را برآورده کند.
همچنین باید مشخص باشد پس از هر تغییر چه کسی بازبینی را دوباره درخواست میکند، چه سابقهای برای ممیزی نگه داشته میشود و در صورت استفاده از عاملهای تولیدکننده کد، آیا تأیید کاملاً ماشینی مجاز است یا نه.
این قابلیت هنوز نهایی نیست
امکان تأیید رسمی توسط Copilot فعلاً در مرحله پیشنمایش عمومی است و GitHub صریحاً میگوید ممکن است رفتار آن تغییر کند. در نتیجه بهتر است سازمانها سیاستهای غیرقابل بازگشت را بر پایه رفتار فعلی یک قابلیت آزمایشی بنا نکنند.
با این حال، جهت تغییر روشن است: Copilot دیگر فقط درباره یک تغییر نظر نمیدهد؛ در صورت اجازه مدیران میتواند در همان فرایندی نقش داشته باشد که تصمیم میگیرد کد اجازه ادغام دارد یا نه.
برای تیمهای مهندسی، سؤال مهم این نیست که «آیا Copilot میتواند تأیید کند؟»؛ سؤال مهمتر این است که این تأیید در کدام مخزن و کدام بخش از کد اعتبار داشته باشد و چه نوع بازبینی مستقلی باید در کنار آن حفظ شود.