مطوّر فردي مع Claude Code قصّة إنتاجيّة. فريق مع Claude Code سؤال operating model.

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

إليك ما ينجح، وما لا ينجح، والأنماط التي سأسرقها.

مجلّد .claude/ المشترك هو الانفراج

Commit لـ .claude/ في الريبو. كلّه.

• CLAUDE.md — سياق المشروع، الاتفاقيات، قائمة "لا تُعدّل أبدًا".
• .claude/settings.json — قائمة سماح / منع للأدوات.
• .claude/agents/*.md — طاقم sub-agents الخاصّ بك.
• .claude/commands/*.md — slash commands الخاصّة بك.

يحصل الجميع في الفريق على نفس operating model عند git pull. ينتقل onboarding من "دعني أُريك prompts الخاصّة بي" إلى "اقرأ .claude/، ستفهم".

ملكيّة الوكلاء — اختر مشرفًا

كلّ sub-agent يجب أن يكون له owner في الفريق. ليس لأنّ الوكلاء معقّدون (ملف .md)، بل لأنّ الوكلاء ينحرفون.

code-reviewer كُتب لفريق من 5 مهندسين في الشهر الأوّل سيكون خاطئًا في الشهر السادس. على شخص ما أن:

• يقرأ ردود فعل المراجعة التي يطرحها الوكيل.
• يلاحظ متى يفوت صنفًا من الأخطاء.
• يحدّث system prompt.

عامل الـ sub-agents كبنية تحتيّة. مملوكون، مُصدَّرون، مُراجَعون في PRs.

طقوس PR تتغيّر مع Claude Code

ثلاث طقوس رأيتها تنجح:

1. PRs مكتوبة بالذكاء الاصطناعي تُعلن ذلك

أضف label أو قسمًا في قالب الـ PR:

## بمساعدة ذكاء اصطناعي

- Implementer: نعم / لا
- مؤلّف الاختبارات: إنسان / ذكاء اصطناعي
- Code reviewer (قبل الـ PR): لا / وكيل `code-reviewer`

ليس بيروقراطيّة. هو إشارة. حين ينكسر شيء، تريد معرفة أيّ صنف من التأليف عليك التحقيق فيه.

2. مراجعة بمستويين

لـ PRs > 200 سطر أو تلمس مسارات حرجة:

• المستوى 1: وكيل code-reviewer (قبل الـ push).
• المستوى 2: مراجع بشريّ (بعد الـ push).

لكلّ ما عداها، تكفي إجازة الوكيل + مراجعة المؤلّف للـ diff. توقّف عن التظاهر بأنّك تقرأ كلّ سطر في كلّ PR أقلّ من 50 سطرًا.

3. مراجعة كود "diff-first"

يتوقّف المراجعون عن فتح الملفات. يقرؤون الـ diff في gh pr diff ويثقون بمجموعة الاختبارات. يبدو هذا متهوّرًا حتى تدرك أنّه السلوك الصحيح منذ سنوات — كان البشر سيّئين فيه فقط.

تجعل مراجعة-كوكيل في Claude Code نموذج "diff-first" أمينًا: وكيل منفصل دقّق فيها بحثًا عن الواضح قبل أن يلمسها إنسان.

ما لا ينجح

قائمة قصيرة لأنماط تبدو مكاسب لكنّها ليست كذلك:

• رخصة Claude Code واحدة، يتشاركها الفريق. يدمّر التخصيص، يدمّر مسارات التدقيق، يخلق كابوس صلاحيات. رخص لكلّ مستخدم، نقطة.
• "عروض sprint AI" يقطف المديرون فيها أفضل PRs. تحيّز نجاة. تتبّع مقاييس مجمّعة، لا highlight reels.
• منع Claude Code من الخدمات "الحرجة". عكس الحركة الصحيحة. تحتاج الخدمات الحرجة إلى أكثر sub-agents انضباطًا وأقصى allowlists، لكنّها الأكثر استفادة من الـ workflow.
• إجبار الجميع على استعمال نفس الـ prompts. شجّع .claude/commands/ المشترك؛ قاوم فرض الأسلوب الشخصيّ. يكتب الناس prompts بشكل مختلف وهذا عاديّ.

ما يتغيّر لمديري الهندسة

ثلاثة أمور تتحوّل فعلاً:

1. تصبح السرعة أكثر وضوحًا

يمكنك سحب إحصائيات من ~/.claude/sessions/ (أو ما يكافئ ذلك في log shipping). متوسّط الزمن لكلّ ميزة، متوسّط جولات الوكيل قبل الأخضر، نسبة PRs التي تنجح في المراجعة من المحاولة الأولى.

هذه البيانات جيّدة. استخدمها للتشخيص ("الفريق يعاني من الميزة X") لا لتقييمات الأداء ("استعملت الوكيل أقلّ").

2. يميل onboarding نحو قاعدة الكود

يصبح الموظّف الجديد منتجًا بسرعة أكبر — ليس لأنّه أذكى، بل لأنّ .claude/CLAUDE.md والـ sub-agents تُحمّل مسبقًا كلّ المعرفة القبليّة لقاعدة الكود.

أهّلت مهندسين في يومين كانوا سيستغرقون أسبوعين قبل Claude Code. صارت قاعدة الكود موثّقة ذاتيًا تحت التعليمات.

3. يُعاد توزيع وقت الكبار

يتوقّف المهندسون الكبار عن كتابة boilerplate. يراجعون مزيدًا من الـ diffs، يكتبون مزيدًا من CLAUDE.md، يصمّمون مزيدًا من الـ ADRs. يتولّى الوكيل الكتابة؛ ويتولّى السنير البنية.

هذا تحوّل حقيقي. بعض الكبار يحبّونه. بعضهم يفتقد الكتابة. كلاهما مشروع. اعترف فقط بأنّ التحوّل يحدث.

الخطأ الفريقيّ الأكثر شيوعًا

السماح لـ Claude Code بدخول قاعدة الكود دون .claude/ مشترك أوّلاً.

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

اقضِ يومين في كتابة .claude/ المشترك. عرّضه للفريق. Commit. ثمّ اطلق Claude Code.

خطّة تشغيل ناجحة في 30 يومًا

• الأسبوع 1: 2 إلى 3 من المهندسين الكبار يستعملون Claude Code على تذاكر opt-in. يكتبون النسخة الأولى من .claude/.
• الأسبوع 2: افتحه لباقي الفريق. امنعه على ترحيلات الإنتاج وPRs البنية التحتيّة. اجتماع يومي 15 دقيقة "ما نجح / ما فشل" مخصّص لـ workflow الوكيل.
• الأسبوع 3: تقنين الـ sub-agents. تبنّي طقوس المراجعة. وضع المقاييس.
• الأسبوع 4: ارفع منع الإنتاج للمهندسين الذين شحنوا 3+ PRs بمساعدة الذكاء الاصطناعي. أبقِ منع البنية التحتيّة الآن.

بحلول الشهر الثاني، Claude Code هو فقط "كيف نعمل". لا أحد يتحدّث عنه تحديدًا بعد ذلك. هذا الهدف.

---

المقال التالي: أنماط متقدّمة — hooks، خوادم MCP، أدوات مخصّصة، وsystem prompts. الأمور التي تبنيها حين تتجاوز الإعدادات الافتراضيّة.