GitHub Copilot يتحول إلى منصة برمجة وكيلة لا مجرد إكمال تلقائي

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

تعديلات متعددة الملفات… لكن تحت عين المراجعة

الجسر الأهم بين الإكمال التلقائي والوكيل الكامل هو تحرير الملفات المتعددة. في تحديث VS Code Copilot لشهر أكتوبر/تشرين الأول 2024، طرحت GitHub ميزة تحرير الملفات المتعددة في وضع المعاينة عبر الإعداد github.copilot.chat.edits.enabled، بما يسمح ببدء جلسة تحرير مدعومة بالذكاء الاصطناعي وطلب تغييرات عبر عدة ملفات داخل مساحة العمل.

النمط الموثق ليس أن Copilot “يعيد كتابة المستودع في الخفاء”. المسار المعروض يتمحور حول المراجعة: يقترح Copilot تعديلات، يطبقها مباشرة داخل المحرر، ثم يتيح للمطور مراجعتها في سياقها. وتصف وثائق Microsoft Visual Studio تجربة مشابهة في Copilot Edits تجمع بين المحادثة والمراجعة المضمنة، مع ملخص للملفات المتأثرة، والتغييرات المقترحة، وفروقات الشيفرة داخل المحرر، وأزرار قبول أو رفض للتغييرات الفردية.

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

Copilot Workspace: العمل يبدأ من النية لا من المؤشر

يدفع Copilot Workspace الفكرة نفسها باتجاه إدارة المهام داخل GitHub. يصف دليل GitHub Next هذه التجربة بأنها مساعد ذكاء اصطناعي “متمحور حول المهمة”، ومندمج بعمق مع GitHub، وواعٍ بسياق المستودع، والمشكلة، وطلب السحب المرتبط بالمهمة.

وفي سجل تغييرات Copilot Workspace لشهر فبراير/شباط 2025، أبرزت GitHub تحسينات في المتابعات والبحث عن الملفات تستهدف توليد شيفرة عبر ملفات متعددة والعمل داخل مستودعات كبيرة ذات اعتماديات معقدة. وتقول GitHub إن ميزة “follow ups” تفحص قاعدة الشيفرة وتحرر الملفات الضرورية تلقائياً إذا اكتشفت متابعات مطلوبة.

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

VS Code يصبح لوحة التحكم لوكلاء Copilot

تحديثات Copilot في VS Code تجعل الاتجاه نحو فهم المستودع أوضح. يقول سجل تغييرات أبريل/نيسان 2026 إن Copilot يستطيع البحث “بالمعنى” داخل أي مساحة عمل، وتشغيل استعلامات شبيهة بـ grep عبر مستودعات GitHub ومؤسساته. ويذكر التحديث نفسه ميزة تجريبية باسم /chronicle للاستعلام في سجل المحادثات، إلى جانب تخزين أذكى للمطالبات، وتحميل مؤجل للأدوات لتقليل استهلاك الرموز، وفروقات مدمجة في المحادثة للوكلاء.

كما يشير سجل تغييرات مارس/آذار 2026 في VS Code Copilot إلى الاتجاه نفسه، إذ يذكر Autopilot لجلسات وكلاء مستقلة بالكامل في معاينة عامة، ويقول إن أداة #codebase تنفذ عمليات بحث دلالية بالكامل على فهرس واحد مُدار تلقائياً.

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

اختيار النموذج أصبح جزءاً من سير العمل

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

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

تجارب Bring Your Own Key، أو استخدام مفتاح API خاص بالمستخدم، تدفع في الاتجاه نفسه، لكن يجب صياغتها بحذر. تشير ملاحظات إصدار VS Code لشهر مارس/آذار 2025 إلى أن BYOK أصبح في وضع المعاينة لمستخدمي Copilot Pro وCopilot Free، بما يسمح باستخدام مفاتيح API خاصة لمزودين مثل Azure وAnthropic وGemini وOpenAI وOllama وOpenRouter. وتضيف الملاحظات أن GitHub كانت تستكشف دعمه لعملاء Copilot Business وEnterprise. لذلك فالأدق وصفه بأنه دعم BYOK في سياقات محددة داخل VS Code/Copilot، لا دليلاً على أن كل خطط Copilot تدعم عالمياً أي نموذج يختاره المستخدم.

إيقاف النماذج لم يعد خبراً جانبياً

كلما امتد Copilot عبر المحادثة، والتعديلات المضمنة، ووضع السؤال، ووضع الوكيل، والإكمالات، أصبحت تغييرات النماذج تؤثر مباشرة في العمل اليومي. يقول سجل تغييرات GitHub لشهر مايو/أيار 2026 إن نموذج Grok Code Fast 1 سيتم إيقافه عبر كل تجارب GitHub Copilot، بما في ذلك Copilot Chat، والتعديلات المضمنة، ووضعَي ask وagent، وإكمالات الشيفرة، في 15 مايو/أيار 2026. ويذكر السجل نفسه أن GPT-4.1 مقرر لإيقافه عبر تلك التجارب في 1 يونيو/حزيران 2026.

هذا ليس حدثاً منفرداً. فقد قالت GitHub في سجل تغييرات يناير/كانون الثاني 2026 إنها تقيّم النماذج القديمة وتوقفها بانتظام لصالح نماذج أحدث، مع إدراج إيقافات تشمل Copilot Chat، والتعديلات المضمنة، ووضعَي ask وagent، وإكمالات الشيفرة.

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

لماذا يقلق المطورون من تغيّر الجودة؟

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

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

كيف ينبغي للفرق أن تتعامل مع المرحلة الجديدة؟

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

أما لقادة الفرق الهندسية، فالأولوية هي تحديد أين يُسمح لـ Copilot الوكيلي بالعمل. تعديلات الملفات المتعددة ووضع الوكيل مفيدان للتغييرات الميكانيكية، والترحيلات، وتحديث الاختبارات، لكنهما يوسعان مساحة المراجعة. لذلك تصبح سياسات النماذج، وقابلية التدقيق، وخطط الإطلاق التدريجي أكثر أهمية عندما يحرر Copilot عدة ملفات أو يشغّل أوامر طرفية، مقارنة باقتراح سطر واحد.

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

الخلاصة

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

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