في 17 أغسطس، شهد GitHub خللًا واسع النطاق في الخدمة، وفي نفس اليوم، فتح Cursor النسخة التجريبية المبكرة Origin للمستخدمين المدفوعين. يتم الآن توصيل مستودعات الكود بـ Agent تعمل باستمرار، حيث تم تصميم البنية التحتية التعاونية الحالية لتناسب إيقاع عمل البشر. أظهرت الدراسات أن 40.2% من المستودعات شهدت PRs متداخلة لـ Agents، مع نسبة تعارض دمج تصل إلى 41.7%. تم تصميم Cursor Origin لدعم الكتابة المتكررة من قبل Agents، ويدعم 22.6 commit/s لكل مستودع، مع دمج المستودعات وPRs والفحوصات والمراجعات. يُعرّف Origin كطبقة تحكم فوق Git، مع إعادة تصميم عمليات التعاون المتكررة للـ Agents. لقد شكّلت xAI وX وSpaceX وCursor التابعة لـ ماسك سلسلة إنتاج ذكاء اصطناعي متكاملة، حيث توفر Colossus قوة الحوسبة، وGrok النماذج، وCursor تنفيذ الكود، وOrigin إدارة حالة الهندسة. ينتقل GitHub من التعاون البشري إلى توسيعه للـ Agents، بينما أعاد Cursor تصميم forge وفقًا لحمل عمل الـ Agents، وتتصاعد المنافسة بين المسارين بشكل متزايد.

كاتب المقال، المصدر: LeiFeng.com

صاحب مستودع الكود، يتحول من إنسان إلى عامل.

في 17 أغسطس، حدثت مشكلة واسعة النطاق في خدمة GitHub. تأثرت سلاسل أساسية مثل الويب وواجهة برمجة التطبيقات وActions وطلبات السحب وعمليات Git وWebhooks تدريجيًا، ووصل معدل أخطاء طلبات الويب وواجهة برمجة التطبيقات في بعض الفترات إلى حوالي 20%.

في نفس اليوم، بدأ Cursor في فتح Origin early beta تدريجيًا لجميع خطط الدفع. بدأت المستودعات وطلبات السحب والفحوصات والمراجعات والدمج والأتمتة في الدمج ضمن نظام واحد، ووضّح Cursor موقعه بوضوح: يجب أن يُصمّم استضافة الكود لـ "agent scale".

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

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

قد تبدأ العديد من المشكلات الجديدة التي يواجهها GitHub، والكثير من المشكلات التي تريد Origin حلها، من هنا.

01 GitHub لم يصبح مسنًا فجأة

عندما ولد GitHub، كانت وحدة أساسية ثابتة للتعاون البرمجي: الإنسان.

يكتب المهندس بضعة ساعات من الكود ثم يُقدّم一次 commit؛ تُطوّر ميزة واحدة على مدار أيام وتُشكّل PR واحدًا؛ قد تظهر المراجعة بعد نصف ساعة أو في اليوم التالي؛ من المقبول عادةً أن تستغرق CI بضع دقائق، ومعالجة تعارض الدمج لاحقًا لن تفقد النظام معناه.

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

حسب إحصائيات LWN، شهد دورة تطوير Linux 7.0 إجمالي 14251 commit غير مدمجة، من قبل 2362 مطورًا. حدثت هذه الإرسالات خلال دورات تطوير مستمرة لأسابيع، مع وجود مناقشات عبر البريد الإلكتروني ومراجعة المُحافظين ودمج الأنظمة الفرعية ودورة الإصدار.

أظهر Cursor في عرض تقديمي لـ Origin في يونيو شكلًا آخر من أشكال الحمل: 22.6 commit/s في مستودع واحد.

هذا الرقم ينتمي إلى بيانات عرض تجريبي مباشر، وليس معيار إنتاج تم إعادة إنتاجه بشكل مستقل، ولا يمكنه إثبات أن Origin يمكنه الحفاظ على نفس مستوى الإنتاجية على المدى الطويل في بيئات العمل الحقيقية. لكنه كافٍ لتوضيح نوع عبء العمل الذي تستهدفه Origin: عدد كبير من الوكلاء يقومون بكتابة مستمرة على نفس حالة الكود.

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

الوكيل لا يخضع لهذا الحد.

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

لذلك، ليس نموذج كائنات Git نفسه هو ما يجب أن يتحمل التغيير، بل أكثر أهميةً هو مستوى التحكم الخاص بـ Git: الواجهة البرمجية، المصادقة، المهام الخلفية، جدولة CI، Webhook، حماية الفرع، حالة المراجعة، وطابور الدمج، بالإضافة إلى الأحمال المتسلسلة التي تتشكل بين هذه المكونات.

أظهرت دراسة نُشرت في يوليو حول Agent PR على GitHub هذا الشكل المتزامن. وحللت الدراسة 33596 من Agent PR في 2807 مستودعًا، حيث ظهرت Agent PR متداخلة زمنيًا في 40.2% من المستودعات.

في التعديلات المتزامنة المعاد تعيينها بالعينة، بلغت نسبة تعارضات الدمج النصية بين PRs الخاصة بعوامل مختلفة 41.7٪، بينما كانت النسبة بين PRs المتزامنة التي أنشأها نفس العامل 19.8٪.

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

تم تصميم Origin من هنا أيضًا.

02 أصل إعادة كتابة تكلفة التعاون

إذا كان Origin يضيف فقط نقطة دخول لاستضافة مستودع Git، فمن الصعب عليه أن يُغيّر علاقات المطورين وبيئة مفتوحة المصدر ونظام الصلاحيات المؤسسية وأدوات التكامل التي شكلتها GitHub.

فرصته تأتي من أن العامل غيّر تكاليف التعاون. يُعد stacked PR مثالًا نموذجيًا.

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

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

يمكن أن تصبح PR الصغيرة نقطة تحقق للوكيل، مما يمنح المهمة القدرة على التحقق المحلي، وإعادة المحاولة المحلية، وتتبع التبعيات.

يمكن أيضًا فهم استحواذ Cursor على Graphite هنا. لا تزال النسخة التجريبية المبكرة الحالية من Origin لم تستوعب بالكامل سير عمل Graphite المكدس، لكن ميزات Graphite الطويلة الأمد مثل مراجعات PR المكدسة وطابور الدمج المدرك للتجميع، تتوافق تمامًا مع العقبات اللاحقة التي ظهرت بعد زيادة سرعة إنتاج الكود بواسطة Agent.

بعد زيادة عدد PR، تزداد مسؤوليات قائمة الدمج. يمكن لـ Agent A و Agent B العمل من نفس SHA الأساسي في نفس الوقت، مع اجتياز كل منهما الاختبارات بشكل منفصل.

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

يمكن أيضًا تحويل التعارضات تدريجيًا من التدخل اليدوي إلى حالة فشل قابلة للتعافي في خط الإنتاج. يقدم Cursor بالفعل /babysit نوعًا من القدرات للتعامل المستمر مع ملاحظات PR والفحوصات الفاشلة والتعارضات. بعد ظهور مشكلة في الدمج المرشح، يمكن إعادة السياق ذي الصلة إلى الوكيل لتصحيحه والتحقق منه مرة أخرى في بيئة معزولة.

سيتم أيضًا هيكلة المراجعة. يعتمد التعاون البشري بشكل كبير على اللغة الطبيعية وخبرة الفريق، بينما يتطلب تشغيل العوامل لفترات طويلة قراءة واضحة لتحديد أي فحص فشل، وأي خيوط لم تُحل، وأي سياسة لم تُلبَّ، وما هو SHA الحالي للرأس.

لقد عرض Origin عبر API كائنات المستودع والالتزام والفحوصات وطلبات السحب، وتمييز المراجعة الرسمية عن المناقشات العادية.

تُستهلك هذه الحالات المُهيكلة لاحقًا مباشرة من قبل Automations. تُحفّز push أو PR opened أو PR pushed عميل السحابة، وتُكتب نتائج التنفيذ مرة أخرى في checks و PR، وفي حال الفشل، تدخل العملية إلى سير العمل المعالج. كما تسمح MCP وhooks وAgent API للأدوات الخارجية بالانضمام إلى نفس سلسلة الأحداث.

"فصل عن GitHub" يعالج مسار الترحيل. يمكن للفريق أولاً نسخ مستودع GitHub احتياطيًا، مع الحفاظ على GitHub كمصدر الحقيقة، وفي نفس الوقت نقل سير عمل العميل إلى Origin؛ وبعد استقرار التشغيل، يمكن قطع التزامن وترك Origin يدير المستودع بشكل مستقل.

هذا يسمح لـ Cursor بأخذ المهام الأولية مثل الوكيل، والـ PR، والمراجعة، والفحوصات، والأتمتة، ثم تدريجيًا الاحتفاظ بالمزيد من حالات الهندسة داخل نظامه الخاص.

منطق منتج Origin واضح لذلك: يستمر Git في تولي التحكم بالإصدارات، بينما تهدف Origin إلى إعادة تصميم طبقة التحكم التي تعمل حول الوكلاء عالي التردد فوق Git.

03 Old Ma is consolidating an AI production chain

على مدار العام الماضي، تشكلت علاقات سلسلة توريد أكثر اكتمالاً بين xAI وX وSpaceX وCursor.

شركت xAI X، ثم دخلت نظام SpaceX؛ حصل Cursor على موارد الحوسبة Colossus، ثم دخل أيضًا نظام SpaceX. في الوقت نفسه، تم إصدار Grok 4.6، وبدأ Origin في الفتح.

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

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

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

يمكن تعيين Colossus و Grok و Cursor و Origin على مستويات مختلفة على هذه السلسلة: Colossus توفر قوة الحوسبة، Grok توفر قدرات النموذج، Cursor توفر عامل الكود وبيئة التنفيذ، Origin تخزن حالة المستودعات وطلبات السحب والفحوصات وحالات المراجعة.

يُشكل إنتاج الكود سلسلة متصلة: النموذج يتخذ قرارًا، ويحول Cursor هذا القرار إلى تعديلات فعلية، ويحفظ Origin حالة المشروع ويتولى التحكم في التعاون اللاحق.

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

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

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

لماذا يحتاج Cursor إلى Origin، ويمكن تفسير ذلك أيضًا: بعد توليد الكود، هناك حاجة إلى نظام يحافظ على حالة المشروع على المدى الطويل، وينسق التعديلات، ويتحقق من النتائج، ويربطها بالتنفيذ التالي. إذا ظل هذا الموضع دائمًا خارجيًا، فستكون هناك وصلة اعتماد حاسمة في سلسلة إنتاج برنامج Agent.

والأصل يملأ هذه الطبقة بالضبط.

04 الخلاف بين GitHub وOrigin

يملك GitHub بالفعل ميزات PR متراكمة وطابور دمج وواجهة برمجة تطبيقات REST، كما يستمر في دمج عامل الترميز Copilot في القضايا والإجراءات وPR ومراجعة الكود. من حيث قائمة الميزات فقط، سيزداد التداخل بين الطرفين في المستقبل.

الاختلافات تأتي أساسًا من افتراضات التصميم.

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

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

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

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

وبالتالي، ستتغير مؤشرات Agent-native forge. إن 22.6 commit/s ملحوظة، لكن عدد commits نفسه لا يمكنه تمثيل كفاءة إنتاج البرنامج. المؤشرات الأكثر أهمية ستكون الوقت المطلوب من دخول المهمة إلى النظام حتى الدمج، وقدرة الاسترداد الجزئي بعد الفشل، النسبة المئوية للتعديلات التي تتم تلقائيًا ضمن السياسة، تكلفة الحساب الخاصة بالتغييرات المقبولة، والانتباه البشري المستهلك في التعديلات عالية المخاطر.

ما يرغب Origin في التحكم فيه هو سطح التحكم في إنتاج البرنامج الناتج عن دمج المستودعات والفحوصات والمراجعات والصلاحيات والأحداث.

من ثم سيتحول التنافس بين GitHub وOrigin إلى مسارين: GitHub يتوسع من نظام تعاون بشري ناضج نحو الوكلاء، بينما يحاول Cursor إعادة تصميم forge وفقًا لعبء عمل الوكلاء.

05 لقد وصل老马 إلى الطبقة التالية

بالعودة إلى الموضوع، فبعد إصدار Grok 4.6، من السهل على الخارج الاستمرار في مناقشة قدرات الكود ودرجات الاستدلال والسعر من خلال المعايير المرجعية. لكن عندما ننظر إلى Colossus وGrok وCursor وOrigin معًا، فإن هذا التخطيط قد امتد بالفعل إلى سلسلة إنتاج البرمجيات بعد النموذج.

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

لذلك، فإن موقع Grok 4.6 اليوم على قائمة ما قد يكون نتيجة مؤقتة. السؤال الأطول أجلاً هو من يستطيع تنظيم النموذج وبيئة التنفيذ وحالة هندسة البرمجيات كنظام إنتاجي يعمل باستمرار.

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