لماذا بنية الدماغين؟
تستخدم معظم مساعدات كتابة الكود نموذجًا واحدًا يجب عليه تحديد ما سيتم بناؤه وكتابة المصدر في آن واحد. ومع استمرار الجلسات الطويلة، تمتلئ نافذة السياق (context window) الخاصة بالنموذج، مما يؤدي إلى "انحراف السياق" (context drift) – حيث ينسى النموذج القرارات السابقة ويقوم بإنتاج كود متناقض أو مكرر. يحل Cursor هذه المشكلة عن طريق تقسيم الجهد الذهني:
- وكلاء التخطيط (Planner agents) يعملون على أقوى النماذج (تذكر المسودة Opus 4.8 أو Fable 5). يقوم هؤلاء بتقسيم الطلب رفيع المستوى إلى تسلسل هرمي للمهام، وحل الغموض، وتسجيل خيارات التصميم.
- وكلاء التنفيذ (Worker agents) يعملون على نماذج أسرع وذات إنتاجية عالية (Composer 2.5). يتلقون مهامًا محددة من المخططين ويقومون بإنشاء مقتطفات الكود.
إن الفصل بين "ماذا" و"كيف" يمنع التحميل الزائد الذي يعطل الأنظمة ذات النموذج الواحد. يظل كل نموذج ضمن حجم سياق يناسب دوره، مما يتجنب تضخم ميزانية الرموز (token budget) الذي يضطر المصممين إلى اختصار المطالبات (prompts).
توسيع نطاق السرب
كانت الإصدارات الأولى من سرب Cursor تنجز حوالي ألف عملية إرسال (commit) في الساعة. وبعد إعادة التصميم بنظام "الدماغ المنقسم"، وصل النظام إلى حوالي ألف عملية إرسال في الثانية. كشفت هذه السرعة عن عنق زجاجة جديد: أدوات التحكم في الإصدارات لم تكن مصممة لمثل هذا التنافس. فعندما يصدر مخططان تعليمات متداخلة، قد ينتهي الأمر بالمستودع (repository) بوجود منطق مكرر – وهي مشكلة يطلق عليها الفريق اسم "أخطاء الدماغ المنقسم" (split-brain errors).
قام Cursor بتهدئة هذه الفوضى باستخدام ثلاث ضمانات:
- وثائق تصميم مشتركة – يكتب كل مخطط قراراته في وثيقة مركزية مرتبطة بالكود الذي تم إنشاؤه. يتبع الوكلاء تلك الروابط، بحيث لا يتم إعادة إنشاء التصميم نفسه في مكان آخر.
- مراجعات متعددة الزوايا – يقوم ثلاثة وكلاء بفحص جزء مختلف من العمل (النص الكامل، أو المخرجات فقط، أو الكود فقط). تكتشف عملية التحقق المتبادل هذه التناقضات التي قد تغفل عنها الرؤية الواحدة.
- أدلة ميدانية ذاتية الصيانة – يحتفظ الوكلاء بـ "مجلد معرفي" يحتوي على النتائج المفاجئة والعثرات. عندما يبدأ وكيل تنفيذ جديد، فإنه يستشير المجلد لتجنب تكرار الأخطاء المعروفة، مما يوفر ذاكرة قصيرة المدى عبر السرب.
تحافظ هذه التدابير على تماسك قاعدة الكود (codebase) رغم سيل التغييرات.
معايير الأداء المهمة
اختبر Cursor السرب الهجين من خلال إعادة بناء دليل SQLite بالكامل – وهو تنفيذ بلغة Rust يتكون من 835 صفحة – وهي مهمة تضع الدقة والحجم تحت الاختبار الشديد. كانت النتائج صارخة:
- الدقة – حقق التكوين الهجين (المخطط + وكلاء Composer) دقة بنسبة 100%، متفوقًا باستمرار على التشغيل المنفرد لأكثر النماذج تقدمًا المشار إليها (GPT-5.5).
- حجم الكود – أنتج السرب الهجين 9,908 سطرًا من كود المحرك، مقابل 64,305 سطرًا من السرب الأحادي القديم.
- التكلفة – بلغت تكلفة تشغيل نسخة منفردة من GPT-5.5 حوالي 10,565 دولارًا. بينما أنفق النهج الهجين 411 دولارًا فقط على أسطول الوكلاء.
يعود فارق التكلفة إلى Composer 2.5، الذي تصفه المسودة بأنه يقدم أداءً يضاهي النماذج الرائدة مع فرض جزء بسيط من سعر المليون رمز (token). ومن خلال توجيه معظم استهلاك الرموز إلى هذا النموذج الأرخص، يحافظ السرب على انخفاض التكلفة الإجمالية دون التضحية بالجودة.
الخلاصة
- إن الجمع بين مخطط قوي ومنفذ رخيص يحقق مكاسب هائلة في السرعة، وتراص الكود، والتكلفة.
- يقضي التصميم على انحراف السياق من خلال تخصيص "ماذا" للنماذج الرائدة و"كيف" للنماذج المتخصصة.
- تظل الأعباء التشغيلية ومتطلبات البنية التحتية هي أكبر العقبات أمام التبني على نطاق أوسع.