بين يدي فريقك playbooks الهندسة — الأنظمة المُجرَّبة لرسم خريطة codebase، وشحن ميزة، واستكمال الاختبارات، وإدارة migration. تلك تقول لمهندسيك ماذا يفعلون. وهذا الدليل هو الطبقة التي تحتها: نموذج التشغيل الذي يُبقي العمل مُراجَعًا ومُثبَتًا ومملوكًا لمن يُسأل عنه وآمنًا وهم يعملون. كُتب لقائد هندسي يطرح Claude Code على فريق يعرف البرمجة أصلًا — لا لمجرِّب منفرد.
الخطأ الواحد الذي يحوّل طرح الذكاء الاصطناعي إلى حادثة ليس prompt رديئًا — بل غياب قاعدة عن من يقرأ الـ diff، وما الذي يثبت الإصلاح، ومن يستطيع أن يُسأل عن الـ merge. وليس شيء ممّا يلي إجراءات ثقيلة؛ إنها حفنة الضوابط التي تتيح لفريقك أن يتحرك بسرعة لأن الحدود واضحة.
نموذج التشغيل: Claude يكتب مسودة الكود، وأنت صاحب التوقيع
ابدأ بالمبدأ الذي يتفرّع عنه كل ما عداه: Claude يكتب المسودة؛ والإنسان يقرّر. إنه أسرع مهندس مبتدئ عملتَ معه — لا يكلّ من التنفيذات الأولى والقراءات والاختبارات والـ migrations — وليس عنده حُكم ولا مساءلة، ومن عادته أن يخطئ بثقة.
فقسمة العمل ثابتة لا تتبدّل:
- Claude يتولّى الشوط من الصفر إلى المسودة: ينفّذ الميزة، ويكتب الاختبارات، ويرسم خريطة repo لا تعرفه، ويدير الـ migration الآلية، ويساند المراجعة.
- والإنسان يتولّى القرار: يقرأ الـ diff، ويثبت التعديل باختبار، ويعتمده، ويدمجه.
الفريق الذي يستوعب هذا يكسب السرعة بلا مخاطرة. والفريق الذي ينساه يدمج تعديلًا خاطئًا واثق النبرة الساعة الخامسة من مساء الخميس. الـ playbooks كلها مبنية على هذا الخط — توصلك إلى مسودة قوية بسرعة، ثم تعيد الحُكم إلى يدك عمدًا. تبقى أنت صاحب التوقيع: اسمك على الـ commit، فعيناك على الـ diff.
ما الذي تشاركه بأمان — وما الذي لا تشاركه
على Desktop، المجلد المفتوح هو الحدّ — لا يرى Claude إلا ما فتحتَه — ونافذة Ask permissions تستأذنك قبل كل قراءة. وهذا يجعل قاعدة البيانات بسيطة القول سهلة الاتباع:
- آمن للمشاركة: الـ repo المصدري، والـ diff قيد المراجعة، والـ stack traces والمخرجات الفاشلة، ووثائقكم وتذاكركم، والاعتماديات العامة.
- يبقى خارج المحادثة: الأسرار، وبيانات الاعتماد، ومفاتيح الـ API، والـ tokens؛ وبيانات العملاء والبيانات الشخصية؛ وكل ما هو تحت اتفاقية سرّية؛ وبيانات الإنتاج. هذه لا مكان لها في prompt، أبدًا.
عادتان تجعلان هذا تلقائيًا. الأولى: افتح الـ repo الذي تحتاجه المهمة وحده — إصلاح خطأ في ملف واحد لا يحتاج الـ monorepo كله وثلاث خدمات شقيقة في السياق. والثانية: أبقِ الأسرار في مكانها — في ملفات الـ env ومدير الأسرار، تُقرأ وقت التشغيل، ولا تُلصق في محادثة ولا تُرتكب في الـ repo. وplaybook الـ project-context يخبز هذا في CLAUDE.md عندكم: يوثّق أين تعيش بيانات الاعتماد كي تبقى خارج السياق، ولا يحمل هو نفسه مفتاحًا واحدًا.
بوابة المراجعة والإثبات
أسرع طريق لخسارة الثقة التي تبنيها أن تدع السرعة تقفز فوق المُراجِع. فضع بوابة واحدة بين المسودة والـ merge، وسمِّها صراحةً:
- كل diff يقرؤه إنسان — صاحب التوقيع يقرؤه سطرًا سطرًا قبل الاعتماد. على Desktop ذلك هو عرض القبول والرفض المرئي للـ diff، فأنت تراجع أولًا بأول، لا تختم على جدار كود في النهاية.
- كل إصلاح يثبت نفسه باختبار يفشل على السلوك القديم وينجح على الجديد. التعديل الذي لا يحمل اختبارًا فاشلًا حوّله إلى أخضر تخمينٌ. اجعل الوكيل يريك الأحمر، ثم الأخضر.
- العمل غير التافه يبدأ بخطة. استعمل plan mode لتأخذ المنهج نثرًا وتقرأه وهو رخيص — تصحيح فقرة خاطئة يكلّف دقيقة؛ وتفكيك diff خاطئ من 300 سطر يكلّف أمسية.
- الوكيل يدير حلقتكم الحقيقية، وأنت تثق بالأحمر. اربط حزمة الاختبارات ومدقق الأنواع والـ linter كي يرى Claude إخفاقاته بنفسه ويصحّح ذاتيًا. وكيل يرى الأحمر خير من عشرة لا يملكون غير الاستدلال على الكود.
هذه ليست بيروقراطية أُلصقت في الآخر — إنها خطوة واحدة مسمّاة في سير العمل. وplaybook الـ code-review والـ ship-a-feature يمرّران كل تعديل عبرها بحكم البناء. والكود المنظَّم رقابيًا أو الحساس أمنيًا يجتاز المراجعة المعتادة وتوقيع الأمن وفحص الامتثال — لا تلويحة «الذكاء الاصطناعي كتبه».
من يملك ماذا (RACI خفيف)
السرعة تموت في غموض «من يستطيع الدمج». لا تحتاج مصفوفة RACI رسمية — تحتاج أربعة أدوار مسمّاة لأي قطعة عمل:
- يُسوِّد — المهندس الذي يشغّل الـ playbook مع Claude.
- يُراجِع — الزملاء، ومعهم مالك الكود في المساحة الملموسة.
- يعتمد — القائد التقني أو من يُسأل عن تلك المساحة.
- يشحن / يدمج — إنسان يضغط زرّ الـ merge، ويملك النتيجة، ويستطيع أن يُسأل عنها.
والمقصود أن Claude ليس واحدًا من الأربعة أبدًا. إنه الأداة التي يستعملها دور التسويد — ليس مُراجِعًا، ولا مُعتمِدًا، ولا اسمًا على الـ merge أبدًا. اكتب هذه الأسماء الأربعة مرة واحدة لكل مساحة (الخدمة، والحزمة، والمنطقة)، ويختفي معظم حالات «من اعتمد هذا؟». المساءلة لا بد أن تقع على إنسان، لأن الوكيل لا يملك منها شيئًا يقدّمه.
العمل بلغتين: العربية والإنجليزية
لفريق يعمل في المنطقة، ليست الثنائية اللغوية خطوة ترجمة تُلصق في آخر المشروع — إنها طريقة عمل الفريق فعلًا. والقاعدة الحاكمة: كيّف، لا تمرّر على الترجمة الآلية.
- الكود يبقى إنجليزيًا؛ والنقاش يتبع قارئه. المعرّفات وأسماء الدوال وعناوين الـ commit تبقى إنجليزية — تلك هي الطبقة الكونية التي تقرؤها كل أداة وكل زميل. أما وثائق التصميم والـ ADRs والـ RFCs وأوصاف الـ PR وتعليقات المراجعة فتستحق أن تُكتب باللغة التي يقرؤها المُراجِع فعلًا.
- كيّف، لا تترجم. اطلب من Claude أن يؤلّف الـ ADR أو وصف الـ PR بالعربية من البداية، لا أن يترجم مسودة إنجليزية — وثيقة التصميم التي تُقرأ عربية أصيلة تحمل المنطق خيرًا من أخرى تُقرأ مترجمة آليًا. والأمر نفسه للإنجليزية.
- البوابة نفسها للغتين. وثيقة تصميم أو وصف PR بالعربية يجتاز المراجعة نفسها التي يجتازها الإنجليزي. لا تدع اللغة الثانية تفلت من التوقيع لأن أحدًا في سلسلة الاعتماد لا يقرؤها — جِد مُراجِعًا يقرؤها. بوابة المراجعة والإثبات تسري أيًا كانت لغة النثر؛ وحزمة الاختبارات لا لغة لها وتبقى الكلمة الفصل.
هكذا تكون العربية ندًّا كاملًا للإنجليزية في مؤسستك الهندسية، لا فكرة لاحقة — وهذا، في هذه المنطقة، هو ما يجعل التوثيق يُقرأ فعلًا.
مسار القدرات: من أول قراءة إلى التحديث الشامل
الـ playbooks مرتّبة مسارًا متدرّجًا، لا قائمة مسطّحة، لأن المتأخر منها يعتمد فعلًا على المتقدّم. أدخِل الفريق فيها بالترتيب:
- المرحلة 1 — الأسس. القراءة قبل أي كتابة: ارسم خريطة codebase لم تره من قبل، ثم قطّر تلك القراءة في سياق المشروع — ملف
CLAUDE.mdالذي يؤسس كل مهمة لاحقة على أعرافكم الحقيقية والأمر الذي يشغّل اختباراتكم بالحرف. تجاوزهما وستبدأ كل مهمة لاحقة من تخمين. - المرحلة 2 — الأنظمة المتكررة. الحلقات الأسبوعية، كل واحدة خلف بوابة المراجعة والإثبات: التشخيص من trace، واستكمال الاختبارات التي لم تُكتب يومًا، والـ refactor الآمن خلف حزمة خضراء، وشحن ميزة من أولها إلى آخرها، ومراجعة الكود قبل أن يراجعه إنسان، وسير عمل git نظيف بـ commits منطقية تشرح اللماذا.
- المرحلة 3 — الإدارة المتكاملة. اللحظات الكبرى المتعددة الملفات التي تستجمع كل أساس وكل نظام: الـ migration الآلية، وتحديث نظام فرعي كامل، وتولّي codebase موروث من أوله إلى آخره.
وعلى صفحة فريق الهندسة يظهر المسار مرحلةً مرحلة مع شريط تقدّم، ويستطيع فريقك تأشير كل playbook أُنجز — فيصير «نحن نطوّر قدرات الفريق» رقمًا تراه فعلًا، لا أمنية. (التقدّم يُتتبَّع على جهاز كل شخص؛ وعرض جماعي على مستوى المدير هو الخطوة الطبيعية التالية بعد أن تُكمِلوا المسار.)
الطرح: خطة 30/60/90
لا تطرح كل شيء على الجميع من اليوم الأول — فهكذا تخبو الطروحات. درِّجه كما دُرِّج المسار. هذا هو القوس كله، قائمةً تنسخها إلى وثيقتك:
30/60/90 — طرح Claude على فريق هندسي
أول 30 يومًا — الأسس
- اختر 2–3 مهندسين راغبين عبر المساحات الأهم.
- ابنوا CLAUDE.md للـ repo: البنية، وأوامر التطوير الحقيقية، والأعراف.
- اتفقوا على ضابط الصفحة الواحدة: ما الذي يجوز مشاركته، ومن يدمج.
- يشغّل كل مهندس أول playbook من المرحلة 1 كاملًا (الخريطة + السياق).
الأيام 30–60 — الأنظمة المتكررة
- ضعوا الحلقات الأسبوعية على Claude: التشخيص، والاختبارات، والـ
refactor، والشحن، والمراجعة، وgit.
- وثّقوا الـ prompts الناجحة في CLAUDE.md وslash commands.
- سمّوا أدوار RACI الأربعة لكل مساحة: يُسوِّد / يُراجِع / يعتمد / يدمج.
الأيام 60–90 — الإدارة المتكاملة
- أديروا تحديثًا أو migration حقيقيًا واحدًا كاملًا عبر الـ playbooks.
- ثبّتوا بوابة المراجعة والإثبات خطواتٍ مسمّاة: قراءة الـ diff، وإثبات
الإصلاح باختبار، وplan mode للعمل غير التافه، ومراجعة الكود المنظَّم.
- راجعوا مسار القدرات: من أكمل أي مرحلة، وأين الفجوات، وأي مقاعد
تُضاف بعد ذلك.الرغبة في فرضه على الجميع دفعةً واحدة هي الرغبة التي تُقاوَم. التبنّي عادة تنتشر، لا مفتاح يُقلب. أدخِل قلة من المهندسين في الأسس، وأعطهم CLAUDE.md الـ repo وقاعدة من صفحة واحدة، ودعهم يوثّقون ما ينجح — وبحلول اليوم التسعين يكون عندك فريق أدار migration حقيقية عبر النظام، وبوابة مراجعة وإثبات يثق بها الجميع، والدليل الذي تحتاجه لتوسيعه. وplaybook طرح Claude على الفريق يتعمّق في الآليات العابرة للأدوار حين تصبح جاهزًا لتوسيعه خارج الهندسة.