أعلنت GitHub في 2 أكتوبر 2026 إمكانية طلب مراجعة شيفرة GitHub Copilot عبر واجهتي REST وGraphQL واختيار مستوى الجهد للطلب. والتغيير متاح عموما ضمن خطط Pro وPro+ وMax وBusiness وEnterprise. وهو يتيح للفريق بدء مراجعة من برنامج نصي أو نظام داخلي، بدلا من الاعتماد حصرا على إجراء يدوي في الواجهة.
طلب المراجعة يمكن أن ينطلق من داخل سير العمل
بحسب سجل التحديثات، اختيار مستوى الجهد في طلب API اختياري، وليس حقلا يجب ضبطه في كل مرة. وبالنسبة إلى فريق يبني أتمتة، يعني ذلك إمكانية دمج الطلب في الموضع الذي يتخذ فيه بالفعل قرار جاهزية التعديل للمراجعة.
يمكن مثلا تصميم عملية داخلية تطلب المراجعة بعد انتهاء الاختبارات الأولية للمشروع. هذا مثال لاستخدام محتمل، وليس تسلسلا يفعل تلقائيا نتيجة التحديث. ولا يزال على المطور تحديد الشروط والصلاحيات وطريقة التعامل مع فشل الطلب.
ويذكر الإعلان نفسه تغييرا أسبق أيضا: منذ 28 سبتمبر، يستخدم Default مستوى Balanced. وقد احتفظ النظام باختيار Lite الصريح السابق. هذان تاريخان لتفصيلين مختلفين؛ فالجديد في 2 أكتوبر هو الوصول عبر API، ولا ينبغي عرض تغيير الإعداد الافتراضي وكأنه دخل حيز التنفيذ آنذاك فقط.
وعند تصميم الأتمتة، يستحسن تحديد ما سيحدث إذا تأخرت مراجعة أو فشلت. يمكن للفريق إظهار حالة واضحة للمطور وترك قرار المتابعة للجهة المسؤولة. ولا ينبغي تفسير صمت عملية آلية على أنه تأكيد لعدم وجود مشكلات في الشيفرة.
عمق المراجعة والتشغيل التلقائي ليسا الإعداد نفسه
تصف وثائق GitHub مستوى Lite بأنه مراجعة عادية، بينما يستهدف Balanced تحليلا أعمق للمنطق المعقد والشيفرة الحساسة أمنيا والتغييرات الممتدة عبر الخدمات. ويظهر خيار Max بعلامة Coming soon ولا يزال غير متاح. اسم خطة Max لا يجعل مستوى المراجعة Max متاحا.
وتقول GitHub إن Balanced يستهلك مزيدا من أرصدة الذكاء الاصطناعي، وقد يستهلك دقائق أكثر قليلا من GitHub Actions. لذلك ينبغي فحص الإعداد الافتراضي ضمن ميزانية العمل، دون افتراض أن العمق الإضافي لا يغير الاستهلاك.
تفصل الوثائق بين اختيار مستوى الجهد وتفعيل المراجعات التلقائية. فإيقاف المراجعة التلقائية لا يمحو مستوى الجهد المختار للمراجعات اليدوية. كذلك قد تنشأ الطلبات التلقائية من إعدادات المستخدم أو قواعد المستودع والمؤسسة؛ ولا يلغي الإعداد الشخصي بالضرورة قاعدة مؤسسية.
للفريق الراغب في تجربة API، البداية المناسبة مستودع اختبار مع تعديل صغير ونتيجة متوقعة. تأكدوا من طلب المراجعة فعليا، وافحصوا المستوى الذي جرت به، وراجعوا الملاحظات قبل توسيع الاستخدام. نجاح استدعاء API يؤكد تلقي النظام طلبا، لكنه لا يثبت صحة الشيفرة. وتبقى مسؤولية تقرير جاهزية التعديل للدمج جزءا من عملية التطوير.