Claude Code بـ 29 أداة مقابل Codex بـ 7 أدوات: فلسفتا التصميم على طرفي نقيض

مللت من متابعة التحديثات الأسبوعية لكلٍّ من Claude Code وCodex، فعدت إلى المبادئ الأساسية. فتحت كل تعريف نوع في SDK، وكل أمر نظام، وكل مخطط إعدادات توصلت إليه. أردت أن أفهم ليس فقط ما تفعله كل أداة، بل لماذا يتباعد عدد الأدوات بهذا الشكل الكبير.

يكشف Claude Code عن 29 أداة، بينما يكشف Codex عن 7 أدوات فحسب. ظلت هذه النسبة تراودني، لأنها لا يمكن أن تكون مجرد فجوة في الميزات. فريقان ممولان بشكل جيد مع مهندسين من الطراز الأول لا يصلان عن طريق الصدفة إلى نسبة 4:1. الفجوة مقصودة، والمنطق وراءها يكشف عن فلسفتين مختلفتين حقاً حول كيفية تفاعل الذكاء الاصطناعي مع بيئة التطوير لديك.

دقة الأداة قرار أمني

الفرق الأكثر لفتاً للانتباه هو كيفية تعامل كل أداة مع عمليات الملفات. يقسّم Claude Code التعامل مع الملفات إلى أربع أدوات منفصلة: Read وWrite وEdit وMultiEdit. كما تحصل عمليات البحث على أدواتها المخصصة، إذ يعمل Grep وGlob بشكل مستقل تماماً عن Bash. هذا يعني أنه يمكنك تهيئة settings.json للسماح بـ Read مع حظر Write. يمكنك السماح للوكيل بالبحث في قاعدة الكود الخاصة بك دون أن تمنحه إذناً لتعديل ملف واحد. يتم التحكم في الأذونات على مستوى الأداة.

يسلك Codex مساراً مختلفاً. يمنح الوكيل shell وapply_patch وfile_read كعناصر بدائية أساسية. كل شيء آخر يمر عبر shell. هل تريد البحث في الملفات؟ هذا أمر shell. هل تريد إدراج المجلدات؟ shell أيضاً. لا يأتي الأمان من أذونات على مستوى الأداة، بل من قواعد execpolicy التي تطابق أنماطاً محددة مع أوامر shell، وتصنفها إلى فئات allow وprompt وblock.

لا يوجد نهج خاطئ هنا. يمنحك نموذج Claude Code أقفالاً دقيقة لكنه يتطلب الحفاظ على سطح أدوات أكبر. نموذج Codex أبسط في التفكير، لكنه يدفع تطبيق الأمان إلى مطابقة السلاسل النصية لأوامر shell، وهو ما يصبح هشاً عندما تصبح الأوامر معقدة. رأيت حالات تجاوزت فيها سلسلة pipe محكمة الصياغة قاعدة execpolicy كُتبت للإصدار المباشر من الأمر ذاته.

التفصيل الكامل:

• Claude Code (29 أداة): 4 أدوات للملفات (Read/Write/Edit/MultiEdit)، 3 أدوات بحث (Glob/Grep/LS)، أداتا ويب، 3 أدوات cron، 4 أدوات MCP، Bash، والمزيد
• Codex (7 أدوات): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

توزيع المهارات يقسّم النظام البيئي

اعتمدت كلتا الأداتين المعيار المفتوح Agent Skills، حيث يعرّف ملف SKILL.md واحد سلوك المهارة. البنية متطابقة. نموذج التوزيع ليس كذلك.

بنى Codex نظام توزيع مركزياً. تشغيل $skill-installer يسحب المهارات المنتقاة من مستودع المهارات الرسمي لـ OpenAI. مرر رابط GitHub ويمكنك تثبيت مهارات من أطراف ثالثة أيضاً. يوجد حتى $skill-creator لإنشاء مهارات جديدة بشكل تفاعلي عبر المحادثة. التجربة تشبه npm: أمر واحد، سجل واحد، وتوفر فوري.

سار Claude Code في الاتجاه الآخر. تنشئ ملفات SKILL.md في .claude/skills/ يدوياً، أو تثبّت حزماً من مستودعات git عبر /plugin marketplace add. لا يوجد سجل رسمي واحد. تُكتشف المهارات من خلال مستودعات المجتمع والروابط المشتركة وتبادل المعلومات.

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

مقارنة سريعة:

• الاستدعاء: Claude Code يستخدم /skill-name، وCodex يستخدم $skill-name
• التخزين: .claude/skills/ مقابل .agents/skills/
• المهارات المدمجة: يشحن Claude Code مع /simplify و/batch و/loop و/claude-api؛ يشحن Codex مع $skill-installer و$skill-creator
• التوزيع: سوق لامركزي مقابل مستودع مركزي

تشخيص الجلسة حيث تتجلى الفجوة الحقيقية

تتشارك كلتا الأداتين الأساسيات: /model و/plan و/review و/clear و/fast. يظهر الاختلاف في فحص الجلسة الداخلي.

استثمر Claude Code كثيراً في تمكينك من فهم ما يجري داخل جلستك. /compact يشغّل ضغط السياق يدوياً. /context يعرض ما هو محمّل. /cost يتتبع إنفاق الرموز في الوقت الفعلي. /doctor يشخّص مشاكل الإعداد. /rewind يعود إلى حالة محادثة سابقة. /insights يحلل شهراً من أنماط الاستخدام ويقترح تحسينات. /usage يعرض الاستهلاك التراكمي عبر الجلسات. هذه سبع أوامر مخصصة تماماً لفهم حالة الجلسة وإدارتها.

ركّز Codex على أمور أخرى. /personality يضبط أسلوب تواصل الوكيل. /theme يغير المظهر البصري. /apps يدير التطبيقات المتصلة. هذه ميزات تخصيص تجربة المستخدم، وليست أدوات تشخيص.

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

• Claude Code (نحو 35 أمراً بالإضافة إلى 4 مهارات مدمجة): تركيز كبير على تشخيصات الجلسة مثل /compact و/context و/cost و/doctor و/rewind و/insights و/usage
• Codex (نحو 19 أمراً): أقوى في تخصيص تجربة المستخدم مع /personality و/theme و/copy و/apps و/skills و/agent و/tools

بنى الفريق تنطلق من افتراضات مختلفة

كيفية تعامل كل أداة مع التعاون متعدد الوكلاء تكشف ربما أعمق فرق في التصميم.

تستخدم فرق الوكلاء في Claude Code التواصل النظير إلى نظير. يرسل أعضاء الفريق رسائل مباشرة لبعضهم البعض دون التوجيه عبر وكيل رئيسي. يتشاركون قائمة مهام وينسقون بشكل مستقل. يمكنك تشغيل ما بين 2 إلى 16 وكيلاً، وسيتفاوضون فيما بينهم حول من يتعامل مع ماذا. اختبرت هذا مع ثلاثة وكلاء في مهمة إعادة هيكلة، وكان استهلاك الرموز 3 إلى 7 أضعاف مقارنة بجلسة واحدة تؤدي نفس العمل. تكلفة التنسيق حقيقية. لكن عندما تستفيد المهمة فعلاً من الاستكشاف المتوازي (كتصحيح حالة سباق حيث تريد وكلاء يستكشفون فرضيات مختلفة في آنٍ واحد)، يجد نموذج P2P إجابات أسرع.

يستخدم Codex نموذج المركز والأطراف (hub-spoke). يرفع وكلاء الأطراف تقاريرهم للوالد فحسب. لا يوجد تواصل جانبي. أمر spawn_agents_on_csv ينشئ وكلاء بالجملة من ملف CSV، وهو محسّن للمهام المتوازية بشكل مثير حيث كل وحدة عمل مستقلة. فكّر في: “طبّق هذا الترحيل على 200 ملف” أو “شغّل هذا الفحص على كل نقطة نهاية في هذه القائمة.”

P2P ليست أفضل في كل الحالات. أهدرت رموزاً كثيرة في مهمة دفعات مباشرة لأن وكلاء Claude Code ظلوا يناقشون أعمالهم المتداخلة مع بعضهم. كان نموذج hub-spoke لـ Codex هو الخيار الصحيح لتلك المهمة بالتحديد.

• Claude Code: مراسلة P2P مع قائمة مهام مشتركة، 2 إلى 16 وكيلاً، دعم tmux split-pane
• Codex: بنية hub-spoke، إنشاء وكلاء بالجملة من CSV عبر spawn_agents_on_csv

دقة الخطافات تحدد عمق الأتمتة

يتيح لك Claude Code اعتراض تنفيذ الأداة في نقاط متعددة من دورة الحياة. يُطلق PreToolUse قبل تشغيل أداة، مما يتيح لك التحقق من الاستدعاء أو تعديله. يُطلق PostToolUse بعد ذلك، حتى تتمكن من إرفاق منسّق يعمل تلقائياً مع كل حفظ للملف. تلتقط خطافات Notification اتصالات الوكيل. يُطلق PreCompact قبل ضغط السياق، مما يمنحك فرصة للحفاظ على المعلومات الحرجة. يمكن لـ HTTP Hooks نشر JSON إلى روابط خارجية، مما يربط Claude Code بأنابيب CI وSlack أو لوحات معلومات مخصصة.

يبقي Codex الأمر بسيطاً. ملف execpolicy واحد بقواعد allow/prompt/block مطبقة على أوامر shell. هذا هو سطح قابلية التوسع بالكامل للتحكم في سلوك الوكيل.

أعددت خطاف PostToolUse يشغّل Prettier بعد كل عملية Write. استغرق ذلك خمس دقائق وأزال فئة كاملة من طلبات المتابعة المتعلقة بالتنسيق. هذا النوع من الأتمتة الجراحية غير ممكن في نموذج Codex، حيث ستحتاج إلى تضمين “وشغّل prettier بعد الكتابة” في كل طلب أو بناء ذلك في مهارة.

لكن لبساطة Codex قيمة أيضاً. لم أكسر إعداد Codex الخاص بي أبداً بسبب خطاف مهيأ بشكل خاطئ. فعلت ذلك مرتين مع Claude Code، مرة بخطاف PreToolUse منع بصمت قراءات ملفات مشروعة وتسبب في عشرين دقيقة من التصحيح المحير.

• Claude Code: PreToolUse وPostToolUse وNotification وPreCompact وHTTP Hooks
• Codex: ملف قواعد execpolicy بثلاثة مستويات (allow/prompt/block)

اختر البنية، لا قائمة الميزات

المقارنة بين 29 و7 لا تعني أن إحدى الأداتين أكثر قدرة من الأخرى. إنها تعني إجابتين مختلفتين على نفس سؤال التصميم: إلى أي مدى يجب أن يقوم وكيل الذكاء الاصطناعي للبرمجة بتجزئة قدراته إلى وحدات قابلة للتحكم بشكل منفرد؟

يقول Claude Code “كل شيء”. كل عملية تحصل على أداتها الخاصة، وسطح أذوناتها الخاص، ونقاط خطافها الخاصة. هذا يمنحك أقصى قدر من التحكم على حساب تعقيد الإعداد. يقول Codex “الأساسيات فقط”. تحصل العمليات الجوهرية على أدوات مخصصة؛ كل شيء آخر يتدفق عبر shell مع حواجز حماية قائمة على السياسات. هذا يمنحك البساطة على حساب الدقة.

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