الوكلاء يفتحون طلبات الدمج

في 28 أكتوبر نشرت GitHub تقرير Octoverse، تقريرها السنوي عن النشاط على المنصة، ويبرز فيه سطر واحد: بحلول سبتمبر 2026، بدأ أكثر من 40 بالمئة من طلبات الدمج (pull requests) على GitHub بمسودة أولى من وكيل، ارتفاعًا من 17 بالمئة في مارس. وكان ذلك 110 ملايين طلب دمج في سبتمبر وحده. وفي اليوم نفسه، خلال مؤتمرها Universe، طرحت GitHub خدمة Copilot Projects في معاينة عامة، وأتاحت Agentic Workflows للجميع.

وبعد أسبوع اشترت Meta شركة Conductor، وهي شركة ناشئة صُممت لتشغيل عدة وكلاء برمجة في آن واحد. وتشير الأخبار مجتمعةً إلى اتجاه واحد: لم تعد كتابة الشيفرة الجزء النادر في صناعة البرمجيات. بل تحديد مواصفاتها، ومراجعتها، واختبارها، وتحمّل مسؤوليتها.

ما الذي أحصته GitHub

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

ويقول التقرير أيضًا إن طلبات الدمج التي يبدؤها وكلاء باتت تُدمج بمعدل لا يقل عن غيرها. ففي فبراير دُمج 83 بالمئة من طلبات الدمج التي شارك فيها وكيل خلال أسبوعين، مقابل نحو 86 بالمئة من تلك التي لم يُكتشف فيها وكيل، وبحلول سبتمبر وصلت نسبة طلبات الوكلاء إلى 90 بالمئة. وهي أوسع نطاقًا أيضًا: فنحو 87 بالمئة منها تغيّر أكثر من ملف واحد، مقابل 79 بالمئة من غيرها. وفي قراءتنا، يُظهر الدمج أن مراجعًا قبل التغيير، لا أن التغيير كان صحيحًا.

مزيد من الوكلاء لكل شخص

والمنتجات التي أطلقتها GitHub في اليوم نفسه تفترض أن هذه النسبة ستواصل النمو. فـ Copilot Projects يمنح العمل الممتد عبر عدة مستودعات مكانًا واحدًا لسياقه ووكلائه ونتائجه. تصفون هدفًا، فيشغّل Copilot وكلاء بالتوازي، و«يعود إليكم حين يحتاج إليكم»، ويأتي بنتائج مثل طلبات دمج لمراجعتكم. وتتيح Agentic Workflows للفريق أن يصف بلغة Markdown مهامَّ مثل فرز المشكلات أو تحليل عملية بناء فاشلة، ثم يكلّف وكيل برمجة بتنفيذها في GitHub Actions، مع صلاحيات للقراءة فقط افتراضيًا، ومهمة منفصلة تفحص التغييرات المقترحة قبل تطبيقها.

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

سبعون بالمئة لا تعني الانتهاء

ويُظهر اختبار جديد من خارج GitHub لماذا لا يمكن تخطي تلك المراجعة. ففي 26 أكتوبر نشر باحثون من Alibaba وعدة جامعات Co-Design Bench: وهو 273 مهمة مأخوذة من 26,314 جلسة برمجة حقيقية لمستخدمين، فُحصت كل منها مقابل معايير قبول خفية كتبها خبراء، يبلغ مجموعها 2,331 معيارًا. وحقق أقوى النماذج العشرة، التي شُغّلت جميعها في إعداد الوكيل نفسه، 69.9 بالمئة من المعايير لكل مهمة في المتوسط، لكنه لم يستوفِ المتطلبات بالكامل إلا في 26.4 بالمئة من المهام. وكتبت The Decoder، في تقريرها عن الدراسة في 8 نوفمبر، أن وكلاء البرمجة لا يزالون «بحاجة إلى تنظيف بشري في نحو ثلاث من كل أربع مهام».

وللدراسة حدودها. فكل مهمة طلب واحد ثابت، فلم يكن بوسع الوكلاء طرح أسئلة أو تلقي تصحيح أثناء العمل، والتقييم يجريه حكّام من الذكاء الاصطناعي قد يخطئون، وعدد من المؤلفين من Alibaba، التي كان نموذجها Qwen بين النماذج المختبرة. ومع ذلك، فإن الفجوة التي تقيسها، بين معظم المتطلبات وجميعها، هي بالضبط الفجوة التي يوجد المراجع لسدّها.

ما الذي تفعله الفرق الجيدة الآن

لا يحتاج أي من هذا إلى أدوات جديدة بقدر ما يحتاج إلى انضباط قديم يُطبَّق بصرامة أكبر. ابدؤوا بالمواصفات: فحين يصوغ وكيل التغيير، تكون المهمة المكتوبة هي المصدر الحقيقي، وقد حذّر جينا من أن «المهام سيئة التحديد قد تؤدي إلى تنفيذ متكرر وإعادة عمل واستهلاك أعلى لأرصدة الذكاء الاصطناعي». دوّنوا ما الذي يعنيه الانتهاء قبل أن يبدأ الوكيل، على غرار ما يفعله Co-Design Bench حين يضع معايير القبول أولًا.

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

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

الأدوات يمكن أن تُطفأ

وتضيف صفقة Conductor درسًا أهدأ. فقد أفادت TechCrunch في 4 نوفمبر بأن Meta استحوذت على هذه الشركة الناشئة، التي تأسست في 2024، وفرق الوكلاء لديها «مصممة لمساعدة مهندسي البرمجيات على العمل بتناسق على أجزاء منفصلة ومعزولة من المشروع»، مستخدمةً وكلاء من مختبرات مثل Anthropic وOpenAI. وأكدت Meta عملية الشراء لكنها لم تكشف عن شروطها.

ويحدد إشعار Conductor نفسه الجدول الزمني. فقد توقف التسجيل الجديد في 4 نوفمبر، وتصبح مساحات العمل السحابية للقراءة فقط في 13 نوفمبر، وفي 20 نوفمبر تبدأ الشركة حذف بيانات المستخدمين السحابية، فأمام العملاء ستة عشر يومًا لتصدير ما يحتفظون به هناك. ويواصل تطبيق سطح المكتب العمل في الوقت الحالي، ويبدأ إيقافه تدريجيًا في مطلع 2027. وتقول Conductor إنها لم تبع بيانات المستخدمين قط ولم تدرّب عليها، وتتيح تصديرها ونقلها إلى التطبيق المحلي.

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

أين نقف

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