الـ workflows الديناميكية: حين يبني Claude الـ harness الخاص به

صُمّم Claude Code في وضعه الافتراضي للـ coding، وتبيّن أن قدرًا مفاجئًا من العمل يشبه الـ coding بما يكفي ليتعامل معه الأداة نفسها على نحو جيّد. لكن هناك صنفًا من المهام يبدأ فيه Claude واحد — يفكّر ويُنفّذ داخل محادثة واحدة — في التعثّر: المهام الطويلة جدًا، أو المتوازية على نطاق واسع، أو ذات الطابع التنافسي (adversarial) بطبيعتها. لهذه المهام، اضطر الفريق تاريخيًا إلى بناء harnesses مخصّصة يدويًا — للـ deep research، وتحليل الأمان، وcode review، وما شابه.

تُلغي الـ dynamic workflows هذا التمييز. فبدلًا من أن يبني أحدهم harness مسبقًا، يكتب Claude واحدًا في اللحظة — برنامج JavaScript صغير، مُفصّل على مقاس المهمة التي بين يديه، يُطلق أسطولًا من الـ subagents ويُنسّق بينها. ويمكنك حفظ الجيّد منها، وإعادة تشغيلها، ومشاركتها مع فريقك.

تنبيه في البداية: هذا جديد، ولا تزال أفضل الممارسات قيد التبلور. تميل الـ workflows إلى استهلاك tokens أكثر من طلب عادي، لذا فإن المهارة الحقيقية هي معرفة متى يستحق الـ compute الإضافي عناءه. ومعظم هذا الدليل يدور حول هذا الحكم بالتحديد.

لماذا تتكبّد العناء — أنماط الفشل التي يُصلحها الـ workflow

حين تُسلّم الـ harness الافتراضي مهمة، يكون عليه أن يُخطّط ويُنفّذ في الـ context window نفسها. وبالنسبة للـ coding العادي، هذه ميزة. لكن كلما طال اشتغال Claude واحد على مهمة معقّدة، انجرّ أكثر نحو ثلاثة فخاخ متوقّعة:

• التوقّف مبكرًا. في مهمة كبيرة متعدّدة الأجزاء، قد يعتبر Claude العمل منتهيًا بعد تقدّم جزئي — يُصلح 20 من أصل 50 مشكلة مرصودة ويُعلن النصر. والـ checklists الطويلة هي حيث يؤلم هذا أكثر.
• تصحيح واجبه بنفسه. حين يُطلب منه أن يتحقّق من مخرجاته أو يحكم عليها وفق rubric، يميل Claude إلى الموافقة عليها. فالمراجِع الذي كتب الشيء نفسه مراجِعٌ متساهل.
• فقدان الخيط. عبر turns كثيرة — خصوصًا بعد أن تُلخَّص المحادثة لتوفير المساحة — يتشوّش الهدف الأصلي. فقيد «لا تفعل X» أو الـ edge case الذي ذكرته قبل ساعة يغيب بهدوء عن الأنظار.

يهاجم الـ workflow الثلاثة جميعًا بنيويًا. فكل subagent يحصل على context نظيفة خاصة به وهدف واحد ضيّق ومحدّد جيّدًا. والـ agent الذي يتحقّق من نتيجة هو agent مختلف عن الذي أنتجها. ولأن الـ orchestration هو script حتمي (deterministic)، لا يمكن للهدف الأصلي أن ينجرف — فالـ loop يُمسكه.

الـ workflows الديناميكية مقابل الساكنة (static)

إن سبق أن نسّقت بين عدة نسخ من Claude — باستخدام الـ Agent SDK، أو بكتابة scripts لاستدعاءات claude -p — فقد بنيت workflow ساكنًا (static). تُكتب هذه مسبقًا وعليها أن تُغطّي كل حالة، فتأتي عامة في النهاية. أما الـ dynamic workflow فيقلب ذلك: صار Claude الآن قادرًا بما يكفي على كتابة harness مُفصّل على مقاس مهمتك أنت تحديدًا، في اللحظة التي تطلبه فيها. أقرب إلى «الـ script الذي تحتاجه هذه الـ migration» منه إلى «script واحد لكل الـ migrations».

الأنماط الجديرة بالمعرفة

يمكنك تشغيل workflow بمجرد طلبه بلغة طبيعية (أو بكلمة ultracode، التي تُخبر Claude Code أن يلجأ إلى واحد). لكن من المفيد أن تتعرّف على الأشكال التي يُركّب منها Claude — فهي المفردات التي ستستخدمها لتوجيهه:

• Fan-out and synthesize (التوزيع ثم التجميع). قسّم المهمة إلى أجزاء صغيرة كثيرة، شغّل agent على كلٍّ منها، ثم ادمج النتائج. والدمج حاجز (barrier): ينتظر الجميع قبل أن يجمع مخرجاتهم. الأفضل حين تكون هناك خطوات صغيرة كثيرة، أو حين تحتاج كل خطوة إلى context نظيفة كي لا تُلوّث الواحدة الأخرى.
• Adversarial verification (التحقّق التنافسي). لكل agent يُنتج نتيجة، أطلِق agent منفصلًا مهمته مهاجمتها وفق rubric. هذا هو الترياق لمشكلة تصحيح الواجب الذاتي.
• Generate and filter (التوليد ثم التصفية). اعصف ذهنيًا لتوليد كومة من المرشّحين، ثم صفِّ وفق rubric أو عبر verification، واحذف المكرّر، وأعِد ما نجا فقط.
• Tournament (البطولة). بدلًا من تقسيم العمل، اجعل الـ agents تتنافس عليه — عدد N من الـ agents يحاول كلٌّ منها المهمة نفسها بطريقة مختلفة، ثم يقارن بينها حُكّام ثنائيًا (pairwise) حتى يفوز واحد. فالمقارنة أكثر موثوقية من التقييم المطلق.
• Classify and route (التصنيف ثم التوجيه). يُقرّر agent مُصنِّف نوعَ هذه المهمة، ثم يُرسلها إلى المتخصّص المناسب — أو يعمل في النهاية لتشكيل المخرجات.
• Loop until done (التكرار حتى الانتهاء). حين لا تعرف حجم العمل، استمر في إطلاق agents حتى يتحقّق شرط توقّف — لا نتائج جديدة، ولا أخطاء متبقية في الـ logs — بدلًا من تخمين عدد ثابت من المرّات.

وهذه الأنماط تتركّب. فمراجعة جادّة قد توزّع (fan out) عبر عدة أبعاد، وتتحقّق من كل نتيجة تنافسيًا، ثم تُكرّر حتى لا تأتي جولتان بأي جديد.

أين تتألّق الـ workflows

المفاجئ هو كم مرّة تكون أكبر المكاسب في عمل غير برمجي. إليك عيّنة:

• Migrations وrefactors. قسّم التغيير إلى وحدات — مواضع الاستدعاء (call sites)، والـ tests الفاشلة، والـ modules — وأعطِ كلًّا منها subagent خاصًا به يعمل في worktree معزول، مع agent ثانٍ يراجع الإصلاح قبل أن يُدمج (merge). (اعتمدت إعادة كتابة Bun من Zig إلى Rust على هذا بالضبط.) نصيحة: اطلب من الـ agents تجنّب الأوامر الشرهة للموارد كي تتمكّن من تشغيل الكثير منها بالتوازي دون أن تُذيب جهازك.
• Deep research. وزّع عمليات البحث، واجلب المصادر، وافحص كل ادّعاء تنافسيًا، واصنع تقريرًا موثّقًا بالمراجع. وهي ليست للويب فقط — وجّه الشكل نفسه نحو Slack لتجميع تحديث حالة، أو نحو codebase لفهم كيف يعمل feature فعلًا. (يأتي Claude Code مع skill باسم /deep-research مبني على هذا.)
• التحقّق من صحّة مستند. يستخرج agent كل ادّعاء واقعي من مسودّة؛ ويتحقّق subagent من كل واحد بالتفصيل مقابل المصدر؛ بل يمكن لثالث أن يُدقّق فيما إذا كان المصدر جديرًا بالثقة. مفيد قبل أن تُطلق أي شيء لا تحتمل أن تُخطئ فيه.
• الفرز النوعي. ترتيب 1000 support ticket حسب الخطورة لن يتّسع في context واحدة، وتتدهور الجودة إن حاولت. بدلًا من ذلك، نفّذ مقارنات ثنائية (pairwise) على شكل tournament، أو رتّب ضمن دلاء (bucket-rank) بالتوازي ثم ادمج. كل مقارنة هي agent خاص بها؛ ويُمسك الـ script شجرة البطولة (bracket) كي يبقى في الـ context ترتيب التشغيل فقط.
• التحقيق في السبب الجذري. الـ debugging الجيّد يعني عدة فرضيات مستقلّة، تُختبر بإنصاف — لكن context window واحدة تُغري النموذج بتفضيل تخمينه الأول. يُسنِد الـ workflow agents منفصلة إلى أدلّة متباينة (logs، ملفات، بيانات)، ويُولّد نظريات متنافسة، ويضع كلًّا منها أمام لجنة من المتحقّقين والمُفنِّدين. يصلح لسؤال «لماذا انخفضت المبيعات في مارس؟» بقدر ما يصلح لـ stack trace.
• الفرز على نطاق واسع (triage). صنّف كل عنصر في الـ backlog، وأزِل تكراره مقابل ما هو مُتتبَّع أصلًا، ثم إمّا أصلحه أو صعّده. ومن أنماط الأمان هنا الحجر (quarantine): الـ agents التي تقرأ محتوى عامًا غير موثوق لا يُسمح لها باتخاذ إجراءات ذات صلاحية — بل تتصرّف بناءً على المعلومة agents منفصلة. اقرنه بـ /loop كي يعمل باستمرار.
• الذوق والاستكشاف. التسمية، والتصميم، وأي شيء يُحكم عليه بالإحساس يستفيد من rubric. ولّد خيارات كثيرة، وسلّم agent المراجعة معايير «الجيّد»، ودع tournament يُرتّبها. تنتهي المهمة حين يقتنع المراجِع.
• Evals خفيفة وفحص القواعد. قارن المخرجات بـ rubric لتحسين skill، أو افرض قواعد CLAUDE.md التي يُغفلها Claude باستمرار — agent مُتحقّق واحد لكل قاعدة، إضافة إلى شخصية متشكّكة (skeptic) لإبقاء النتائج الإيجابية الكاذبة منخفضة. والعكس ينجح أيضًا: نقّب في sessions الأخيرة عن التصحيحات التي تُكرّرها، اجمعها في عناقيد، تحقّق من أن كلًّا منها كان سيمنع خطأً حقيقيًا، ثم اخلُص الناجين منها إلى ملف الـ memory الخاص بك.
• Model routing (توجيه النموذج). يمكن لمُصنِّف أن يبحث في مهمة أولًا — كم عدد الملفات في module الـ auth، وما شكل الـ codebase — ثم يُوجّه إلى model أسرع أو أقدر بناءً على ما وجده من تعقيد. (دليلنا حول أي model تستخدم يتناول المفاضلات يدويًا.)

بعض الـ prompts لتسرقها

أسرع طريقة لاستشعار الأمر هي رؤية الطلبات، لا النظرية:

هذا الـ test يفشل مرة واحدة تقريبًا من كل 50 تشغيلًا. أنشئ workflow لإعادة
إنتاجه، وصياغة نظريات، واختبار كل واحدة تنافسيًا في worktree خاص بها. لا تتوقّف
حتى تصمد نظرية.
This test fails about 1 in 50 runs. Set up a workflow to reproduce it, form
theories, and adversarially test each one in its own worktree. Don't stop
until a theory holds.

استخدم workflow للتنقيب في ستة أشهر من #incidents في Slack وإبراز الأسباب
الجذرية المتكرّرة التي لم يُسجّل لها أحد ticket قط.
Use a workflow to dig through six months of #incidents in Slack and surface
recurring root causes where nobody ever filed a ticket.

خذ خطة عملي وشغّل workflow تُمزّقها فيه agents مختلفة من وجهة نظر مستثمر،
وعميل، ومنافس.
Take my business plan and run a workflow where different agents tear it apart
from an investor's, a customer's, and a competitor's point of view.

إليك مجلدًا فيه 80 سيرة ذاتية. استخدم workflow لترتيبها للدور الـ backend
وتدقيق أفضل عشرة. أجرِ معي مقابلة لتحديد الـ rubric أولًا.
Here's a folder of 80 resumes. Use a workflow to rank them for the backend
role and double-check the top ten. Interview me for the rubric first.

راجع مسودّة مدوّنتي واستخدم workflow للتحقّق من كل ادّعاء تقني مقابل الـ
codebase. لا أريد أن أُطلق أي شيء خاطئ.
Go through my blog draft and use a workflow to verify every technical claim
against the codebase. I don't want to ship anything wrong.

متى لا تلجأ إلى واحد

هذا هو الجزء الذي يتطلّب انضباطًا. الـ workflows جديدة وقوية فعلًا، ما يجعلها مُغرية للإفراط في استخدامها — وقد تُكلّف tokens أكثر بفارق ملموس. قبل أن تُطلق واحدًا، اسأل السؤال الصادق: هل تحتاج هذه المهمة فعلًا إلى compute أكثر؟ معظم الـ coding العادي لا يحتاج. المراجعة العادية لا تحتاج إلى لجنة من خمسة مراجعين؛ وعملية rename واحدة لا تحتاج إلى أسطول. احفظ الـ workflows للمهام الكبيرة أو المتوازية أو التنافسية بشكل لا تحتمله context واحدة — ودع كل ما عداها بسيطًا. (إن أردت العادات اليومية بدلًا من الآلات الثقيلة، فذلك دليلنا الرفيق، 9 workflows في Claude Code توفّر الوقت فعلًا.)

بعض النصائح العملية

• استخدم الأنماط في الـ prompt. كلما كنت أكثر تحديدًا — بتسمية fan-out وverification وtournament — كان الـ harness الذي يكتبه Claude أفضل. فالطلبات الغامضة تُنتج orchestration غامضًا.
• الـ workflows قد تكون صغيرة. لا تحتاج إلى مهمة عملاقة. اطلب «workflow سريعًا» لإجراء فحص تنافسي خاطف على افتراض واحد.
• اقرنه بـ /loop و/goal. المهام القابلة للتكرار — triage، وبحث، وverification — تعمل جيّدًا على فترات بـ /loop، ويضع /goal خط نهاية صارمًا لا يستطيع الـ workflow أن يُعلن بهدوء أنه تجاوزه.
• حدّد ميزانية tokens. يمكنك تحديد سقف الإنفاق داخل الـ prompt مباشرة: «استخدم 10k tokens» يضع السقف، كي لا يهرب workflow طموح بفاتورتك.
• احفظ وشارك. اضغط s في قائمة الـ workflow للاحتفاظ بواحد جيّد. أضِفه إلى ~/.claude/workflows، أو ضمّنه داخل skill — وحين تفعل، اطلب من Claude أن يتعامل مع الـ script المحفوظ بوصفه template يُكيّفه، لا وصفة يُشغّلها حرفيًا.

الصورة الأكبر

الـ dynamic workflow، في جوهره، هو أن يلاحظ Claude أن عقلًا واحدًا في context واحدة ليس الشكل المناسب للمشكلة — فيُجمّع فريقًا يكون كذلك. وهذا نوع من الرافعة مختلف عن «Claude أسرع». ويجدر التعامل مع هذا بوصفه نقطة بداية لا playbook مكتملًا: فالأنماط أعلاه أساس، وأكثر الاستخدامات إثارة للاهتمام هي على الأرجح تلك التي لم يجرّبها أحد بعد. وجّه واحدًا نحو مشكلة كانت أكبر من أن تُمسكها في رأسك، وانظر ماذا يعود.