ما يكشفه نظام Task في Claude Code عن المهندس الأصيل في عصر الذكاء الاصطناعي

الأسبوع الماضي، غيّر Claude Code بهدوء اسم Todo إلى Task. يبدو وكأنه مجرد تغيير في المصطلحات، لكنه في الحقيقة بداية نظام مختلف تمامًا.

كان Todo قائمة يحتفظ بها Claude بمفرده - ذاكرة شخصية لوكيل واحد. أما Task فهو وحدة عمل مشتركة بين وكلاء متعددين. هذا الفرق يغيّر نموذج أدوات البرمجة بالذكاء الاصطناعي.

بعبارة أخرى، ظهرت وحدة تجريد جديدة ضرورية لأسراب الذكاء الاصطناعي.

الجوهر هو التفويض، لا الأتمتة

كان Claude Code القديم عقلًا واحدًا. أسنِد إليه مشروعًا معقدًا وسينسى الخطوات السابقة في منتصف الطريق، مما يجبرك على إعادة البدء عند حدود 60% مرارًا وتكرارًا.

نظام Task الجديد يملك بنية مختلفة جذريًا:

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

هذا ليس أتمتة - إنه تفويض. الفرق مهم. الأتمتة تعني كتابة سكريبت لتسلسل معروف. التفويض يعني تحديد النتائج والثقة بفريق منظّم ليجد مسار التنفيذ بنفسه.

رسم الاعتماديات هو السلاح الحقيقي

الميزة الجوهرية في نظام Task هي الاعتماديات بين المهام (blockedBy). المهمة 3 لا يمكنها أن تبدأ حتى تكتمل المهمتان 1 و2.

لماذا هذا مهم؟

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

الآن، الخطة نفسها مُهيكلة ومخزّنة خارجيًا. حتى لو ضُغط السياق أو استُبدل وكيل، تبقى الخطة قائمة. رسم الاعتماديات يعمل كطبقة تنسيق دائمة تتجاوز ذاكرة أي وكيل فردي.

المعالجة المتوازية تأتي مجانًا

أسنِد سبع إلى عشر مهام ولن يعالجها النظام بالتتابع بعد الآن. المهام التي لا تعتمد على بعضها تعمل في وقت واحد. عمليات البحث السريعة تذهب إلى Haiku، والتنفيذ إلى Sonnet، والقرارات المعقدة إلى Opus - توزيع النماذج يحدث تلقائيًا بناءً على خصائص كل مهمة.

هذه نتيجة مباشرة لتصميم مهام مُهيكل. كلما كان تحليل العمل أنظف والاعتماديات أوضح، استخرج النظام توازيًا أكبر. أنت لا تحسّن التوازي صراحة - بل تحصل عليه كمنتج ثانوي لبنية مهام جيدة.

العمل يصبح تنسيقًا

وثائق Swarm تكشف أنماطًا واضحة:

• Parallel Specialists: عدة خبراء يراجعون في آن واحد - الأمان، الأداء، فحص الأنواع، كلها معًا.
• Pipeline: بحث → تخطيط → تنفيذ → اختبار - مراحل متتابعة تعتمد كل منها على سابقتها.
• Self-Organizing Swarm: الوكلاء يسحبون من مجموعة مهام مشتركة، يختارون ما ليس محجوبًا ولا مُسندًا.

العمل لم يعد كتابة كود. العمل أصبح تصميم أي الوكلاء يفعلون ماذا، بأي ترتيب، ومع أي اعتماديات بينهم.

كفاءة السرب تعتمد على تصميم المهام

هناك ثلاث رافعات لتحسين أداء السرب:

• دقة تقسيم المهام: المهام الأصغر ترفع معدل التوازي، لكن تكاليف التواصل بين الوكلاء تزداد مع كل تقسيم.
• فصل الأدوار: التخصص يحسّن الجودة، لكنه قد يخلق اختناقات عند وكلاء يتحملون أعباءً غير متناسبة.
• تصميم الاعتماديات: هيكلة ما يجب أن ينتهي قبل أن تنطلق الخطوة التالية دون انسداد - هذه هي طوبولوجيا سير عملك.

من تجاربي الشخصية، الرافعة الثالثة لها التأثير الأكبر. دقة التقسيم وفصل الأدوار أمران بديهيان نسبيًا. تصميم الاعتماديات يتطلب التفكير في شكل العمل ذاته - ما أسميه تصميم طوبولوجيا الاعتماديات.

هذه هي المهارة الحقيقية في عصر السرب. ليست كتابة كود أسرع أو اختيار نماذج أفضل. بل هيكلة تدفق العمل بحيث يتمكن أكبر عدد من الوكلاء من العمل دون انتظار.

من كتابة الكود إلى تصميم طريقة العمل

المسار واضح:

في البداية، كنا نكتب الكود. ثم صرنا نصمم الأنظمة. الآن، نصمم الطريقة التي يُنجز بها العمل ذاته.

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

التغيير من Todo إلى Task يبدو صغيرًا على السطح. لكن تحته، تُرسى أسس عالم يكون فيه الناتج الرئيسي للمهندس ليس الكود - بل هندسة التعاون بين الآلات.