لماذا تضع GitHub سقفًا لـ Copilot؟ وكلاء البرمجة يكسرون نموذج الاشتراك

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

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

ما المؤكد حتى الآن؟

هناك أربع نقاط يمكن تثبيتها من المصادر العلنية.

أولًا، أوقفت GitHub مؤقتًا التسجيلات الجديدة في خطط Copilot Pro وPro+ وStudent، وشدّدت حدود الاستخدام في الخطط الفردية، وأزالت نماذج Opus من خطة Pro .

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

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

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

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

من مساعد يجيب إلى وكيل يعمل

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

لكن نموذج agentic coding مختلف. في إصدارات GitHub Copilot داخل VS Code، أشارت GitHub إلى ميزة Autopilot for fully autonomous agent sessions ضمن المعاينة العامة، كما تحدثت عن أدوات للتحكم في كيفية تشغيل الوكلاء . هذا يعني أن نية واحدة من المطور قد تتحول إلى جلسة عمل مستقلة لا تنتهي فورًا بعد الرد الأول.

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

لماذا يضغط وكلاء البرمجة على البنية التحتية؟

1. الطلب القصير أصبح جلسة طويلة

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

بمعنى آخر، لا يكفي النظر إلى عدد المشتركين. مستخدم واحد يشغّل مهمة وكيل مكثفة قد يستهلك موارد أكثر بكثير من عدد كبير من طلبات الإكمال البسيطة.

2. التوازي لم يعد يعني عدد الأشخاص المتصلين

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

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

3. الذكاء الاصطناعي دخل مسار التعاون الأساسي

مراجعة الكود مثال مهم. GitHub قالت إن استخدام Copilot code review نما 10 أضعاف منذ أبريل السابق، وأصبح يمثل أكثر من خُمس مراجعات الكود على GitHub. وذكرت أيضًا أن البنية الخلفية انتقلت إلى agentic architecture تسترجع سياق المستودع وتستنتج عبر التغييرات .

هذا أثقل من نافذة دردشة منفصلة. هنا يدخل الذكاء الاصطناعي في مسار تعاون يومي: يقرأ سياق المستودع، ينظر في التغييرات، ويشارك في مراجعة الكود. لذلك ليس مفاجئًا أن تعلن GitHub أن Copilot code review سيبدأ باستهلاك دقائق GitHub Actions من 1 يونيو 2026 .

4. الاشتراك الثابت يصطدم بسرعة الآلة

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

لهذا تبدو خطوة GitHub نحو الفوترة حسب الاستخدام منطقية ضمن هذا السياق. فبدءًا من 1 يونيو 2026، ستستهلك كل خطط Copilot أرصدة GitHub AI Credits بدل أن تبقى التكلفة مفهومة فقط من زاوية المقعد أو الاشتراك الشهري .

ماذا فعلت GitHub بالفعل؟

ليست المسألة حدًا واحدًا أو تعديلًا عابرًا. GitHub تتحرك على عدة مستويات لإعادة موازنة السعة والتكلفة وعدالة الاستخدام:

• إيقاف التسجيلات الجديدة مؤقتًا في Copilot Pro وPro+ وStudent، وتشديد حدود الاستخدام في الخطط الفردية، وإزالة نماذج Opus من Pro .
• تطبيق حدود جديدة والتخلص من Opus 4.6 Fast في Copilot Pro+، في سياق زيادة أنماط الاستخدام عالي التوازي والكثافة التي تضغط على البنية التحتية المشتركة .
• نقل جميع خطط Copilot إلى الفوترة حسب الاستخدام ابتداءً من 1 يونيو 2026، مع استهلاك GitHub AI Credits عند استخدام Copilot .
• جعل Copilot code review يستهلك دقائق GitHub Actions ابتداءً من 1 يونيو 2026 .
• إضافة نشاط GitHub Copilot CLI لكل مستخدم إلى مقاييس استخدام Copilot في تقارير المؤسسات، ما يمنح الفرق رؤية أدق لاستخدام واجهة سطر الأوامر .

هذه الإشارات مجتمعة تقول إن المشكلة ليست «نموذجًا مكلفًا» فقط، ولا «أسبوعًا مزدحمًا» فقط. الحمل نفسه تغيّر.

كيف نقرأ رقم «30 ضعفًا»؟

حتى لو كان رقم «30 ضعفًا» الوارد في التقرير الخارجي صحيحًا، فلا ينبغي فهمه على أنه يعني بالضرورة زيادة عدد المستخدمين 30 مرة. هندسيًا، قد يأتي الضغط من حاصل ضرب عدة عوامل: مزيد من المطورين يستخدمون agentic coding، وكل مطور قد يشغّل مهام أطول وأكثر توازيًا، وهذه المهام قد تستدعي نماذج وأدوات وتقرأ سياق مستودعات وتدخل في مسارات مثل مراجعة الكود وموارد GitHub Actions .

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

ماذا يعني ذلك لفرق التطوير؟

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

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

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

رابعًا: حدّثوا نموذج الميزانية قبل 1 يونيو 2026. بعد هذا التاريخ، سيستهلك استخدام Copilot أرصدة GitHub AI Credits، وستبدأ مراجعة الكود عبر Copilot في استهلاك دقائق GitHub Actions . هذا يجعل تكلفة الذكاء الاصطناعي أقرب إلى كثافة الاستخدام الفعلية، لا إلى عدد الاشتراكات فقط.

الخلاصة

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

GitHub أقرت بأن agents وsubagents يضغطون على البنية التحتية ونموذج التسعير، وردّت بإيقاف بعض التسجيلات الجديدة، وتشديد الحدود، وتعديل توفر بعض النماذج، والانتقال إلى GitHub AI Credits، وإدخال Copilot code review في حساب دقائق GitHub Actions .

النتيجة الواضحة: نموذج السعة ونموذج الأعمال في Copilot يُعاد تشكيلهما بفعل وكلاء البرمجة. أما رقم «30 ضعفًا»، فيجب التعامل معه بحذر بوصفه رقمًا من تقرير خارجي لا حقيقة رسمية معلنة .