Cursor تضيف وضع الفريق إلى Projects: وكلاء الزملاء يتشاركون السياق والمهام

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

ما الذي تغيّر

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

تبرز الشركة ثلاثة عناصر.

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

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

الثالث — تواصل الوكلاء فيما بينهم. يرى منسّقو الزملاء ما يفعله الآخرون ويمكنهم الاتفاق دون تدخل البشر.

كيف يبدو ذلك في الأمثلة

تورد Cursor عدة سيناريوهات. أكثرها واقعية هو المناوبات (on-call). تدير عدة فرق في الشركة التناوب داخل Project مشترك. عندما استلم أحد المهندسين المناوبة من زميله، تحقق منسّقه أولًا من صحة كل شيء، ثم تابع من حيث توقّف سابقه. كان يعرف بالفعل المهام الجارية، والطلبات التي لم تُعالج، وما ينبغي نقله بشأن الحوادث والملاحظات، والقنوات ولوحات Linear والخيوط التي يجب متابعتها. ويمكن تسليم العمل غير المكتمل مباشرة: يلتقطه وكيل المناوب الجديد ببساطة.

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

الفكرة واضحة ومألوفة: ما كان يُحسم في اجتماع أو مراسلات يُنقل إلى المنسّقين.

ما ينبغي أخذه في الاعتبار

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

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

ماذا نفعل عمليًا

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

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