أعلنت GitHub في 17 يوليو 2026 تحديثًا جديدًا يجعل مقاييس استخدام GitHub Copilot أكثر دقة وارتباطًا بما يحدث فعليًا داخل المستودعات، بعد أن أضافت تقارير على مستوى كل repository بدل الاكتفاء بنظرة عامة على مستوى المؤسسة أو المنظمة فقط. وبالتزامن مع ذلك، وسّعت الشركة واجهة التقارير نفسها لتُظهر نشاط تطبيق GitHub Copilot app داخل واجهة البرمجة، وهو ما يمنح فرق التطوير والإدارة صورة أوضح عن أين يُستخدم Copilot فعلًا، وكيف يستهلك الجلسات والطلبات والرموز.

هذا التحديث يبدو إداريًا للوهلة الأولى، لكنه عملي جدًا في لحظة أصبح فيها الإنفاق على أدوات الذكاء الاصطناعي موضع متابعة دقيقة داخل الفرق الهندسية. فبعدما تحولت الفوترة في كثير من الأدوات إلى نماذج أقرب للاستهلاك الفعلي، لم يعد يكفي أن تعرف عدد المستخدمين النشطين فقط، بل تحتاج إلى معرفة أي المستودعات تستفيد من Copilot، وأين تتحول المراجعات والاقتراحات إلى طلبات سحب فعلية، وأي جزء من الاستخدام يأتي من التطبيق نفسه لا من بيئة التطوير فقط.

ما الجديد في مقاييس استخدام GitHub Copilot؟

بحسب GitHub Changelog الرسمي، أصبح Copilot usage metrics REST API يدعم نقطتي وصول جديدتين تعرضان تقريرًا يوميًا على مستوى المستودع. هذه التقارير تُظهر نشاط طلبات السحب المرتبط بكل من Copilot coding agent وCopilot code review، سواء على مستوى المؤسسة أو المنظمة. عمليًا، هذا يعني أن مسؤولي المنصات والفرق الهندسية لم يعودوا مضطرين للاعتماد على أرقام مجمعة قد تخفي أماكن التأثير الحقيقي، بل يمكنهم رؤية أي المستودعات تشهد إنشاء أو دمج طلبات سحب بمساهمة مباشرة من Copilot.

ويشمل التقرير اليومي عدد طلبات السحب التي أنشأها Copilot coding agent وتم دمجها، إضافة إلى نشاط Copilot code review مع تفصيلات خاصة باقتراحات المراجعة. هذه النقلة تمنح الشركات قدرة أفضل على الربط بين استهلاك الأداة وبين أثرها العملي داخل دورة التطوير نفسها، بدل قياس الاستخدام بوصفه عدد جلسات أو محادثات فقط.

لماذا يهم هذا التحديث لمديري الهندسة والفرق التقنية؟

القيمة الحقيقية هنا أن مقاييس استخدام GitHub Copilot لم تعد مجرد لوحة تبني عامة، بل أصبحت أقرب إلى طبقة ملاحظة تشغيلية تساعد الفريق على اتخاذ قرارات فعلية. فإذا كان لديك عشرات المستودعات، فلن يكون مهمًا فقط معرفة أن Copilot مستخدم على مستوى الشركة، بل معرفة أين يساعد فعلًا في دفع طلبات السحب، وأين لا يزال حضوره ضعيفًا أو غير مؤثر.

هذا النوع من الرؤية مهم خصوصًا بعد الجدل الذي صاحب تغييرات الاستهلاك والحصص في خدمات المساعدة البرمجية. وإذا كنت تتابع هذا الملف، يمكنك الرجوع إلى مقالنا السابق عن تغييرات GitHub Copilot التي أثارت استياء المطورين بعد استنزاف الحصص بشكل أسرع، لأن التحديث الجديد يبدو كخطوة مكملة تمنح المؤسسات أدوات أفضل لفهم أين تذهب التكلفة فعلًا.

GitHub تضيف أيضًا نشاط التطبيق نفسه داخل API

في اليوم نفسه، أضافت GitHub تحديثًا آخر لا يقل أهمية، إذ أصبح GitHub Copilot app جزءًا ظاهرًا داخل تقارير 1-day و28-day الخاصة بواجهة المقاييس. ووفق الشرح الرسمي، أُضيف حقلان جديدان: الأول لعدد المستخدمين النشطين يوميًا داخل التطبيق، والثاني قسم مستقل يعرض إجمالي الجلسات والطلبات والمطالبات واستهلاك الرموز داخل التطبيق نفسه.

هذا التفصيل مهم لأن كثيرًا من الشركات لم تعد تستخدم Copilot فقط من داخل VS Code أو بيئات التطوير التقليدية، بل باتت توزّع العمل بين واجهات متعددة، منها التطبيق المستقل وتجارب المراجعة والوكلاء البرمجيين. وعندما تكون هذه الأنماط كلها مخفية داخل رقم إجمالي واحد، يصبح من الصعب تقييم التبني الحقيقي أو مقارنة العائد بين سطح وآخر. أما الآن، فبإمكان الفريق أن يعرف بدقة إن كان التوسع يأتي من IDE، أو من التطبيق، أو من مراجعات الشيفرة، أو من الوكيل البرمجي.

كيف يمكن أن يغير ذلك قرارات التفعيل والميزانية؟

أهم ما يقدمه هذا التحديث هو تحويل الحديث عن الذكاء الاصطناعي البرمجي من انطباعات عامة إلى مؤشرات قابلة للمراجعة. فبدل أن تقول المؤسسة إن Copilot “يبدو مفيدًا”، يمكنها أن ترى مثلًا أن مستودعات معينة تشهد معدلًا أعلى من طلبات السحب المولدة أو المراجعة، بينما مستودعات أخرى لا تكاد تستفيد من الأداة. وعندها يصبح من السهل تحديد أين يجب توسيع التفعيل، وأين تحتاج الفرق إلى تدريب، وأين قد يكون تقليص النطاق أو إعادة الضبط قرارًا منطقيًا.

كما أن ظهور بيانات التطبيق نفسه يسهّل فهم ما إذا كان بعض المستخدمين يستهلكون الأرصدة عبر جلسات مطولة وطلبات كثيرة في Copilot app بدل بيئة التطوير. وهذا النوع من الشفافية قد يساعد على وضع سياسات استخدام أكثر دقة، خصوصًا في الشركات التي تتعامل مع ميزانيات AI credits أو تسعى لمقارنة العائد الإنتاجي بالتكلفة المباشرة.

ما الذي تقيسه التقارير الجديدة فعليًا؟

تُظهر تقارير المستودعات، وفق توثيق GitHub، نشاط طلبات السحب المرتبط بمسارين رئيسيين: Copilot coding agent وCopilot code review. أي أنها لا تحصي كل سطر كود كُتب بمساعدة Copilot، بل تركز هنا على المخرجات المرتبطة بطلبات السحب وما إذا كانت أُنشئت أو دُمجت أو راجعتها الأداة. أما تقارير التطبيق، فتضيف طبقة مختلفة تركز على المستخدمين النشطين، وعدد الجلسات، وعدد الطلبات، والمطالبات، واستهلاك الرموز.

هذا الفصل بين المقاييس مهم، لأنه يمنع خلط الإنتاج البرمجي بالتفاعل داخل التطبيق. وبعبارة أخرى، GitHub لا تقول إن كل استخدام متشابه، بل تقدم لكل سطح تشغيل طريقة قياس تناسبه. وهذا يمنح مسؤولي المنصات وفرق FinOps التقنية قدرة أكبر على قراءة المشهد بشكل ناضج بدل تفسير رقم واحد على أنه الحقيقة الكاملة.

هل هذه مجرد ميزة إدارية أم خطوة أكبر؟

من السهل التعامل مع الخبر على أنه تحديث API محدود، لكن تأثيره أوسع من ذلك. فكلما أصبحت أدوات الذكاء الاصطناعي داخل التطوير أكثر استقلالًا وتعددًا في الواجهات، زادت الحاجة إلى طبقة قياس تفصيلية توضح أين يظهر الأثر الحقيقي. وما تفعله GitHub هنا يشير إلى أن الشركة تدرك أن المرحلة التالية في منافسة أدوات البرمجة الذكية لن تُحسم فقط بالنموذج الأقوى، بل أيضًا بالقدرة على تفسير الاستخدام وربطه بالقيمة التشغيلية.

بمعنى آخر، المؤسسة التي تدفع مقابل Copilot لم تعد تريد وعودًا عن “تحسين الإنتاجية” فقط، بل تريد أدلة يمكن متابعتها يوميًا: أي المستودعات نشطة؟ كم عدد طلبات السحب التي لمسها الوكيل البرمجي؟ ما حجم التبني داخل التطبيق؟ وما مقدار الرموز التي تُستهلك في هذا المسار؟ هنا بالضبط تصبح مقاييس استخدام GitHub Copilot جزءًا من القرار الإداري، لا مجرد ميزة جانبية للمراقبة.

خلاصة التحديث

بتحديثات 17 يوليو 2026، انتقلت GitHub من تقديم صورة عامة عن استخدام Copilot إلى تقديم رؤية أكثر تفصيلًا على مستوى المستودعات والتطبيق نفسه. وهذا يجعل مقاييس استخدام GitHub Copilot أداة أكثر فائدة للفرق التي تحاول ضبط التبني، ومراقبة التأثير، وربط استهلاك الذكاء الاصطناعي بعوائد ملموسة داخل دورة التطوير.

إذا استمرت GitHub في توسيع هذه الطبقة من التقارير، فقد نرى لاحقًا أدوات أكثر ذكاءً لقياس الجاهزية، والعائد على الاستثمار، وأنماط الاستفادة بين الفرق والمشروعات. أما الآن، فالواضح أن الشركة ترسل رسالة مباشرة للمؤسسات: إذا كنت ستدفع أكثر على الذكاء الاصطناعي البرمجي، فمن حقك أن ترى بدقة أين يعمل، وكيف يُستخدم، وما الذي يغيره داخل مستودعاتك.