تقول ملاحظة سجل التغييرات في GitHub بتاريخ 1 سبتمبر إن هناك أمرين منفصلين، والفرق بينهما هو جوهر القصة. أولًا: “تتضمن كل مراجعة كود من Copilot الآن تقييم موافقة في تعليق النظرة العامة.” ثانيًا، وبعدها مباشرة: “لا يُحتسب تقييم الموافقة وحده ضمن متطلبات الدمج.”
الآلية التي يُعتدّ بها
أما الآلية الملزِمة فهي منفصلة: “عند تفعيلها، يمكن لـ Copilot إرسال موافقة تُحتسب ضمن قاعدة الموافقات المطلوبة في المستودع.” وتقول GitHub إن هذه القدرة معطلة افتراضيًا وقابلة للتهيئة على مستوى المؤسسة، والمؤسسة الفرعية، والمستودع — وهي ثلاثة أماكن يمكن للمسؤول تفعيلها فيها. ويمكن لمسؤولي المستودع أيضًا “اختيار مسارات الملفات التي يُسمح لـ Copilot بالموافقة عليها”، وتتصرف الموافقة هنا مثل موافقة الإنسان عند الإبطال: فإذا دُفعت التزامات جديدة بعد موافقة Copilot، تُلغى موافقته كما تُلغى موافقة أي مراجع بشري.
ما الذي تُخطئ فيه الصياغة الشائعة
كلا التبسيطين خاطئ، لكن في اتجاهين متعاكسين. فعبارة “GitHub فعّلت موافقات الذكاء الاصطناعي على طلبات السحب” تُبالغ فيما أُطلق للجميع — إذ إن ما فُعّل على مستوى الجميع هو التقييم، الذي تقول GitHub إنه لا يُحتسب في وقت الدمج. لكن القول إن الأمر “مجرد روبوت مراجعة آخر” يقلل من شأنه بشدة، لأن المسؤول، متى فعّل الإعداد، يستطيع أن يجعل مستودعًا مهيأً لطلب موافقة واحدة يندمج من دون أن يقرأ أي إنسان الفارق. وقائمة السماح لمسارات الملفات هي الكبح البنيوي الوحيد هنا، وهي تُضبط لكل مستودع على حدة.
الضابط الذي يقع عليه هذا الإصدار
ليست الموافقات المطلوبة إعدادًا عاديًا. بل هي الضابط الذي تشير إليه معظم المؤسسات الهندسية للمدققين بوصفه دليلًا على إدارة التغيير وفصل المهام ضمن SOC 2. وهذه هي المرة الأولى التي يمكن فيها لمراجع ذكاء اصطناعي تابع للجهة نفسها أن يفي بهذا الضابط، ولا تتناول ملاحظة سجل التغييرات ما إذا كانت موافقة Copilot ترفع هذا الضابط. هذا السؤال بات مطروحًا الآن أمام كل مؤسسة على المنصة، وسيحسمه المدققون لا GitHub.
أين تتوفر الخدمة
الميزة متاحة في المعاينة العامة عبر خمسة باقات — Copilot Pro وPro+ وMax وBusiness وEnterprise. وتعطيلها افتراضيًا يؤدي هنا دورًا حقيقيًا؛ فالمخاطرة ليست في تاريخ الإطلاق، بل في الربع الأول الذي يفعّلها فيه أحدهم على نطاق واسع لإزالة عائق عن طابور من الأعمال المتأخرة.