Claude Code قوي في قراءة قاعدة شيفرة ضخمة والحفاظ على خطة تمتد عبر ملفات كثيرة. أما Codex فقوي في التغييرات محدودة النطاق والقائمة على الاختبارات. وينتهي كثير من المهندسين إلى الرغبة في استخدام كليهما على المستودع نفسه: أحدهما يصوغ إعادة هيكلة بينما الآخر يرسّخ مجموعة اختبارات متذبذبة. وبمجرد أن تجرّب ذلك، يصبح مجلد العمل نفسه هو المشكلة. أداتان مختلفتان، وواجهتا أوامر مختلفتان، ومجلد واحد يكتبان فيه معاً.
يرشدك هذا الدليل خلال الإعداد خطوة بخطوة، ويسمّي نمط الفشل عند كل خطوة، ويوضح النقطة التي تتوقف عندها الطرفيتان عن التوسع. أما شقّ العزل فمسألة محلولة عبر git worktrees. وأما شقّ التنسيق، أي معرفة أي أداة تعمل على ماذا وإبقاء كل تغيير قابلاً للمراجعة، فهو حيث تتولى طبقة محايدة تجاه بيئة التشغيل مثل Sharkly المسؤولية.
Sharkly ليس بديلاً عن Claude Code أو Codex. إنه يضيف طبقة المهام وComputer والسياق والمراجعة المشتركة حول أدوات التنفيذ التي تستخدمها بالفعل، بحيث تصبح جلسة Claude Code وجلسة Codex مهمتين في سير عمل واحد بدلاً من طرفيتين تراقبهما باستمرار.
لماذا قد تشغّل Claude Code وCodex على المستودع نفسه
ثلاثة أسباب تتكرر مراراً وتكراراً، وليست كلها المشكلة ذاتها.
نقاط قوة مختلفة لمهام مختلفة. تُسند العمل واسع السياق (تتبّع هذا الخطأ عبر الوحدة، أو التخطيط لهذه الهجرة) إلى أحد الوكيلين، والعمل الضيق القابل للتحقق (اجعل هذا الاختبار ينجح، أو أحكم هذه الدالة) إلى الآخر. ومطابقة الأداة بالمهمة موضوع قائم بذاته؛ راجع أي نموذج لأي مهمة برمجة: مطابقة النماذج بالوكيل المناسب.
مواجهة مباشرة على عمل حقيقي. المعيار الوحيد الصادق هو قاعدة الشيفرة الخاصة بك، لا لوحة المتصدرين. فتشغيل الأداتين على التذكرة نفسها ومقارنة الفروقات يخبرك أكثر من أي نتيجة منشورة. ونشرح الطريقة في كيفية مقارنة وكلاء البرمجة على قاعدة الشيفرة الخاصة بك لا على معيار جاهز.
أنت تدفع ثمن كليهما بالفعل. كثير من الفرق لديها اشتراك Claude ومقعد Codex أو مقعد API بالفعل. والحياد تجاه المزوّد هو الهدف: يجب أن يصمد سير عملك أياً كانت الأداة التي تُطلق النموذج الأفضل التالي، ودون إعادة بناء.
أياً كان السبب، فإن الفشل واحد. وكيلان في مجلد واحد هما كاتبان يحرّران مستنداً واحداً بلا قفل. أحدهما يبدّل الفرع من تحت الآخر، أو يعيد تنسيق ملف في منتصف التحرير، فتنتج فروقات مطبّقة جزئياً لا معنى لها.
الخطوة 1: امنح كل وكيل شجرة عمل خاصة به
يعالج git worktree التصادم من جذوره. يمكن لمستودع واحد أن يحتوي على عدة مجلدات عمل مسحوبة في الوقت نفسه، كل منها على فرع خاص به، وجميعها تتشارك قاعدة بيانات .git واحدة. فبدلاً من مجلد واحد يتصارعان عليه، تحصل على مجلد لكل مهمة.
# One checkout per task, each on its own branch
git worktree add ../app-refactor -b agent/refactor
git worktree add ../app-tests -b agent/tests
git worktree list
ثم وجّه أداة مختلفة إلى كل مجلد:
cd ../app-refactor && claude # Claude Code on the refactor
cd ../app-tests && codex # Codex on the test suite
نمط الفشل إذا تجاهلت هذه الخطوة: تشغّل الأداتان الأمر cd إلى المستودع نفسه، وتتسابقان على الملفات ذاتها، فتمحو إحداهما بصمت عملاً غير مُودَع لدى الأخرى. وأشجار العمل تجعل ذلك مستحيلاً فعلياً. وللتنظيف بعد ذلك حوافّه الحادة؛ ويغطي إدارة أشجار العمل لوكلاء البرمجة دون عناء التنظيف الأمر git worktree remove ومشكلة الفروع القديمة.
الخطوة 2: وجّه كل أداة إلى التعليمات الصحيحة
يقرأ Claude Code وCodex ملفات مشروع مختلفة. يبحث Claude Code عن CLAUDE.md؛ ويقرأ Codex الملف AGENTS.md. وإذا كان مستودعك يحتوي على أحدهما فقط، فسيعمل أحد الوكيلين دون أي إلمام بأعرافك.
احتفظ بكليهما، وحافظ على اتساقهما. النمط الموثوق هو كتابة القواعد المشتركة مرة واحدة وجعل كل نقطة دخول تتضمنها:
<!-- CLAUDE.md and AGENTS.md both start with -->
See ./docs/agent-conventions.md for build, test, and style rules.
# Verify each tool actually loads its file before you turn it loose
claude --version # Claude Code reads CLAUDE.md from the worktree root
codex --version # Codex reads AGENTS.md from the worktree root
نمط الفشل إذا تجاهلت هذه الخطوة: يتبع Codex إعداد lint معيّناً بينما يتبع Claude Code إعداداً آخر، فيتحول كل دمج إلى معركة أسلوب لم يوثّقها أحد. وهنا تهم ملاحظة شخصية: رمز التثبيت لا يحمل أعرافك معه، والملف المحلي المدرج في .gitignore لا ينتقل إلى شجرة العمل. لذا ضع القواعد المشتركة في ملفات متتبَّعة، وإلا بدأت كل شجرة عمل جديدة فارغة.
الخطوة 3: شغّل، ثم راقب فجوة التنسيق تتسع
مع شجرتي عمل وملفي إعداد، تعمل الآلية بسلاسة. لديك Claude Code على فرع وCodex على فرع آخر، ولا يلمس أي منهما ملفات الآخر. وبالنسبة لأصيل واحد بوكيلين، يصمد هذا الوضع.
لكن الفجوة تتسع حين ترفع نظرك عن لوحة المفاتيح. فكل جلسة تحتفظ بتاريخها في تبويبها الخاص، بعيداً عن أنظار الأخرى. وعندما تحتاج جولة Codex إلى معرفة ما غيّرته جولة Claude Code بالفعل، لا توجد ذاكرة مشتركة يمكن الرجوع إليها، فتصبح أنت طبقة التكامل. وينتهي الوكيلان في أوقات مختلفة وينتظران الإدخال بصمت، فيتحول «تشغيل كليهما بالتوازي» بهدوء إلى «التحقق من كل منهما بالتتابع».
ثم وسّع ذلك لما يتجاوز اثنين. الخطوة التالية الطبيعية هي سكربت تغليف يشغّل أشجار العمل، ويطلق الأداة المناسبة في كل منها، ويوجّه المخرجات إلى ألواح tmux مسمّاة. يفيد ذلك مع عدد قليل من الجولات. ثم يبدأ بالتضخم: تسمية الفروع، والتنظيف، ووسيلة لمعرفة أي أداة تعمل على أي مهمة، وإعادات المحاولة للأداة التي انهارت. وقبل أن تنتبه، تجد نفسك تدير إطار تنسيق هشاً متماسكاً بـ bash، نصف حالته في سجل الأوامر والنصف الآخر في رأسك. وتشغيل العديد منها في وقت واحد يصطدم بالجدار ذاته سواء كان الوكلاء جميعاً من Claude Code، كما في تشغيل عدة وكلاء Claude Code، أو مزيجاً منهم.
أين تتوقف الطرفيتان عن التوسع
الاختبار الصادق لمعرفة ما إذا كنت قد تجاوزت إعداد «افعلها بنفسك»:
- هل يستطيع أحد أعضاء فريقك رؤية ما يفعله وكلاؤك الآن، دون أن تقرأ له طرفيتك بصوت عالٍ؟
- عندما ينتهي Codex في الثانية ظهراً ويحتاج إلى إدخال، هل يخبرك شيء بذلك؟
- عندما ينتهي الوكيلان معاً، هل يوجد طابور لمراجعة عملهما، أم لا شيء سوى أنت وفرعين؟
إذا كانت الإجابات بالنفي، فالقطعة الناقصة ليست سكربت shell آخر. إنها طبقة تُسند العمل إلى أي من الأداتين، وتعرض الحالة الحية، وتُبقي كل تغيير قابلاً للمراجعة قبل دمجه. وهذا ما يضيفه لوح المهام فوق الطرفيات الخام.
وهذا هو الحد الجدير بالقول صراحة. ينفّذ Claude Code وCodex العمل فعلياً. أما طبقة الأوامر فتتولى الإسناد، وأجهزة Computer المتصلة، وسياق المهمة، والتقدّم، والعوائق، والنتائج، والمراجعة البشرية عبر كليهما. في Sharkly، تُسند مهمة واحدة إلى Claude Code Runtime وأخرى إلى Codex Runtime؛ يعمل كل منهما في شجرة عمل معزولة على Computer متصل، وتعود عمليات التنفيذ والعوائق والنتائج إلى الخط الزمني للمهمة بدلاً من أن تختفي في طرفيات خاصة.
ويبقى تقسيم العمل واضحاً. يبحث الوكلاء وينفّذون ويختبرون ويقدّمون تقاريرهم. أما البشر فيحددون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. تتوقف الأتمتة عند حدّ الحاجة إلى حكمك، وتعيد إليك فرقاً مرفقاً بأدلة التحقق. فتحتفظ بالأدوات التي تدفع ثمنها بالفعل، ويستمر استخدام النماذج عبر الاشتراكات ومفاتيح API المهيّأة في كل أداة، وتحصل على مكان واحد ترى فيه من يعمل على ماذا.
استخدم الإعداد اليدوي عندما تشغّل وكيلاً أو وكيلين لأصيل واحد وتستطيع إبقاء الحالة في رأسك. والجأ إلى طبقة مشتركة عندما يحتاج شخص ثانٍ إلى رؤية واضحة، أو عندما يتجاوز العدد ما تعرضه نافذة طرفية واحدة، أو عندما تقارن الأدوات كثيراً بما يكفي ليصبح سؤال «أي جولة أنتجت هذا الفرع» غير واضح.
قائمة تحقق يمكنك تنفيذها اليوم
نفّذ ما يلي بالترتيب في المرة القادمة التي تضع فيها الأداتين على مستودع واحد:
- [ ] أنشئ
git worktreeواحداً لكل مهمة، كل منها على فرع خاص به. لا توجّه أداتين أبداً إلى المجلد نفسه. - [ ] أودِع كلاً من
CLAUDE.mdوAGENTS.md، بحيث يشير كل منهما إلى ملف أعراف مشترك واحد في المصدر المتتبَّع. - [ ] تأكد من أن كل أداة تحمّل إعدادها من جذر شجرة العمل قبل أن تسند أي عمل.
- [ ] أسند مهمة واحدة محددة النطاق لكل وكيل. العمل واسع السياق لأحدهما، والعمل الضيق القائم على الاختبارات للآخر.
- [ ] حدّد بوابة المراجعة مسبقاً: لا يُدمج أي فرع حتى يقرأ شخص الفرق ونتائج الاختبارات.
- [ ] عندما تتجاوز جولتين أو ثلاث جولات متزامنة، توقف عن توسيع bash وانقل الإسناد والحالة والمراجعة إلى طبقة واحدة.
إذا أردت الاستمرار في استخدام Claude Code وCodex معاً بدلاً من الالتزام بمنظومة واحدة، فهذه هي المشكلة التي صُمم Sharkly من أجلها. نزّل Sharkly، وصِل Computer واحداً، وأسند مهمتك الأولى إلى الوكيل الذي يناسب العمل.
الأسئلة الشائعة
هل يمكن لـ Claude Code وCodex تحرير الملفات نفسها بأمان؟ ليس في المجلد نفسه. امنح كل منهما شجرة عمل git خاصة به ليعملا على فرعين منفصلين، ثم ادمج عبر المراجعة. فالتزامن في المجلد نفسه هو حيث يُفقد العمل غير المُودَع.
هل أحتاج إلى اشتراكين؟ تحتاج إلى ما تتطلبه كل أداة. يستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيّأة في Claude Code وCodex؛ ولا تغيّر طبقة التنسيق هذا الوصول ولا تعيد بيعه.
هل لوح المهام مبالغة بالنسبة لوكيلين؟ بالنسبة لوكيلين تتحكم فيهما في جلسة واحدة، تكفي أشجار العمل العادية وطرفيتان. أما اللوح فيستحق مكانه عندما يحتاج أحد أعضاء الفريق إلى رؤية واضحة أو يرتفع عدد الجولات. راجع أفضل الأدوات لإدارة وكلاء البرمجة بالذكاء الاصطناعي المتوازيين.
