كيف توزّع العمل بين Claude Code وCodex وCursor

ملفا ترحيل (migration)، الجدول نفسه، العمود الجديد نفسه، وكلاهما في طلب سحب واحد. كتب Claude Code الأول في 11:40، وكتب Codex الثاني في 11:52 من فرع لم يسمع بالأول قط. لم يخطئ أيٌّ من الوكيلين في شيء، ولم تكن لدى أيٍّ منهما وسيلة ليعرف بوجود الآخر.

وضعت ورقة بحثية من يوليو 2026 رقمًا على هذه الحكاية. أعاد الباحثون تنفيذ عمليات دمج ثلاثية في git على 747 زوجًا من طلبات السحب المفتوحة في الوقت نفسه والمكتوبة بيد وكلاء الذكاء الاصطناعي، زوج واحد لكل مستودع، من مجموعة بيانات فيها 33,596 طلب سحب عبر 2,807 مستودعات. الأزواج التي كتبها وكيلان مختلفان اصطدمت بتعارضات نصية في 41.7 بالمئة من الحالات، مقابل 19.8 بالمئة حين شُغِّل الوكيل نفسه مرتين، وفترتا الثقة عند 95 بالمئة لا تتداخلان. وكانت ملفات الكود المصدري، لا ملفات القفل (lockfiles)، تمثّل 84.4 بالمئة من الملفات المتعارضة (Xu, Subramanian and Karthik, arXiv:2607.04697).

والتحفّظ المرافق لهذه النتيجة هو نصفها الأهم. الأزواج التي جمعت وكيلين من جهتين مختلفتين لم تتجاوز 0.5 بالمئة من الأزواج النشطة في الوقت نفسه، وظهرت في 122 مستودعًا من أصل 2,807. أي أن أحدًا تقريبًا لا يشغّل وكيلين من مزوّدين مختلفين على مستودع واحد بعد. وإن كنت تقرأ هذا الآن فأنت ضمن تلك النسبة الصغيرة، 4.3 بالمئة من المستودعات، ومعدّل تعارض مضاعف تقريبًا هو خط الأساس عندك.

أعمل على Taskfolk، فخذ ذلك في حسبانك عند قراءة أقسام المنتج. أما النصف الأول فتوثيق رسمي من المزوّدين، يمكنك مراجعته بنفسك.

الاشتراكات الثلاثة رخيصة، والتكلفة الحقيقية أنت

من يسأل عن توزيع العمل بين هذه الأدوات يسأل في الحقيقة سؤالًا آخر: هل الدفع لثلاثة اشتراكات حماقة؟ بيانات الاستخدام تقول إنه أمر شائع. استطلعت Digital Applied آراء 2,847 مطوّرًا في 320 وكالة وفريقًا داخليًا بين يناير ومارس 2026. وجاءت حصة الأداة الأساسية هكذا: Claude Code بنسبة 28 بالمئة، وCursor بنسبة 24، وGitHub Copilot بنسبة 17، وCodex بنسبة 11.

لكن العمود الذي يستحق القراءة هو نسبة من يستخدم الأداة أصلًا: Copilot عند 58 بالمئة، وClaude Code عند 54، وCursor عند 49، وCodex عند 31. المجموع يتجاوز 100 بكثير لأن معظم المشاركين ذكروا أداتين إضافيتين على الأقل في أدوار مساندة. وهذا استطلاع تسويقي تجريه وكالة، لا دراسة محكّمة، فتعامل مع الأرقام العشرية بوصفها مؤشرًا، ومع الصورة العامة بوصفها صحيحة.

الاشتراك الثاني والثالث رخيصان أمام التكلفة الفعلية، وهي أنك صرت طبقة النقل بينها. تشرح قرارًا لـ Claude Code، ثم تعيد شرحه لـ Cursor، ثم تلصق معايير القبول في Codex. في كل مرة تحمل الحالة بيدك لأن لا أحد غيرك يحملها.

ماذا تخزّن كل أداة، وأين

تُناقَش التعليمات والذاكرة وكأنهما شيء واحد. هما شيئان، والفرق بينهما هو ما يحدّد ما يمكن مشاركته. كل صف في الجدول التالي مأخوذ من توثيق المزوّد نفسه، وقُرئ في 26 يوليو 2026. تحقّق دائمًا من تاريخ أي جدول من هذا النوع، بما فيه هذا الجدول.

	Claude Code	Codex	Cursor
ملف التعليمات	‏CLAUDE.md و.claude/CLAUDE.md و~/.claude/CLAUDE.md، إضافة إلى مسار سياسة مُدارة	‏AGENTS.override.md ثم AGENTS.md، من ~/.codex ومن جذر مستودع git نزولًا	‏.cursor/rules/*.mdc، إضافة إلى AGENTS.md في الجذر والمجلدات الفرعية
يقرأ ملفات الآخرين؟	لا. التوثيق يقول صراحةً إنه يقرأ CLAUDE.md لا AGENTS.md	لا يقرأ CLAUDE.md افتراضيًا، لكن أسماء الملفات البديلة قابلة للضبط	نعم لـ AGENTS.md، وتوثيق سطر الأوامر يضيف CLAUDE.md في جذر المشروع
قاعدة الدمج	تُضمّ الملفات المكتشفة تباعًا من الجذر إلى المجلد الحالي، والأقرب أخيرًا، مع استيراد @path حتى عمق أربعة	تُضمّ تباعًا من الجذر إلى المجلد الحالي، والأقرب يغلب، والحجم المجمّع محدود بـ 32 KiB	قواعد الفريق ثم قواعد المشروع ثم قواعد المستخدم، تُدمج كلها، والمصدر الأسبق يغلب
المطبّ	بعد نحو 200 سطر يتراجع الالتزام، وهذا سياق لا قاعدة مُلزِمة	عند بلوغ سقف 32 KiB يتوقف ببساطة عن إضافة الملفات	ملف .md عادي داخل .cursor/rules يُتجاهل لأنه بلا frontmatter
الذاكرة التلقائية	‏~/.claude/projects/<project>/memory/، أول 200 سطر أو 25 KB لكل جلسة، محلية على الجهاز	غير موثّقة كميزة	لكل مشروع ولكل شخص، تُولَّد في الخلفية، وتُدار من الإعدادات
مخزن الجلسات	ملفات JSONL داخل ~/.claude/projects/، وصيغتها داخلية ومرتبطة بالإصدار	ملفات rollout بصيغة JSONL داخل ~/.codex/sessions/، تحقّق منها المجتمع لا التوثيق	غير موثّق، مع وجود --resume وسرد الجلسات

يتبع ذلك أمران. التعليمات تتقارب فعلًا: الأدوات الثلاث تقرأ ملف Markdown عاديًا، وصار AGENTS.md الاسم الفائز في معركة التسمية، ويكفي رابط رمزي واحد أو سطر استيراد واحد @AGENTS.md لتحصل على ملف تعليمات واحد تحمّله الأدوات الثلاث. توثيق Claude Code نفسه ينصح بهذا بالضبط. اعتبر المسألة محلولة.

الذاكرة وحالة الجلسة لا تتقاربان، ولم تُصمَّم لتتقارب أصلًا. صفحة الذاكرة في Claude Code تقول إن الذاكرة التلقائية محلية على الجهاز، وإن ملفاتها "not shared across machines or cloud environments"، أي لا تُشارَك بين الأجهزة ولا البيئات السحابية. ويحتفظ Cursor بقواعده في ملفات .mdc مزوّدة بـ frontmatter، وبذاكراته لكل مشروع ولكل شخص خلف الإعدادات. أما Codex فيكتب ملفات rollout لا ينشر شكلها. ولا أحد يبني جسرًا بينها، لأن أيًّا من الثلاثة لا يملك سببًا ليبنيه.

flowchart LR
  A["Claude Code"] --> A1["CLAUDE.md and local auto memory"]
  B["Codex"] --> B1["AGENTS.md and rollout files"]
  C["Cursor"] --> C1["mdc rules and per project memories"]
  A --> T["The work record"]
  B --> T
  C --> T

إذن الحالة الوحيدة التي تقرأها الأدوات الثلاث وتكتب فيها هي حالة تحتفظ بها في مكان ثالث. وهذا المكان موجود أصلًا لدى معظم الفرق: أداة تتبّع العمل.

تقسيم يصمد بعد ظهر الثلاثاء

هذا هو توزيع الأدوار الذي يستقر عليه الجميع تقريبًا. لا أراه خاطئًا، لكنه أقل أجزاء المسألة إثارة للاهتمام.

المرحلة	الأنسب عادةً	لماذا
الكتابة	Claude Code	تشغيلات طويلة ومستقلة تمسّ ملفات كثيرة، مع عزل worktree من صميم المنتج
المراجعة	Codex أو جلسة Claude Code ثانية	الرأي الثاني لا قيمة له إن كان صاحبه هو من كتب الكود
الصقل	Cursor	حلقة تحرير قصيرة وإنسان يراقب الفروقات وهي تُطبَّق

الجدول بوصفه نيّة لا يساوي شيئًا. بعد ظهر الثلاثاء ستسلّم وكيل المراجعة ميزة نصف منتهية لأن طرفيّته كانت مفتوحة أمامك أصلًا. التقسيم يصير حقيقيًا حين يتحوّل إلى عمود على اللوحة وصلاحية على مفتاح.

ابدأ بالأعمدة. أعطِ المشروع حالة لكل مرحلة، مسمّاة باسم العمل لا باسم الأداة (Building وIn review وPolishing)، ثم حدّد النقلات المشروعة. في Taskfolk قائمة الانتقالات المسموح بها هي الضابط المُنفَّذ فعلًا: أي نقلة خارجها تُعيد خطأ من كل مسار كتابة، بما في ذلك REST وMCP.

أما رقم العمل الجاري (WIP) فغير مُنفَّذ. اللوحة تعرض العدد مقابل الحد وتبرز العمود عند تجاوزه، وهذا كل ما يحدث. وأي مقال يخبرك أن حد WIP سيرفض بطاقة فهو يخمّن.

هكذا يصير التسليم تغيير حالة بدل نسخ ولصق. وكيل الكتابة يضبط In review ويتوقف. ووكيل المراجعة يجد تذكرة في عموده عليها رابط طلب السحب، والتذكرة تحمل القرارات، فلا أحد يعيد الشرح من جديد. ويتوسّع مقال وكيلان وباكلوج واحد في فكرة الأعمدة بوصفها بروتوكولًا.

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

ثلاث هويات، ولكل واحدة ما يحق لها كتابته

يغطّي مقال باكلوج مشترك لوكلاء البرمجة آليات القائمة بشكل عام، ولهذا يقتصر هذا القسم على ما يتغيّر حين يأتي الوكلاء الثلاثة من ثلاث جهات.

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

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

{
  "field_policy": ["status", "labels"]
}

ثم امنح ذلك المفتاح نطاق comments:write ليبقى قادرًا على الإبلاغ عمّا وجده. التعليقات تحكمها النطاقات لا قائمة الحقول، ولهذا لا يكفي ضابط واحد. والقائمة تعمل على مستوى الحقل لا على مستوى القيمة: تستطيع أن تقول إن هذا الوكيل يكتب الحالة أو لا يكتبها، ولا تستطيع أن تقول إنه يضبطها على In review فقط. وأنا أيضًا أتمنى لو استطعنا.

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

كيف يعرف الوكيل الثاني أن دوره جاء

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

الاستقصاء الدوري (polling) مقبول. الحجة القائلة إنه مكلف لا تصمد أمام الحساب: مفتاح Taskfolk يسمح افتراضيًا بـ 600 طلب في الدقيقة، والاستقصاء كل عشر ثوانٍ ينفق ستة منها. تكلفته الحقيقية هي التأخير وانعدام الرؤية. الطابور لا يوجد إلا داخل الحلقة التي كتبتها أنت، فلا يستطيع أحد غيرك فحصه، ولا شيء يعيد إليك ما فات خلال الساعات التي نام فيها حاسوبك.

البديل اتصال Server-Sent-Events واحد طويل العمر لكل وكيل، يُفتح بمفتاح الوكيل نفسه.

curl -N "https://taskfolk.ai/api/v1/workspaces/acme/agent-events?since=2026-07-26T02:00:00Z" \
  -H "Authorization: Bearer tfk_live_a1b2..."

import httpx

url = "https://taskfolk.ai/api/v1/workspaces/acme/agent-events"
params = {"since": "2026-07-26T02:00:00Z"}
headers = {"Authorization": "Bearer tfk_live_a1b2..."}

with httpx.stream("GET", url, params=params, headers=headers) as r:
    for line in r.iter_lines():
        if line.startswith("data: "):
            handle(line[6:])

: connected
data: {"type":"ready"}
data: {"type":"issue.assigned","issue_key":"APP-14","at":"2026-07-26T02:14:52Z"}
: ping

تحتاج نقطة النهاية إلى نطاق agents:read، ومفتاح بشري يحصل على خطأ 400 يطلب منه استخدام مفتاح الوكيل. وتصل عبرها خمسة أنواع من الأحداث: issue.assigned وcomment.mention وsession.updated وautomation.notify وchat.message. الحمولات تحمل مؤشرات ومقتطفًا لا يتجاوز 240 حرفًا، لا المحتوى الكامل أبدًا، ونبضة كل 25 ثانية تكشف الاتصال الميت بسرعة.

‏since هو المعامل الذي يهم في الليل. يعيد بث الأحداث الفائتة من الجداول المصدرية ضمن نافذة 24 ساعة، فالحاسوب الذي نام طوال الليل يعيد الاتصال ويلحق بما فاته بدل أن يفقد الإسناد.

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

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

sequenceDiagram
  participant Human
  participant Board
  participant Writer
  participant Reviewer
  Human->>Board: assign APP 14 to Writer
  Board->>Board: create pending session
  Board-->>Writer: issue.assigned
  Writer->>Board: claim session, status Building
  Writer->>Board: status In review, attach PR link
  Board-->>Reviewer: issue.assigned
  Reviewer->>Board: comment findings, status Polishing

ويستدعي الوكلاء الثلاثة كتالوج الأدوات نفسه، لأن أدوات MCP مولّدة من مواصفة REST لا مصانة بجوارها. وتغطّي مقالتا إدارة المهام مع Claude Code وإدارة المهام مع Cursor إعداد كل أداة على حدة.

ما لا تستطيعه لوحة مشتركة

نحن لا نزامن ذاكرة أحد ولا ملف قواعده ولا نافذة سياقه. لا شيء في Taskfolk يكتب في CLAUDE.md أو AGENTS.md أو .cursor/rules عندك. وإن قال مقال من عندنا غير ذلك يومًا فهو خاطئ.

ولا نشغّل وكلاءك أيضًا. التدفّق يوصل الإشارات، وسجل الجلسة يخزّن ما جرى، وبيئة التشغيل تبقى لك.

تولّد حزمة المهارة القابلة للتثبيت إعدادات عميل MCP لـ Claude Desktop وCursor وVS Code، ولا تولّد إعدادًا لـ Codex. وإلى أن يتغيّر ذلك، اكتب TOML بيدك:

# ~/.codex/config.toml
[mcp_servers.taskfolk]
url = "https://taskfolk.ai/api/mcp/v1"
bearer_token_env_var = "TASKFOLK_API_KEY"

ويأخذ Claude Code نقطة النهاية نفسها من سطر الأوامر. وخيار --transport http ليس اختياريًا هنا، فمدخل JSON فيه url بلا transport يُعد خطأ في الإعداد، ورسالة الفشل التي تظهر لا تقول ذلك.

claude mcp add --transport http taskfolk https://taskfolk.ai/api/mcp/v1 \
  --header "Authorization: Bearer $TASKFOLK_API_KEY"

وأكبر قيد هنا هو ما كان رقم arXiv يتحدث عنه أصلًا. لا توجد لوحة تمنع وكيلين من تحرير الملف نفسه. تلك مشكلة git، وقد أطلقت Anthropic إجابة لها: claude --worktree <name> ينشئ نسخة عمل معزولة تحت .claude/worktrees/ على فرع خاص بها، ويستطيع وكيل فرعي مخصص أن يحمل isolation: worktree في frontmatter، وينسخ ملف .worktreeinclude الملفات المستبعدة من git مثل .env إلى كل نسخة جديدة.

تفصل worktrees الملفات، وتفصل اللوحة العمل. تحتاج الاثنين معًا، وأي أداة تتبّع تدّعي أنها تحل الأولى إنما تبيعك كلامًا.

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