لا يدخل وكيل البرمجة (coding agent) إلى مستودعك وهو يحمل آراءً قوية. إنه يقرأ ما هو موجود بالفعل، ويمتص المنطق، ويكرر الأنماط التي يجدها. إذا كانت طبقة الوصول إلى البيانات (data access layer) عبارة عن تشابك من SQL الخام والاستعلامات المكررة، فسيقوم الوكيل بكل سرور بإضافة عقدة أخرى. إذا كانت تغطية الاختبارات (test coverage) ضعيفة، فسيقوم بإنشاء اختبارات ضعيفة. هذا ليس كسلاً أو عدم كفاءة، بل هو مطابقة الأنماط (pattern matching) تعمل تماماً كما هو مخطط لها.

إن سد الفجوة بين ما تتخيله وما يبنيه الوكيل يتطلب سياقاً وقيوداً، وليس مجرد مطالبات (prompts) أعلى صوتاً أو تمنيات بنموذج أكثر ذكاءً. أنت تقوم بمواءمة الأداة من خلال هندسة البيئة التي تعمل فيها. إليك ست طرق عملية للقيام بذلك.

إعادة الهيكلة من أجل المحاكاة

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

بدلاً من ذلك، أعطه مرجعاً نظيفاً واحداً. اختر وحدة تمثل هيكلك المثالي. جردها من الضوضاء غير الضرورية بحيث يصبح التصميم المعماري (architecture) واضحاً. عندما تطلب ميزة جديدة، أشر إلى ذلك الملف مباشرة: "اتبع النمط الموجود في /src/orders/repository.py". مثال واحد جيد الصياغة يوصل أكثر مما يوصله فقرة من القواعد المجردة لأن الكود لا يترك مجالاً للتفسير. إذا كان مستودعك يفتقر إلى مثال نظيف واحد، فقم بكتابة واحد. إن التنفيذ المرجعي الموجز هو استثمار لمرة واحدة يؤتي ثماره في كل طلب لاحق. سيقوم الوكيل باستنساخ الهيكل، وأسلوب معالجة الأخطاء، وفصل الاهتمامات (separation of concerns) لأن هذا هو المخطط الوحيد الذي جعلته مرئياً.

استخدم وضع التخطيط (Plan Mode) أولاً

قبل إنشاء أي ملف أو تعديله، اطلب من Claude اقتراح خطة. اجعلها ملموسة: ما هي الملفات التي ستتغير، وما هي الوظائف (functions) التي ستتم إضافتها، وما هي التبعيات (dependencies) التي سيتم استيرادها، وكيف تتناسب القطع الجديدة مع الرسم البياني (graph) الحالي.

تعمل هذه الخطوة ككاشف مجاني للتناقضات. إذا اقترحت خطة Claude إضافة ترحيل لقاعدة البيانات (database migration) داخل خط أنابيب نشر التطبيق (application deployment pipeline)، بينما يقوم فريقك بتشغيل عمليات الترحيل من خلال وظيفة منسقة منفصلة، فستكتشف عدم التطابق في ثوانٍ بدلاً من اكتشافه أثناء مراجعة الكود. إذا خطط لإعادة استخدام أداة مساعدة مهجورة (deprecated utility)، يمكنك توجيهه قبل كتابة نصف الميزة. تجبر الخطة النموذج على إظهار افتراضاته حول بنيتك المعمارية. اعترض عليها بنفس الطريقة التي قد تتحدى بها وثيقة تصميم مطور مبتدئ. هذا يكلف بضع دقائق ويوفر بانتظام ساعة من فك الكود السيئ.

قدم سياقاً كاملاً في وقت مبكر

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

حدد حدودك في المطالبة الأولى. إذا كان يجب أن تظل نقطة النهاية (endpoint) الخاصة بك أقل من 200 مللي ثانية عند المئين التاسع والتسعين (99th percentile)، فقل ذلك. إذا كنت تعمل بموجب HIPAA أو GDPR أو نظام تدقيق داخلي محدد، فاجعل ذلك صريحاً. إذا كانت فاتورة البنية التحتية لديك حساسة ولا يمكنك تشغيل عنقود ذاكرة تخزين مؤقت مدار (managed cache cluster) إضافي، فوضح سقف التكلفة. لا يمكن لـ Claude Code التفاوض على المقايضات التي لا يعرف بوجودها. كلما حقنت هذه الحدود في وقت مبكر، زاد احتمال قيام الوكيل بدمجها في أساس حله بدلاً من معاملتها كأفكار لاحقة يتم إصلاحها لاحقاً.

ترميز الذاكرة

تكرار نفس التصحيح هو إضاعة لوقتك ولنافذة السياق (context window). عندما تجد نفسك تخبر Claude بتجنب مكتبة معينة، أو استخدام غلاف (wrapper) محدد، أو اتباع اتفاقية تسمية معينة أكثر من مرة، توقف. حول هذا التصحيح إلى ذاكرة للمشروع.

أنشئ ملف CLAUDE.md في جذر مستودعك. هذا هو دليل منزلك. املأه بالقواعد التي تهمك: استخدم pytest بدلاً من unittest؛ يجب أن تمر جميع مكالمات HTTP الصادرة عبر قاطع الدائرة (circuit-breaker) في /lib/http؛ لا تستورد أبداً مباشرة من ملف utils.py القديم؛ قم دائماً بالتحقق من المدخلات باستخدام طبقة المخطط (schema layer) قبل وصولها إلى المعالج (handler). عندما يقوم Claude Code بتحميل مشروعك، فإنه يقرأ هذا الملف تلقائياً. بمرور الوقت، يصبح CLAUDE.md أحد أكثر أصولك فعالية لأنه يوسع معاييرك دون مطالبتك بإعادة كتابتها في كل جلسة. التصحيحات التي كانت ذات يوم مطالبات عابرة تصبح عناصر دائمة في قاعدة الكود.

ميكنة القواعد باستخدام الخطافات (Hooks)

تساعد التوثيقات، ولكن يمكن إغفالها. عندما تكون القاعدة بالغة الأهمية، انقلها من مجرد نصيحة إلى فرض إلزامي. استخدم الـ hooks، أو فحوصات ما قبل الالتزام (pre-commit checks)، أو بوابات التكامل المستمر (CI gates)، أو سكربتات التحقق المخصصة لجعل القواعد الصارمة غير قابلة للكسر.

إذا كان يجب أن يحتوي كل موديول (module) جديد على اختبارات وحدة (unit tests) مقابلة، فلا تكتفِ بذكر ذلك في CLAUDE.md. قم بتكوين بوابة تغطية (coverage gate) تفشل عملية البناء (build) عندما يتم إضافة ملف في /src دون اختبار مطابق. إذا كانت سياسة الأمان لديك تمنع إرسال الأسرار (secrets)، فقم بتشغيل ماسح ضوئي (scanner) يمنع عملية الـ push. إذا كان فريقك يتطلب ترتيباً معيناً للاستيرادات (imports) أو قواعد lint محددة، فقم بأتمتة الإصلاح باستخدام pre-commit hook. هذه الآليات تكتشف مخرجات Claude بنفس الطريقة التي تكتشف بها أخطاءك. فهي تزيل احتمالية السهو البشري أو انحراف النموذج (model drift) وتستبدل عبارة "يرجى التذكر" بعبارة "لا يمكن المتابعة". فالقاعدة التي لا يتم فرضها ليست سوى مجرد اقتراح.

تشغيل مراجعين مستقلين

المراجعة الذاتية غير موثوقة. فعندما يراجع Claude عمله الخاص، فإنه غالباً ما يؤكد افتراضاته الخاصة لأنه هو من قام بإنشائها في المقام الأول. الحل هو الاستعانة بـ "أعين جديدة"، حتى لو كانت تلك الأعين تنتمي إلى نفس النموذج ولكن تحت مهام (charter) مختلفة.

قم بتشغيل وكلاء مراجعة (reviewer agents) منفصلين بتركيز ضيق ومحدد. اطلب من أحدهم التدقيق الصارم من الناحية الأمنية: هل هناك مخاطر حقن (injection risks)، أو نقاط نهاية داخلية مكشوفة (exposed internal endpoints)، أو عمليات إلغاء تسلسل غير آمنة (unsafe deserializations)؟ واطلب من آخر تقييم تغطية الاختبار وحالات الحافة (edge cases). وقد يقوم ثالث بالتحقق من أن التغيير يحترم القواعد المحددة في CLAUDE.md. لا يحتاج هؤلاء المراجعون إلى نماذج مخصصة معقدة؛ بل يحتاجون ببساطة إلى الاستقلالية عن خطوة التوليد الأصلية. إن "الاحتكاك" الناتج عن طلب شخص آخر — أو شيء آخر — للنظر في الكود يكشف الافتراضات التي بدت بديهية للمبرمج. وتكلفة الـ tokens الإضافية ضئيلة جداً مقارنة بثمن وصول خطأ برمجي (bug) إلى مرحلة الإنتاج (production).

الحلقة

المواءمة (Alignment) ليست مشروعاً تنهيه، بل هي حلقة تحافظ عليها. في كل مرة تصحح فيها مخرجات Claude، اسأل نفسك عما إذا كان هذا التصحيح يمكن أن يصبح مدخلاً جديداً في CLAUDE.md أو بوابة جديدة في أدواتك. إذا قمت بنفس الإصلاح مرتين، فقد وجدت ثغرة في نظامك؛ فقم بسدها بشكل دائم.

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

Source: https://dev.to/az365ai/how-to-align-claude-code-with-your-codebase-6-techniques-2026-3k28

Optional learning community: https://t.me/GyaanSetuAi