الوكلاء يتفوقون على البشر في أغسطس 2026 في عدد PR على GitHub وعدد المهام في Linear

في أغسطس 2026 أنشأ الوكلاء على GitHub عدد pull requests أكبر مما أنشأه البشر. وفي Linear يفتح الوكلاء مهام أكثر مما يفتحه الموظفون من البشر. أورد هذه البيانات غيرغي أوروس، صاحب نشرة The Pragmatic Engineer، في حديثه خلال مؤتمر LDX3 في نيويورك. كما وصف كيف تتغير الأدوات: فـ Cursor وAntigravity تبتعدان عن بيئة IDE التقليدية، وصارت مراجعة الكود في شركات كثيرة مسرحية شكلية.

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

لم يعد البشر الكتّاب الرئيسيين للكود

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

ولدعم هذه الأطروحة يستخدم أوروس بيانات حديثة من GitHub وLinear وFactory AI. وتكمّلها قصص من OpenAI وAnthropic وUber وRamp، وهي شركات أصبحت فيها العمليات القائمة على الوكلاء جزءًا من التطوير اليومي.

IDE تفقد مكانتها المركزية

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

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

مراجعة الكود تحولت إلى مسرحية

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

المشكلة في الحجم. فالوكيل ينشئ PR في دقائق، بينما تستغرق المراجعة المتأنية الوقت نفسه الذي كانت تستغرقه من قبل. والفجوة بين سرعة التوليد وسرعة الفحص تتسع.

ما هو معروف من الملخّص

• أغسطس 2026: أنشأ الوكلاء على GitHub عدد PR أكبر من البشر.
• Linear: يفتح الوكلاء مهام أكثر من البشر.
• Cursor وAntigravity تبتعدان عن نموذج IDE.
• مراجعة الكود في شركات كثيرة أصبحت إجراءً شكليًا.
• مصادر البيانات: GitHub وLinear وFactory AI.
• الحالات: OpenAI وAnthropic وUber وRamp.

خلاصات عملية للفرق

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

السؤال الرئيسي لعام 2026: من في فريقكم يتحمل مسؤولية النتيجة إذا كان الوكيل هو من يكتب الكود، وأصبحت المراجعة شكلية.