دروس في تشغيل جلسات Claude Code المتوازية

ما تعلمته من تشغيل ثلاث أو أربع جلسات Claude Code في آن واحد أثناء بناء Read Master (يُفتح في علامة تبويب جديدة) — تطبيق بالذكاء الاصطناعي لفهم القراءة والاحتفاظ بها — على جهاز Mac بمعالج Intel عمره ست سنوات.

كيف كُتب هذا المقال: كتب Claude المسودة الأولى (في واحدة من الجلسات المتوازية التي يصفها المقال نفسه)، ثم راجعتها وحررتها ودققت وقائعها بنفسي. الحوادث والأرقام حقيقية، وكلها من مشروعي.

في صباح أحد أيام أغسطس، بلغ متوسط الحِمل على جهازي 214.

متوسط الحِمل (load average) هو الرقم الذي يحتفظ به نظام التشغيل عن حجم العمل المنتظر في طابور المعالج. جهازي فيه 16 نواة منطقية، فحِمل قدره 16 يعني أن كل نواة مشغولة. أما حِمل قدره 214 فيعني أن في الطابور ما يعادل عمل ثلاثة عشر جهازًا مكدسًا على جهاز واحد. تلعثم المؤشر. انتهت مهلات الاختبارات. ومات أمر git push في منتصف خطافاته.

لم يكن السبب خللًا برمجيًا. ثلاث جلسات Claude Code قررت كل واحدة منها، باستقلال وفي اللحظة نفسها، أن الوقت قد حان لتشغيل حزمة الاختبارات كاملة. وكانت كل واحدة تنفذ ما طلبته منها بالضبط.

هذه هي المشكلة الجوهرية في تشغيل وكلاء البرمجة بالذكاء الاصطناعي على التوازي: لا يرى بعضهم بعضًا. يتحول جهازك إلى مورد مشترك لا يديره أحد، ويتحول تاريخ git عندك إلى الساحة التي تتصادم فيها أعمالهم، وتتحول أنت إلى مجدوِل المهام سواء رضيت بهذا الدور أم لا.

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

عتادي، لتترجمه إلى بيئتك

الجهاز: Mac بمعالج Intel من 2019 — 8 أنوية / 16 خيطًا، وذاكرة 64 غيغابايت. ليس Apple Silicon. إن صمدت هذه الأرقام على جهاز Intel عمره ست سنوات، ففي حاسوبك بمعالج M متسع وزيادة.
الحزمة التقنية: مستودع أحادي (monorepo) بلغة TypeScript على Bun، وTurborepo لتشغيل المهام، وTanStack Start للتطبيق، وVitest وPlaywright للاختبارات، وPrisma مع Postgres في الأساس.
نظام التشغيل: macOS. على Linux استبدل بـsysctl -n vm.loadavg الأمر cat /proc/loadavg، وبـtaskpolicy -c utility الأمر nice.

أسماء متغيرات البيئة أدناه (VITEST_MAX_THREADS وPW_WORKERS وغيرها) هي مفاتيح حزمتي أنا. لكل مشغّل اختبارات ما يكافئها؛ ترجمها إلى بيئتك.

الدرس 1: ضع الميزانية للأطوار الثقيلة لا لعدد الجلسات

أول سؤال يطرحه الجميع: "كم جلسة أستطيع تشغيلها؟" وهو سؤال بوحدة قياس خاطئة.

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

أرقامي على 16 خيطًا:

3–4 جلسات نشطة هي النقطة المثلى. خمس فأكثر لا تنجح إلا إذا كان معظمها متوقفًا ينتظر.
جلستان في طور ثقيل على الأكثر في أي لحظة.
المسوح الشاملة للمستودع (فحص كامل، تدقيقات، تعديلات جماعية): واحد في كل مرة على مستوى الجهاز كله.

الحساب بسيط: تشغيلا اختبارات مقيّدان يعنيان نحو 8 عمال مشغولين، إضافة إلى خوادم التطوير ومتصفح. هذا يتسع في 16 خيطًا. الحزمة الثالثة هي التي أوصلت جهازي إلى حِمل 214.

الحيلة التي تجعل الميزانية تصمد هي إزاحة الأطوار: أبقِ جلساتك في مراحل مختلفة من دورة حياتها. واحدة تخطط (مجانية)، وواحدة تنفذ (خفيفة)، وواحدة تتحقق (ثقيلة)، وواحدة تراقب CI (مجانية). العدد نفسه من الجلسات، والتصادمات تتوقف من تلقاء نفسها في الغالب.

جرّبها: في المرة القادمة التي تشغّل فيها عدة جلسات، لاحظ كم منها في طور ثقيل. إن كانت الإجابة يومًا "كلها"، فقد وجدت مشكلتك.

اجعلها تلقائية: الأداة الأولى هي ملف CLAUDE.md — تعليمات دائمة تقرؤها كل جلسة عند بدئها. عندي فيه قسم قصير يلتزم به الوكلاء فعلًا:

## Parallel-session limits (all sessions)

- Before any suite-wide test/lint/build: check `sysctl -n vm.loadavg`.
  If the 1-min load is above ~16, wait 2-3 minutes and re-check, or run
  something smaller (one test file, one package).
- At most two suite runs on this machine at once.
- Repo-wide sweeps: one session at a time.

التعليمات وحدها لن تصمد عند أول احتكاك بالواقع (هذا هو الدرس 3)، لكنها الطبقة الأولى الصحيحة، ولا تكلف سوى خمس دقائق.

الدرس 2: اقرأ متوسط الحِمل كما يقرأ الطيار فحص ما قبل الإقلاع

تستطيع قراءة الحِمل في أي وقت:

# macOS: 1-min, 5-min, 15-min averages
sysctl -n vm.loadavg

# Linux
cat /proc/loadavg

عتباتي على 16 خيطًا: تحت ~16 انطلق. بين 16 و20 انتظر دقيقتين أو قلّص النطاق. فوق 20 لا يبدأ شيء ثقيل، بلا استثناءات.

النصف الأقل بداهة من هذا الدرس: تحت الحِمل الثقيل، تكذب الإخفاقات. حين يتشبع الجهاز رأيت اختبارات عمليات فرعية "تفشل" بـexitCode: null ومخرجات فارغة، ورأيت سباق singleton واحدًا يسقط أكثر من 100 اختبار لا علاقة بينها، ورأيت دفعات git تنتهي مهلتها في منتصف الخطافات. لم يكن أي من ذلك خللًا حقيقيًا. كان تجويع معالجة يرتدي زيّ الخلل.

فقاعدة التنقيح إذن: حين ترى عددًا كبيرًا مريبًا من إخفاقات لا رابط بينها، شغّل uptime قبل أن تصدق أيًا منها. إن كان الحِمل مرتفعًا فانتظر حتى يهدأ الجهاز، ثم أعد تشغيل الاختبار الفاشل وحده. لا تكرر المحاولة في حلقة — فالمحاولات تضيف حِملًا — ولا تتجاوز خطافات git لتمرّ.

وأمر أخير ما دمنا هنا: لا تقس أداءً على جهاز يشغّل جلسات متوازية. حزمة اختباراتي فيها أرضية ضجيج تبلغ ~40 ثانية من الخنق الحراري وحده. أي فرق دون 10% هو حالة طقس، لا إشارة.

جرّبها: اجعل للأمر أعلاه اختصارًا باسم load. وافحصه قبل أي شيء ثقيل.

اجعلها تلقائية: ضع الحِمل في سطر الحالة، ليصبح فحص ما قبل الإقلاع جوًا محيطًا لا طقسًا تؤديه. يتيح Claude Code سطر حالة مخصصًا في ~/.claude/settings.json:

"statusLine": { "type": "command", "command": "bash ~/.claude/statusline.sh" }

#!/bin/bash
# statusline.sh — whatever you already display, plus the 1-min load
load=$(sysctl -n vm.loadavg | awk '{print $2}')
echo "$(git branch --show-current 2>/dev/null) | load $load"

نسختي تلوّنه: أخضر تحت 16، أصفر حتى 20، أحمر فوقها. كل جلسة الآن تريني حرارة الجهاز بلمحة، والوكلاء يرونها أيضًا.

الدرس 3: اجعل الجهاز هو من يفرض القواعد

كتبت "لا تبدأ حزمة ثالثة" في تعليماتي. نجح الأمر في الغالب. وكلمة "الغالب" تحمل هنا ثقلًا حقيقيًا — فالوكيل الغارق في دوامة تنقيح سيشغّل الحزمة، لأن تشغيل الحزمة هو ما يفعله المرء حين ينقّح.

ما أصلح الأمر فعلًا هو جعل القاعدة قابلة للفرض ماديًا. آليتان:

قيّد عمال مشغّلات الاختبارات على مستوى الجهاز. يحقن Claude Code متغيرات البيئة من ~/.claude/settings.json في كل أمر يشغّله:

{
	"env": {
		"VITEST_MAX_THREADS": "4",
		"TURBO_CONCURRENCY": "4",
		"PW_WORKERS": "4"
	}
}

الآن حتى الجلسة التي تتجاهل كل تعليمة لا تستطيع أن تستولي إلا على 4 عمال. تحذير من التجربة: تحقق أن القيد يصل فعلًا إلى العملية. قيودي ابتلعها بصمت وضعُ البيئة الصارم في Turborepo لأسابيع حتى أدرجتها في passThroughEnv. القيد الذي لم ترَه يعمل قيدٌ لا تملكه.

أضف خطاف بوابة. خطافات Claude Code (hooks) نصوص صغيرة تعمل حول نداءات الأدوات. خطاف PreToolUse على Bash يستطيع فحص الجهاز قبل أي أمر ثقيل، ورفضه مع تفسير:

#!/usr/bin/env python3
# ~/.claude/hooks/gate-heavy-commands.py
import json, os, re, subprocess, sys

MAX_LOAD = 20.0   # ~1.25x my 16 logical cores. Tune to your machine.
MAX_SUITES = 2    # two suites are fine; the third gets denied
HEAVY = re.compile(r"vitest|playwright test|jest|turbo run (test|lint|typecheck)")

cmd = json.load(sys.stdin).get("tool_input", {}).get("command", "")
if not HEAVY.search(cmd) or "HEAVY_OK=1" in cmd:
    sys.exit(0)  # not heavy, or explicitly overridden: allow

load1 = os.getloadavg()[0]
procs = subprocess.run(
    ["pgrep", "-fl", "vitest|playwright test|jest|turbo run"],
    capture_output=True, text=True,
).stdout.splitlines()

if load1 > MAX_LOAD or len(procs) >= MAX_SUITES:
    print(
        f"Machine busy (load {load1:.0f}, {len(procs)} suites running). "
        "Wait ~3 minutes and retry, or run a single test file instead. "
        "Prefix with HEAVY_OK=1 only if the human explicitly asked.",
        file=sys.stderr,
    )
    sys.exit(2)  # exit code 2 blocks the tool call; stderr goes to the agent

sys.exit(0)

ثم صِله في ملف الإعدادات نفسه:

{
	"hooks": {
		"PreToolUse": [
			{
				"matcher": "Bash",
				"hooks": [
					{
						"type": "command",
						"command": "python3 ~/.claude/hooks/gate-heavy-commands.py",
						"timeout": 10
					}
				]
			}
		]
	}
}

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

وأثناء كتابة هذا المقال شاهدت البوابة تثبت جدارتها: رفضت تشغيل اختبارات لأن جلسة شقيقة كانت قد رفعت حِمل الجهاز إلى 183. الجلسة المرفوضة انتظرت، ثم أعادت المحاولة حين هدأ الوضع، وأكملت طريقها. لا جهاز منصهر، ولا تدخل مني.

(ولمستخدمي macOS: اسبق المهام الطويلة غير المراقبة بـtaskpolicy -c utility فتفسح الطريق بأدب لما تعمل عليه أنت. وعلى Linux: الأمر nice.)

الدرس 4: شجرة عمل git لكل جلسة

إن تشاركت جلستان نسخة عمل واحدة، فستحرران الملفات نفسها، وتتسابقان على البناءات، وتودع إحداهما أحيانًا عملَ الأخرى نصف المكتمل في إيداعاتها. أشجار عمل git (يُفتح في علامة تبويب جديدة) — أي git worktrees — تحل هذا: عدة مجلدات عمل يخدمها مستودع واحد، لكل منها فرعه الخاص.

git worktree add ../myapp-feature-x -b feature-x origin/main
cd ../myapp-feature-x
npm install   # do not skip this, see below
claude

جلسة واحدة لكل شجرة عمل، دائمًا. وثائق أفضل الممارسات الرسمية (يُفتح في علامة تبويب جديدة) توصي بالنمط نفسه، وإن أردت شرحًا أعمق للإعداد نفسه فدليل Code With Seb للإعداد الإنتاجي (يُفتح في علامة تبويب جديدة) جيد — وقاعدته في تحديد نطاق أشجار العمل حسب الوحدة البرمجية لا حسب المهمة تتناغم مع نصيحة التقسيم في الدرس 6.

فخّان وقعت فيهما لتنجو أنت منهما:

فخ الخطافات الصامتة. أدوات مثل husky تثبّت خطافات git أثناء npm install. شجرة العمل الجديدة بلا تثبيت لا خطافات فيها، وgit يتخطى الخطاف الغائب بصمت ويخرج بحالة 0. إيصالي: في شجرة عمل بلا خطافات استغرق git push ثلاث ثوانٍ. ومع الخطافات 55.9 ثانية. تلك الدفعة السريعة لم تشغّل فحصًا واحدًا وبدت خضراء تمامًا.

فخ التوليد القديم. الملفات المولّدة — عملاء ORM وأشجار المسارات — لا توجد في شجرة عمل جديدة حتى تولّدها. تخطيت تلك الخطوة مرة فقضيت وقتًا أحدّق في 369 خطأ نوع وهميًا في شيفرة لم أمسها.

وإن كانت جلساتك تطلق وكلاء فرعيين: قل لهم في التوجيه نفسه ألا يشغّلوا أبدًا git checkout أو git reset أو git stash. وكيل فرعي عندي سحب مرة إيداعًا قديمًا "ليفحصه"، فأودع الوكيل التالي عمله على الفرع الخطأ. الوكلاء الفرعيون يقرؤون التاريخ بـgit show وgit diff. الجلسة الرئيسية وحدها تحرك HEAD.

جرّبها: الأوامر الأربعة أعلاه، في المرة القادمة التي كنت ستفتح فيها جلسة ثانية في المجلد نفسه.

اجعلها تلقائية: غلّف الطقس كله في نص برمجي حتى لا يؤديه أحد — إنسانًا كان أو وكيلًا — من الذاكرة:

#!/bin/bash
# wt.sh — new worktree with everything a session needs
set -e
git worktree add "../myapp-$1" -b "$1" origin/main
cd "../myapp-$1"
cp ../myapp/.env.local . 2>/dev/null || true
npm install
npm run db:generate 2>/dev/null || true
echo "ready: $(pwd)"

ثم ضع القاعدة في CLAUDE.md ("كل جلسة تعمل في شجرة عملها؛ أنشئها بـ./wt.sh <branch>") فيشغّلها الوكلاء بأنفسهم. تطبيق Claude Code المكتبي يستطيع أيضًا إنشاء شجرة عمل لكل جلسة تلقائيًا، وهذا ما أستخدمه يوميًا — مع خطاف SessionStart صغير ينسخ .env.local ويعيد التوليد إن كان ناقصًا.

الدرس 5: اجعل تعارض الملفات المشتركة مستحيلًا

مع أربعة فروع تُدمج كل يوم، لم تأتِ تعارضاتي من شيفرة الميزات. جاءت من الملفات التي يلمسها كل فرع: سجل التغييرات، وسجل التقدم، ووثيقة السياق المشتركة التي يقرؤها وكلائي.

الحل ليس دمجًا أذكى. الحل إزالة الملف المشترك من الوجود.

لكل ملف مشترك من نوع "أضف في آخره"، استخدم مجلد شذرات: يكتب كل فرع ملفه الصغير بدل الإضافة إلى الملف المشترك:

docs/changelog.d/
  2026-08-19-fix-reader-timeout.md
  2026-08-21-add-arabic-toc.md

نص بناء يجمّع الشذرات في سجل التغييرات الحقيقي وقت الإصدار. لكل شذرة مالك واحد بالضبط، فلا يبقى شيء يتقاتل عليه فرعان. التعارضات لا تُحل؛ بل تكف عن أن تكون ممكنة. إن استخدمت changesets (يُفتح في علامة تبويب جديدة) أو towncrier (يُفتح في علامة تبويب جديدة) في بايثون، فهذه الفكرة نفسها معممة على أي وثيقة مشتركة.

أما الملفات التي لا بد أن يحررها الجميع فعلًا، كوثيقة الاصطلاحات:

أبقِ القوائم بعنصر واحد في كل سطر ومرتّبةً، فتحط الإضافات المتوازية في أسطر مختلفة وتُدمج بسلاسة.
فكّر في merge=union داخل .gitattributes، وهي تُبقي طرفَي التعارض بدل التوقف — لكن اعرف فخها: أثناء إعادة التأسيس (rebase) قد تُبقي بصمت نسخًا مكررة من الأسطر نفسها. أحد ملفات السياق عندي تضخم بهدوء من 223 سطرًا إلى 275 سطرًا من نقاط مكررة قبل أن أنتبه. طبّق union على النثر السطري فقط، لا على JSON ولا على الشيفرة أبدًا، وافحص التكرارات في CI.

وأرخص مخفّض تعارضات على الإطلاق: ادمج بسرعة. طلبات السحب الصغيرة التي تهبط في يومها تقلّص نافذة اصطدام كل جلسة أخرى بك.

جرّبها: اختر أكثر ملفاتك المشتركة إثارة للتعارض وقسّمه إلى مجلد شذرات هذا الأسبوع. إنها ساعة عمل.

اجعلها تلقائية: ثلاث قطع، كلها من نوع "اضبطها وانسَها". سطر .gitattributes يُشحن مع المستودع فتسلك كل نسخة السلوك نفسه. وقاعدة الشذرات تذهب إلى CLAUDE.md ("لا تحرر CHANGELOG.md مباشرة؛ أضف ملفًا تحت changelog.d/") — والوكلاء يلتزمون بها بثبات لأنها منعٌ بسيط. وفحص CI صغير يبحث في ملفات union عن الأسطر المكررة، فيحوّل فخ إعادة التأسيس من تلفٍ صامت إلى بناء أحمر.

الدرس 6: احجز العمل قبل أن تبدأه

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

الوكلاء لا يرون نوايا بعضهم، فلا بد أن تسكن النوايا مكانًا علنيًا. والمكان الأنسب هو الذي تفحصه كل جلسة أصلًا: طلبات السحب.

البروتوكول:

فتح PR مسودة هو إعلان حجز. المهمة ملك من لديه PR يذكرها — ولو كان مسودة فارغة. (إن كنت تعرف مصطلح mutex من البرمجة المتزامنة فهذا هو بعينه: قفل يمنع عاملَين من الإمساك بالمهمة نفسها. وإن لم تعرفه: إنه حجز الدور.)
قبل أن تبدأ مهمة، ابحث عن حجز غيرك:

gh pr list --state all --search "FINDING-12"
git fetch && git log --oneline HEAD..origin/main

افحص مجددًا قبيل فتح PR الخاص بك مباشرة. فقد يهبط إصلاح منافس وأنت تعمل. واحد هبط بعد ساعة من بدئي.
وإن خسرت السباق، فلا تصارع الإصلاح المدموج. قارن فرعك به وأرسل ما ينقصه فعلًا فقط، في متابعة صغيرة.

لكن الأفضل من أي بروتوكول: قسّم. أعطِ كل جلسة إقليمها — واحدة تملك القارئ وأخرى تملك الفوترة — بدل أن تسحب جلستان من قائمة مهام واحدة.

جرّبها: اجعل "افتح PR مسودة في الدقائق الأولى" عادةَ كل جلسة.

اجعلها تلقائية: علّم نص فتح PR عندك أن يفحص المنافسين بنفسه: يمسح إيداعات الفرع وعنوانه بحثًا عن معرفات المهام، ويبحث في PRs القائمة عن كل معرف، ويرفض الفتح إن كان PR آخر يحجزها (مع راية تجاوز للمتابعات المتعمدة). وأنا أكتب هذه السطور، تعمل إحدى جلسات Claude عندي على تركيب هذا الفحص بعينه في نص PR الخاص بي — وفي الأمر دائرية تليق بالموضوع.

الدرس 7: دوّن القرارات لحظة اتخاذها

نمط فشل لم يحذرني منه أحد: تقرر الجلسة "أ" أننا "نؤجل حفظ التقدم ثانيتين، ولهذا السبب"، وبعد ساعة تأتي الجلسة "ب" — التي لا ترى محادثة الجلسة "أ" — فتصلح التأجيل بإزالته، بكل نية حسنة. كلتاهما عملت عملًا معقولًا. لكنهما ببساطة لم تلتقيا قط.

الجلسات المتوازية لا تحترم إلا القرارات التي تستطيع قراءتها. فالقرارات تسكن المستودع:

ملف docs/CONTEXT.md يسجل القرارات الحالية، وسبب الاختيارات غير البديهية، وسطرًا واحدًا لكل مسار عمل جارٍ. كل جلسة تقرؤه، وكل جلسة تستطيع أن تعرف ما تفعله شقيقاتها.
التحديثات تهبط في الإيداع نفسه مع الشيفرة. القرار المسجل "لاحقًا" غير موجود بالنسبة للجلسة التي تفرّعت في الأثناء.

يبدو هذا بيروقراطية إلى أن تشاهد جلستي ذكاء اصطناعي تفكّان بأدب معمارَ بعضهما طوال أصيل كامل.

جرّبها: أنشئ docs/CONTEXT.md بقسمين — "قرارات" و"قيد التنفيذ". وقل لجلساتك (عبر CLAUDE.md) أن تقرأه عند البدء وتحدّثه حين تغيّر شيئًا.

اجعلها تلقائية: افرض قاعدة الإيداع الواحد بخطاف pre-commit يُفشل أي إيداع يلمس ملفات المصدر دون أن يلمس التوثيق. خطافي يمنع حرفيًا إيداعات "الشيفرة فقط" ما لم يتغير معها مستند أو ملف سياق أو شذرة سجل (مع مخرج للإصلاحات التافهة). فجّ، نعم، لكنه يحوّل "أرجو أن تتذكر التوثيق" إلى "الإيداع لن يهبط حتى توثّق" — والوكلاء يستجيبون للنوع الثاني من القواعد استجابة أفضل بكثير.

الدرس 8: أنت المجدوِل، فتجهّز كما يليق بمجدوِل

كل ما سبق يفترض إنسانًا ينتبه. بعض الإعداد الذي لا يتجاوز خمس دقائق يجعل ذلك صحيحًا فعلًا:

فعّل الإشعارات. الجلسة المحجوزة على سؤال صلاحيات تهدر مقعدها بالضبط بمقدار الوقت الذي لا تراها فيه — ولن يريك أي مقياس حِمل ذلك الخمول أبدًا. في التطبيق المكتبي: اسمح لـClaude في إعدادات النظام ← الإشعارات. وفي الطرفية: شغّل /config وفعّل الإشعارات، أو صِل خطاف Notification بإشعار النظام:

{
	"hooks": {
		"Notification": [
			{
				"hooks": [
					{
						"type": "command",
						"command": "osascript -e 'display notification \"Claude needs input\" with title \"Claude Code\"'"
					}
				]
			}
		]
	}
}

عرض متجاور، لا ألسنة متراكمة. الجلسات جنبًا إلى جنب (في التطبيق المكتبي، أو جلسة في كل لوح tmux/iTerm) تجعل "من محجوز، من يعمل، من انتهى" لمحةَ نظر. سؤال الصلاحيات المختبئ خلف لسان تبويب هو أشيع طريقة يُهدر بها مقعد.
سمِّ الجلسات بأسماء نواتجها فتُقرأ قائمة الجلسات كلوحة عمل.
لوّن طرفياتك لكل شجرة عمل. خطأ اليد الكلاسيكي في التوازي هو إطلاق حزمة الاختبارات في الجلسة التي تشغّل واحدة أصلًا.
اضبط وضع المخاطرة لكل جلسة. جلسة التوثيق والاختبارات قليلة الخطر تقبل التحريرات تلقائيًا فلا تتوقف عندك أبدًا. وجلسة الترحيل الخطرة تبقى على الموافقة اليدوية، في اللوح الذي تراقبه فعلًا.

اجعلها تلقائية: خطاف الإشعارات أعلاه هو الأتمتة — يقلب "عليّ أن أطمئن على جلساتي" إلى "جلساتي تناديني حين تحتاجني". هذا الانقلاب هو الفكرة كلها. والبقية إعداد لمرة واحدة.

الدرس 9: حد المعدّل جهاز ثانٍ، وأنت تشبعه أيضًا

معالجك مورد مشترك واحد. واشتراكك في Claude هو الآخر. كل جلسة ووكيل فرعي ومهمة خلفية تسحب من الحوض ذاته على مستوى الحساب كله.

تعلمت هذا بإطلاق ~18 وكيلًا فرعيًا من الطراز الثقيل دفعة واحدة لتدقيق شيفرة. فشل أحد عشر منها بأخطاء حد المعدّل. المهمة نفسها، على دفعات من ثلاثة، اكتملت نظيفة — وتوزيعة مختلفة من 23 وكيلًا بنموذج أخف جرت بعرضها كله بلا إخفاق واحد. إذن: قسّم توزيعات النماذج الثقيلة دفعات (نحو 3 في كل مرة تنجح عندي)، ودع وكلاء النماذج الرخيصة ينتشرون، ولا تطلق توزيعات كبيرة من جلستين في آن واحد أبدًا. (وثائق الوكلاء الفرعيين (يُفتح في علامة تبويب جديدة) تغطي نموذج التوازي نفسه؛ ولجانب الحصة، مقال dev.to هذا عن اختيار النماذج تحت حدود المعدل (يُفتح في علامة تبويب جديدة) يتكامل مع قاعدة الدفعات.)

وهذا يضع تفريغ العمل إلى السحابة في موضعه الصحيح. العمل في السحابة — Claude Code على الويب، المهام المجدولة الخلفية، المراجعة عبر CI — يرفع الحِمل عن جهازك، وأنا أستخدمه لهذا بالضبط: التدقيقات الأسبوعية وفحوص انحراف التوثيق وأعمال الصيانة كلها مهام سحابية مجدولة كي لا يدفع حاسوبي ثمنها. لكن عمل السحابة يسحب من حصة الحساب نفسها التي يسحب منها العمل المحلي. السحابة تريح المعالج، لا حدود المعدّل. حين يتشبع الجهاز، فإرسال المهمة التالية إلى السحابة خير من فتح جلسة محلية خامسة؛ وحين تتشبع الحصة، فلا ينفع إلا الصبر ودفعات أصغر.

جرّبها: في المرة القادمة التي توزّع فيها وكلاء فرعيين، عُدَّ كم ثقيلًا منها يعمل بتزامن. إن تجاوزوا حفنة، قسّمهم دفعات.

اجعلها تلقائية: قاعدتان دائمتان في CLAUDE.md ("قسّم توزيعات النماذج الثقيلة دفعات من ~3"؛ "عند ارتفاع الحِمل فضّل جلسات السحابة على جلسات محلية جديدة")، إضافة إلى نقل كل مهمة صيانة دورية — تدقيقات، فحوص تبعيات، مسح انحراف التوثيق — إلى مهام سحابية مجدولة كي لا تنافس جهازك إطلاقًا.

الخلاصة السريعة

3–4 جلسات نشطة. اثنتان على الأكثر تفعلان شيئًا ثقيلًا. والمسوح والتدقيقات تعمل وحدها.
افحص متوسط الحِمل قبل التشغيلات الثقيلة؛ وانتظر فوق ~1× عدد أنويتك.
إخفاقات غريبة بالجملة؟ uptime أولًا. الحِمل المرتفع يعني أن الإخفاقات تكذب عليك.
افرض بقيود البيئة وخطاف بوابة. الوكلاء لا يرون بعضهم؛ الجهاز يراهم.
شجرة عمل لكل جلسة. ولا تتخطَّ التثبيت أبدًا — فهو ما يمنحك خطافات git.
الملفات المشتركة التراكمية تصبح شذرات لكل فرع. ودمج union يحتاج فحص تكرارات.
الـPR المسودة حجزٌ للدور. افحص المنافسين قبل البدء وقبل فتح PR الخاص بك.
القرارات تسكن المستودع، في إيداع الشيفرة نفسه. الجلسات لا تحترم إلا ما تقرؤه.
إشعارات مفعّلة، عرض متجاور، جلسات مسماة، طرفيات ملونة.
قسّم توزيعات الوكلاء الثقيلة دفعات. السحابة توفر معالجك، لا حصتك.

لماذا يهمني كل هذا

أبني Read Master (يُفتح في علامة تبويب جديدة) وحدي. إنه تطبيق بالذكاء الاصطناعي لفهم القراءة — دليل ما قبل القراءة يهيئك قبل الكتاب، وشرح عند الطلب أثناء القراءة، كل ذلك حول قارئ مصمم لإتاحة الوصول أولًا. منتجُ الشخص الواحد لا يبحر إلا إذا وجد ذلك الشخص رافعة في مكان ما، والجلسات المتوازية في Claude Code أكبر رافعة وجدتها. كل درس هنا دُفع ثمنه بحادثة حقيقية في قاعدة شيفرة حقيقية.

يُطلق Read Master للعموم في سبتمبر. إن كنت فضوليًا لترى ما كان كل هذا التوازي يبنيه، فقائمة الانتظار مفتوحة (يُفتح في علامة تبويب جديدة) — وإن كنت تشغّل جلسات وكلاء متوازية بنفسك، فيسعدني حقًا أن نتبادل الخبرات. ما إعدادك؟ وما أول ما انصهر عندك؟

كتب Claude مسودة هذا المقال في واحدة من الجلسات المتوازية التي يصفها؛ وراجعتُها وحررتها ودققت وقائعها بنفسي. إن جربت خطاف البوابة أو نمط الشذرات، أخبرني كيف سار الأمر.