الهندسة
أنت تعرف البرمجة أصلًا. هذا هو الجزء الجديد — أن تُسلّم عملًا حقيقيًا إلى agent يقرأ الـ repo كله، ويكتب الـ tests، ويريك الـ diff قبل أن يهبط أي شيء.
أنظمة عمل كاملة، لا prompts منفردة — كلٌّ منها يمشي بك خلال الـ workflow كاملًا من البداية إلى النهاية. اختر واحدًا واتبعه.
ارسم خريطة codebase لم ترَه من قبل
وجّه Claude إلى repo غير مألوف واحصل على جولة راسخة — الـ modules الحقيقية، وكيف يتدفّق request، وأين تعيش الأجزاء المخيفة — بالإنجليزية البسيطة، مسمّيًا ملفات موجودة فعلًا.
اكتب الـ CLAUDE.md الذي يرسّخ كل مهمة
ابنِ الـ `CLAUDE.md` الخاص بالمشروع مرّة واحدة — البنية المعمارية، وأوامر التطوير الحقيقية، والأعراف التي تعيش في رؤوس الناس — فتبدأ كل مهمة لاحقة راسخةً بدل التخمين، للفريق كلّه.
تتبّع bug حتى root cause وأثبت أن الإصلاح صحيح
سلّم Claude الـ stack trace كاملًا والـ input الذي يُفشِل العملية، فتحصل على قائمة مرتّبة بالأسباب المرجّحة مع مؤشّرات `file:line`، ثم إصلاحًا مع test يفشل على الكود القديم وينجح على الجديد.
اكتب الـ tests التي لم تكتبها قط
خذ module بلا tests، واجعل Claude يُعدّد السلوكيات الجديرة بالتثبيت — بما فيها الـ edge cases الخبيثة — ويكتب suite يغطّيها، مع التنبيه على أي bugs كامنة يجدها في الطريق.
نفّذ refactor بأمان خلف green suite
نظّف ملفًا متشابكًا بلا تغيير في الـ behaviour — مستخدمًا الـ test suite كحزام أمان، تُشغّله قبل وبعد كي تُثبت أن شيئًا لم يُكسَر بدل أن تأمل ذلك.
أطلِق ميزة من البداية إلى النهاية — خطّط، ابنِ، اختبر، commit
شغّل الـ loop الكامل لـ Stage-2 على ميزة واحدة: اكتب spec محكمًا، احصل على الخطة قبل كتابة أي سطر، دع Claude يُنفّذ خلف suite خضراء لديك، ثبّت السلوك الجديد بـ tests، اقرأ الـ diff كاملًا، ثم commit في أجزاء منطقية نظيفة.
راجِع PR كأنك خبير متشكّك — قبل أن توافق
استخدم Claude كمراجع أول سريع وعدائي على diff أو PR — الصحّة، الـ edge cases، الأمان، قابلية التشغيل — ثم تحقّق من كل ملاحظة مقابل الكود بنفسك، لأنه سيشير بثقة إلى «bug» ليس bug. ما زلت تملك أنت الموافقة.
فُكّ فوضى git والتزِم بـ commits نظيفة ومنطقية
حوّل working tree فيه ثلاثة شواغل غير مترابطة وmerge نصف منجز إلى تاريخ نظيف قابل للمراجعة — يشرح Claude الحالة الراهنة بلغة واضحة قبل أن يمسّ أي شيء، ثم يساعدك على staging كل شاغل والـ commit عليه على حِدة برسائل تقول *لماذا*.
نفّذ migration واسعة ومملّة بلا أن تكسر شيئًا
التغيير الذي يعمّ الـ repo والذي كنت تتهيّبه — استبدال library، إعادة تسمية API، ترقية نمط عبر 80 ملفًا — منجَزًا في مسحة واحدة، مع قائمة واضحة بالحالات التي لم يستطع تحويلها واحدة بواحدة كي تقرّرها أنت يدويًا.
حدّث subsystem قديمًا بخطة وفريق agents
الـ subsystem القديم الذي يخشاه الجميع — الـ auth، أو الـ payments adapter، أو الـ ORM المصنوع داخليًا — يُعاد بناؤه كحملة مُخطَّطة ومُرحَّلة وخضراء باستمرار بدل rewrite كبير دفعةً واحدة. الكبير الذي يجمع كل playbook هندسي آخر في قوس واحد.
انضمّ إلى codebase غريب وأطلِق أول إصلاح لك
القوس الكامل — أسبوعك الأول على repo لم تره من قبل، وbug في الـ production، وكاتبه رحل منذ زمن — وصولًا إلى إصلاح مُراجَع ومُختبَر تفهمه. الكبير الذي يربط كل playbook هندسي آخر معًا.
الهندسة مع Claude، بتعمّق
الـ playbooks أعلاه مهامّ مفردة. وهذه هي القراءات المطوَّلة خلفها — كيف يتّسق العمل عبر ربع سنة كامل، وكيف يبدو الجيّد منه، وأيّ الأحكام تفترض الـ prompts أنك اتخذتها سلفًا. اقرأها بأيّ ترتيب.
- Codebase-in-a-Box — المشروع الختامي لمسار الهندسة المشروع الختامي لمسار الهندسة — تدمج فيه الوحدات الخمس في قوس هندسي واحد على codebase واحد: ترسم خريطته وتوثّقه، وتدير مراجعة كود متحقَّقًا منها، وتشحن ميزة خلف حزمة خضراء، وتعيد الهيكلة بأمان، وتنفّذ migration بقرارات موثَّقة. اجتزه لتنال اعتماد «الهندسة مع Claude».
- أساس الهندسة: الـ codebase الذي تعدّله بثقة الوحدة الأولى من تعمّقات الهندسة — تتجاوز فيها الوصفة الجاهزة إلى إتقان الوثائق الثلاث التي يرثها كل PR وكل refactor وكل migration: خريطة المعمارية، وملف سياق المشروع، وانضباط الـ commit. تبنيها لـ codebase حقيقي. الوحدة مفتوحة مجانًا للتجربة.
- التغيير الآمن: refactor خلف حزمة خضراء، لا على حسن الظن الوحدة الرابعة من تعمّقات الهندسة — تُتقن فيها انضباط الـ refactor الذي يجعل التنظيف البنيوي شيئًا تقف وراءه في المراجعة: تثبّت الأساس الأخضر، وتتحرك في خطوات صغيرة قابلة للمراجعة، وتثبت أن السلوك لم يتغيّر. وحدة مقيّدة.
- النقلة الكبرى: migration على مستوى الـ repo، والحالات الصعبة مسمّاة الوحدة الخامسة من تعمّقات الهندسة — تُتقن فيها الـ migration الشاملة للـ repo التي ظل الجميع يتحاشاها: تمسح الـ blast radius، وتحوّل الأغلبية الآلية، وتُظهر الحالات المستلزِمة للحُكم، وتسلّم كل قرار لإنسان مع الخيارات والمفاضلات. وحدة مقيّدة.
- حقيبة أدوات أساس الهندسة: قالب CLAUDE.md وقالب ARCHITECTURE.md ومكتبة prompts الهندسة الحقيبة التي تخرج بها من وحدة الهندسة الأولى — قالب CLAUDE.md جاهز للإنتاج، وقالب ARCHITECTURE.md، ومذكرة عرف الـ commit، ومكتبة prompts محفوظة لمهام الخريطة والمراجعة والشحن المتكررة. ثبّتها مرة، وارثها في كل مكان.
- شحن الميزات: spec ثم خطة ثم بناء ثم إثبات ثم commit — بهذا الترتيب الوحدة الثالثة من تعمّقات الهندسة — تُتقن فيها حلقة شحن الميزات كاملة: spec قابل للاختبار، وخطة تنقدها قبل أن يوجد أي كود، وتنفيذ تثبته حزمة خضراء، وdiff تملكه سطرًا سطرًا. وحدة مقيّدة.
- محرّك جودة الكود: مراجعة تصطاد الخطأ الحقيقي، وcommits تشرح اللماذا الوحدة الثانية من تعمّقات الهندسة — تُتقن فيها الحركتين اللتين تُبقيان الـ codebase مقروءًا وقابلًا للمراجعة: الجولة الأولى بعين الخصم التي تتحقق من كل نتيجة على الكود الفعلي، وانضباط الـ commit الذي يجعل git blame جديرًا بالقراءة. وحدة مقيّدة.
القواعد غير القابلة للتفاوض قبل أن يُنشَر أيٌّ من هذا. اقرأ الدليل التشغيلي للاطّلاع على playbook كامل حول البيانات والعلامة التجارية والجوانب القانونية والتعميم.
- أنت المؤلّف المسؤول. اقرأ كل diff قبل أن توافق عليه — عامِل مخرجات Claude كأنها PR من junior سريع ومتحمّس: صحيح عادةً، ومخطئ بثقة أحيانًا، ولا يُدمَج أبدًا دون قراءة. الإنسان الأقدم هو من يملك الـ merge.
- اجعله يثبت الإصلاح. التغيير دون test فاشل حوّله إلى أخضر هو مجرّد تخمين، مهما بدا الشرح واثقًا — اطلب test يفشل على السلوك القديم وينجح على الجديد. الثقة في الكلام ليست دليلًا.
- خطِّط قبل الـ diff في أي شيء غير تافه. احصل على النهج نصًّا (أو استخدم plan mode) واقرأه قبل أن يكتب سطرًا — تصحيح نهج خاطئ في فقرة أرخص بكثير من تصحيحه في تغيير من 300 سطر. وأعطه الأثر الحقيقي أيضًا — الـ stack trace كاملًا، والمخرجات الفاشلة — لا إعادة صياغتك.
- أبقِ الكود المملوك والأسرار حيث ينبغي. افتح Claude داخل الـ repo كي يقرأ ملفاتك الحقيقية، لكن أبقِ بيانات الاعتماد، وبيانات العملاء، وأي شيء تحت NDA خارج الـ context — على Desktop المجلّد المفتوح هو الحد، وأنت توافق على كل قراءة في نافذة «Ask permissions».
- دعه يشغّل loop عملك الحقيقي، ثم ثِق بالأحمر. اربط الـ test suite، والـ type-checker، والـ linter كي يرى الـ agent إخفاقاته ويصحّح نفسه — الـ agent الذي يرى الأحمر يساوي عشرة لا يستطيعون إلا التفكير في الكود. واستعِن بـ subagent للقراءات الواسعة كي لا يزاحم التنقيب العميق الـ context الذي تعمل فيه.
- *اعمل commit في كتل صغيرة منطقية تشرح لماذا.* اطلب منه أن يعمل stage ويصوغ الرسالة؛ فتُبقي
git blameصادقًا وتاريخك قابلًا للمراجعة. للفِرَق ثنائية اللغة: يبقى الكود بالإنجليزية، لكن وثائق التصميم، وملفات ADR، وأوصاف الـ PR تستحق أن تُكتب باللغة التي يقرؤها المراجِع.
أسئلة يطرحها الناس
- هل يكتب Claude code دون أن أراجعه؟
- لا — أنت تقرأ كل diff قبل أن توافق عليه، لأنك ما زلت المؤلّف المسؤول. عامِل مخرجاته كأنها PR من junior سريع ومتحمّس: صحيح عادةً، ومخطئ بثقة أحيانًا، ومراجَع دائمًا.
- كيف أعرف أن الإصلاح حقيقي وليس تخمينًا؟
- اجعله يثبت الإصلاح — اطلب test يفشل على السلوك القديم وينجح على الجديد. التغيير دون test فاشل حوّله إلى أخضر هو مجرّد تخمين، مهما بدا الشرح واثقًا.
- هل من الآمن توجيه Claude إلى الـ repo الخاص بنا؟
- افتح Claude Code في المجلد الجذر للمشروع كي يقرأ ملفاتك الفعلية، وأبقِ الكود المملوك في بيئة تعتمدها شركتك. ومراجعة الـ diff قبل أن يهبط أي شيء هي حدّك، لا حدّ الأداة.
- ما المهمة الأولى الواقعية؟
- رسم خريطة codebase غير مألوف: اطلب من Claude أن يقرأ الـ repo ويشرح كيف يتدفّق request من الـ route إلى الـ database، مسمّيًا ملفات حقيقية. إنها أسرع طريقة للاندماج في كود لم تكتبه — وطريقة آمنة للقراءة فقط ترى فيها الـ agent يعمل.