Cursor يريد تشغيل وكلائك واستضافة الكود الذي يكتبونه

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

كلاهما يصدر في نسخة تجريبية لا كمنتج مكتمل، والأسئلة التي يتركانها مفتوحة أهم من قائمة الميزات.

ما الذي أطلقته Cursor فعلاً اليوم

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

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

‏Projects في نسخة تجريبية ويُطرح تدريجياً لجميع المستخدمين اعتباراً من اليوم. وتصل Origin إلى نسخة تجريبية مبكرة على الخطط المدفوعة اليوم، باستثناء مؤسسات Enterprise التي يختار مسؤولوها عدم المشاركة.

Origin مقابل GitHub: مسألة المصدر المرجعي

لا تقدّم Cursor ‏Origin كبديل لـ GitHub، والآلية تدعم ذلك. فبالنسبة إلى المستودعات المستضافة على Origin، تكون Origin هي المصدر المرجعي ولا تصل عمليات الدفع (push) إلى GitHub أبداً. أما المستودعات المستوردة من GitHub، فيبقى GitHub هو المصدر المرجعي، وتستمر عمليات الدفع بالاتجاه إليه، وتعكس Origin النتيجة. وتتحرك طلبات السحب في المستودعات المتزامنة في الاتجاهين: التعليق المكتوب في Cursor يُنشر على GitHub، والرد على GitHub يظهر في Cursor خلال ثوانٍ.

لكن الثقل يكمن في الحالة الأخرى: مستودع يُنشأ في Origin، ويعمل عليه الوكلاء، ويُراجع ويُدمج داخل Cursor، دون أن يلامس GitHub إطلاقاً. وتحمل المستودعات اسم قاعدة كود يصبح جزءاً من رابطها، cursor.com/codebase/acme-corp، وتُوصّل Cursor إلى جانب ذلك منظومة تطبيقات، مع تكاملات Vercel وDepot وBuildkite متاحة الآن، وVercel تمنح كل طلب سحب نشراً تجريبياً.

ادعاء المنسّق والوكلاء الفرعيين، في مواجهة الصياغة

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

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

السعة المستضافة ذاتياً: بنية تحتية للمؤسسات خلف النسخة التجريبية

تقوم قصة Cursor المؤسسية على ثلاثة خيارات منفصلة.

لا ترتبط المجموعات بمستودع واحد: سمِّ مجموعة، ويمكن لأي عامل متاح التقاط الطلب. ويمكن أيضاً تشغيل الوكلاء السحابيين على بنية تحتية يشغّلها المشتري أصلاً، بما في ذلك AWS Lambda وCoder وCloudflare وDaytona وModal وNamespace وVercel وE2B. وتشير هذه القائمة إلى فرق لا تسلّم مخرجات البناء أو الأسرار إلى سحابة مورد، وتتعطل مراجعة أمنها عند هذه النقطة تحديداً.

ما يجب متابعته: التسعير والموثوقية وشرط عدم المشاركة

تبرز ثلاث ثغرات. لم تنشر Cursor أي سعر لـ Projects أو Origin أو المجموعات المستضافة ذاتياً أو شركاء البنية التحتية الذين سمّتهم. ويستثني طرح Origin مؤسسات Enterprise التي يختار مسؤولوها عدم المشاركة، ما يشير إلى أن الشركة تتوقع اعتراضاً من مشترين خصصت قسماً لاستمالتهم. كما أن ادعاءات الاستقلالية، وكلاء يتابعون قناة Slack أو طلب سحب ويتصرفون بناءً على ما يجدونه، تعتمد على حلقات لا يمكن اختبارها إلا بنشر مستدام. أما ما إذا كانت هذه الحلقات تصمد في الأسبوع الثالث، فليس سؤالاً يجيب عنه منشور إطلاق.