عندما أطلقت ميتا "Muse Code" هذا الأسبوع، كان العنوان الرئيسي يتعلق بالتموضع التنافسي: وكيل برمجي آخر يعمل عبر الطرفية (Terminal) وينضم إلى Claude Code وCodex وCursor في معركة استحواذ سير عمل المطورين. لكن المخفي في وصف مارك زوكربرغ نفسه للأداة يحمل إشارة أكثر إثارة للاهتمام لكل من يكتب أو يراجع الكود لكسب عيشه.
كتب زوكربرغ واصفًا طريقة تعامل Muse Code مع المهام الكبيرة: "عندما تكون المهمة كبيرة بما يكفي، تتفرّع إلى وكلاء فرعيين منفصلين يعملون بالتوازي في نُسخ عمل (worktrees) معزولة. نسختك العاملة لا تُمس أبدًا. في الاختبار، جعلناه يبني ست ميزات للعبة في آنٍ واحد دون أي تصادم."
هذا ليس وصفًا لميزة. إنه وصف وظيفي — لك أنت.
ماذا تعني "نُسخ العمل المعزولة" فعليًا
نُسخة عمل git (worktree) تتيح لك سحب عدة فروع من المستودع نفسه إلى مجلدات منفصلة في آنٍ واحد، بحيث يمكن لعدة خطوط عمل أن تتقدّم دون أن يتعارض أحدها مع الآخر. ووفقًا لرواية ميتا، يستخدم Muse Code هذه الآلية للسماح لعدة وكلاء فرعيين بكتابة الكود في الوقت نفسه دون المساس بنسخة عملك الحيّة أو بملفات بعضهم البعض. إنه خيار هندسي منطقي: فالتصادمات على مستوى الملفات هي أسهل أنواع تعارض الوكلاء المتعددين التي يمكن منعها آليًا، فتمنعها آليًا وتُحرّر النموذج للتركيز على البرمجة الفعلية.
الكلمة الجديرة بالملاحظة هي "تتفرّع". فالمطوّر البشري لا يختبر ست نُسخ عمل متوازية كستة تيارات من الكود يفحصها يدويًا واحدًا تلو الآخر بالتسلسل — بل تصله ستة تيارات تقريبًا في الوقت نفسه، كل منها يحتاج إلى قرار: هل يُدمج هذا؟ هل يحتاج إلى إعادة عمل؟ هل يتعارض مع شيء قام به للتو وكيل شقيق في نسخة عمل أخرى؟
المهارة التي تتغيّر فعليًا
على مدى العامين الماضيين، كان النموذج السائد للبرمجة بمساعدة الذكاء الاصطناعي حواريًا وفرديًا: مطوّر واحد، ومساعد واحد، وخيط واحد من الحوار المتبادل، يُراجَع تقريبًا في الوقت الفعلي أثناء إنتاجه. تلك المهارة — صياغة الطلبات بشكل جيد، والتقاط اقتراح سيئ لحظيًا، والتكرار — ما زالت ضرورية. لكنها ليست المهارة التي يُحسّن تصميم Muse Code من أجلها. فالتفرّع إلى وكلاء فرعيين يفترض أنك انتقلت بالفعل إلى نمط عمل مختلف: تفكيك المهمة مسبقًا إلى أجزاء يمكن أن تعمل بشكل مستقل، ثم مراجعة المخرجات المكتملة (أو شبه المكتملة) من عدة وكلاء في آنٍ واحد بدلًا من توجيه وكيل واحد خطوة بخطوة.
هذا أقرب إلى دور قائد تقني يوزّع سباقًا برمجيًا (sprint) على فريق صغير، من كونه مبرمجًا يعمل بنظام الشاشة المزدوجة مع روبوت محادثة. فقرارات البرمجة الفردية تصبح أقل أهمية من عملية التفكيك (هل قسّمت العمل وفق خطوط مستقلة فعليًا؟) ومن مرور المراجعة (هل يمكنك أن تحدد، بسرعة، ما إذا كانت ست فروقات (diffs) متوازية صحيحة كل على حدة و متسقة مجتمعةً؟).
العزل يحل مشكلة التصادمات، لا مشكلة الاتساق
من الجدير التوقف عندها، لأنها نقطة يسهل إغفالها: نُسخ العمل المعزولة تمنع وكيلين من الكتابة فوق الملف نفسه. لكنها لا تفعل شيئًا لمنع وكيلين من ابتكار طريقتين مختلفتين بشكل مستقل لأداء الأمر نفسه — دالة مساعدة ثانية لتنسيق التاريخ، غلاف إعادة محاولة ثانٍ، مسار API مكرر — لأن كل وكيل لم يكن يرى ما يبنيه الآخر. فعزل git ضمانة على مستوى نظام الملفات، لا ضمانة تصميمية. والمراجع الذي يدمج ست نُسخ عمل معًا هو نقطة التفتيش الوحيدة التي يمكن أن يُكتشف عندها تجريد مكرر، أو تسمية غير متسقة، أو ميزتان تفترضان بصمت شكلين مختلفين للبيانات. وإذا كان ذلك المراجع يتصفح الفروقات (diffs) سريعًا لأن حجم المخرجات المتوازية يفوق قدرته على القراءة المتأنية، فهذا بالضبط نوع الانحراف الذي ينتهي به الأمر إلى النشر.
هذا يعيد صياغة ما يجب أن تعنيه "مراجعة الكود" بمجرد أن تصبح أدوات التفرّع أمرًا معتادًا: فحص أقل سطرًا بسطر لأي فرق (diff) منفرد (فبنية الوكيل النحوية سليمة غالبًا)، ومطابقة أكبر بين الفروقات المختلفة — التحقق من أن تيارات العمل المتوازية المُولّدة بالذكاء الاصطناعي تتفق فيما بينها على الاصطلاحات المشتركة، ونماذج البيانات المشتركة، ومعالجة الأخطاء المشتركة.
ما الذي ينبغي العمل من أجله فعليًا
لا شيء من هذا يتطلب Muse Code تحديدًا — فنمط التفرّع نفسه يظهر عبر معظم وكلاء البرمجة الرئيسيين، وهو ما يوحي بأنه بات يتحول إلى بنية معمارية افتراضية بدلًا من كونه رهانًا خاصًا بمزوّد واحد. إليك بعض الأمور الملموسة التي يستحق التدرّب عليها الآن، بغض النظر عن الأداة التي تستخدمها:
- اكتب مواصفات مهام تُفكَّك بشكل نظيف. قبل أن تطلب عملًا متوازيًا، اسأل نفسك ما إذا كانت الأجزاء مستقلة فعليًا — هل تمس الملفات نفسها، أو الثوابت المشتركة نفسها، أو عقد API نفسه؟ إذا كانت الإجابة نعم، فهذه ليست مهمة لستة وكلاء متوازين؛ بل مهمة لوكيل واحد يعمل بالتسلسل، أو لك أنت لتفصل الأجزاء المشتركة يدويًا أولًا.
- تدرّب على المراجعة عند نقطة الدمج، لا عند نقطة الفرق (diff). اعتد على سحب عدة فروع مكتملة جنبًا إلى جنب وطرح السؤال "هل يتفق هذان مع بعضهما البعض؟"، لا الاكتفاء بالسؤال "هل كل منهما صحيح على حدة؟"
- أتقن أساسيات نُسخ عمل git. إذا كانت الأدوات التي تستخدمها ستصف آليات عملها الداخلية بهذه الطريقة، فإن فهم ما تضمنه نسخة العمل وما لا تضمنه هو الحد الأدنى اللازم للثقة بالمخرجات — أو لعدم الثقة بها بالشكل الصحيح.
- كن واضحًا صراحةً بشأن ملكية العناصر المشتركة. الثوابت، والمخططات (schemas)، والأدوات المساعدة المشتركة، واصطلاحات التسمية. فكلما ثبّتّ عددًا أكبر من هذه العناصر قبل بدء التفرّع، قلّ عمل المطابقة الذي ستحتاجه لاحقًا.
الأشخاص الذين سيحققون أكبر استفادة من أدوات مثل Muse Code لن يكونوا أولئك الأفضل في صياغة الطلبات. بل سيكونون أولئك الذين أتقنوا بهدوء إدارة فريق صغير وسريع، وأحيانًا غير منظم — حتى عندما يكون كل عضو في ذلك الفريق مجرد نموذج.
