أعلنت GitHub يوم 20 يوليو 2026 أن GitHub Code Quality أصبح متاحًا رسميًا بعد فترة معاينة عامة استمرت عدة أشهر، لتنتقل الميزة من تجربة اختيارية إلى منتج مدفوع موجّه للفرق التي تريد التقاط مشكلات الجودة قبل وصولها إلى الفرع الرئيسي. وبحسب الشرح الرسمي، لا يقتصر الدور هنا على اكتشاف الأخطاء التقليدية، بل يمتد إلى رصد مشكلات القابلية للصيانة والموثوقية داخل طلبات السحب، مع اقتراحات إصلاح يمكن مراجعتها مباشرة عبر Copilot Autofix.

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

ما هو GitHub Code Quality بالضبط؟

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

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

ما الجديد بعد الإتاحة الرسمية في 20 يوليو 2026؟

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

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

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

كيف يعمل GitHub Code Quality مع CodeQL وCopilot Autofix؟

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

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

لماذا يهم هذا الإطلاق لفرق التطوير الكبيرة؟

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

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

التسعير الجديد وما الذي تغيّر بعد الخروج من المعاينة؟

أحد أهم الفروقات بين وضع المعاينة والإتاحة الرسمية هو أن الفوترة بدأت تلقائيًا في 20 يوليو 2026. ووفق GitHub، يعتمد التسعير على أكثر من طبقة: هناك رسم أساسي قدره 10 دولارات لكل مساهم نشط شهريًا، ويُحسب المساهم نشطًا إذا دفع commit إلى مستودع مفعّل عليه Code Quality خلال آخر 90 يومًا. ولا تُحتسب حسابات الروبوت ضمن هذا الرسم.

إضافة إلى ذلك، توجد فوترة استهلاكية للأعمال المعتمدة على الذكاء الاصطناعي مثل AI-assisted detection وCopilot Autofix، إلى جانب تكاليف الحوسبة الخاصة بتشغيل تحليل CodeQL عبر GitHub Actions. وهذا يعني أن المؤسسات لم تعد تتعامل مع الأداة كتجربة مجانية ممتدة، بل كخدمة يجب تقييم عائدها بوضوح مقابل الكلفة المباشرة وغير المباشرة.

هل تحتاج إلى GitHub Copilot لاستخدام الميزة؟

المثير للاهتمام أن توثيق GitHub يوضح أن GitHub Code Quality لا يتطلب امتلاك رخصة Copilot أو GitHub Code Security حتى تستفيد من المنتج نفسه. لكن بعض القدرات الذكية مثل Copilot Autofix تضيف بطبيعة الحال قيمة أكبر عندما تكون المؤسسة مستعدة لاستخدام هذه الطبقة التوليدية. هذا الفصل مهم لأنه يجعل الأداة قابلة للتبني حتى لدى الفرق التي تريد تحسين الجودة أولًا ثم توسعة استخدام المساعدات الذكية لاحقًا.

كما أن GitHub أوضحت أيضًا أن الخدمة متاحة عند الإطلاق على خطط GitHub Team وGitHub Enterprise Cloud فقط، وليست متاحة على GitHub Enterprise Server في هذه المرحلة. لذلك يجب على المؤسسات التي تعتمد بيئات محلية بالكامل أن تضع هذا القيد في الحسبان قبل بناء توقعات سريعة حول التبني.

هل هو منتج أمني أم منتج جودة؟

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

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

الخلاصة

إتاحة GitHub Code Quality رسميًا في 20 يوليو 2026 ليست مجرد تحديث صغير في GitHub Changelog، بل إشارة واضحة إلى أن مرحلة “اكتب أكثر بسرعة” لم تعد كافية وحدها. السوق يتحرك الآن نحو “اكتب بسرعة، لكن قِس الجودة وافرضها واصلحها قبل الدمج”. ومع لوحات المؤسسة، حدود التغطية، وCopilot Autofix، تحاول GitHub أن تجعل الجودة جزءًا أصيلًا من دورة التطوير اليومية بدل أن تظل مهمة مؤجلة لما بعد التسليم.

إذا كانت مؤسستك تستخدم GitHub على نطاق واسع وتبحث عن وسيلة عملية لربط التحليل، الحوكمة، والإصلاحات الذكية داخل منصة واحدة، فسيكون GitHub Code Quality من التحديثات التي تستحق المتابعة الجدية خلال النصف الثاني من 2026.

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