طرق واقعية لحماية محفظتك عند إصلاح الأنظمة القديمة باستخدام Claude Code

التشغيل المتبادل للنماذج المزدوجة: ذكاء أعلى وتكلفة أقل

أكثر ما يثير الرعب عند البدء في البرمجة المعتمدة على الوكلاء (Agents) ليس الأداء، بل كشف حساب البطاقة الائتمانية للشهر القادم. الوكلاء المزدوجون الذين نراهم في المقاطع المصورة يبدون رائعين، لكن استخدامهم دون تفكير سيؤدي حتماً إلى انفجار في تكاليف واجهة برمجة التطبيقات (API). في عام 2026 الحالي، يبلغ سعر الإدخال لنموذج Claude 4.6 Opus حوالي $5.00 لكل مليون توكن، وهو أغلى بنسبة تزيد عن 60$3.00). أما تكلفة الإخراج فتصل إلى $25.00. في المشاريع القديمة (Legacy) التي تتجاوز 100 ألف توكن، يعني هذا أن كل دورة تنفيذية قد تكلفك ثمن كوب من القهوة.

للتحكم في التكاليف، لا تصر على استخدام Opus بشكل مطلق، بل استخدم طريقة تخصيص الفتحات (Slots). خصص Opus فقط للتصميم واتخاذ قرارات الهندسة المعمارية (Architecture) التي تمثل 20% من العمل الإجمالي، واترك الـ 80% المتبقية من التنفيذ البسيط لنموذج Sonnet.

• الطريقة: قم أولاً بوضع حد أقصى للاستخدام (Usage Limit) لكل مشروع في وحدة تحكم أنثروبيك (Anthropic Console). في إعدادات Claude Code، اجعل Sonnet هو النموذج الافتراضي، وقم بالترقية يدوياً باستخدام علم --model opus فقط في الجلسات التي تتعقد فيها المنطق البرمجي. من الضروري التعود على فتح تقارير API كل صباح إثنين للتأكد من أن الإنفاق الفعلي يسير وفق المنحنى المتوقع.
• النتيجة: ستحصل على جودة الاستدلال عالية المستوى مع توفير ما بين 40% إلى 70% من إجمالي تكاليف API.

رسم خريطة تضاريس قاعدة الكود لمنع هدر التوكنات

في الواقع، يتم هدر 70% من التوكنات التي يستخدمها الوكيل في البحث في ملفات غير ضرورية واستكشاف الأدلة. تظهر نماذج اللغة الكبيرة (LLM) ظاهرة "جرف الأداء"، حيث ينخفض التركيز بشكل حاد عندما يتجاوز السياق 100 ألف توكن. إقحام كل الكود المصدري هو طريق مختصر لإضاعة المال وتدمير الأداء. تظهر نتائج الاختبارات الداخلية لشركة Anthropic أنه عند ضغط السياق المرسل، يتم الحفاظ على جودة الاستدلال مع تقليل تكاليف الإدخال بنسبة تزيد عن 50%.

قم بإنشاء ملف ARCH.md كدليل مخصص للذكاء الاصطناعي لتزويد الوكيل بخريطة طريق.

• الطريقة: أولاً، استخرج الهيكل العظمي للمشروع باستخدام الأمر tree -L 3 -I 'node_modules|dist|.git' > tree.md. بعد ذلك، استخدم أدوات مثل Repomix لإنشاء "خريطة تواقيع" (Signature Map) تستبعد المنطق الفعلي وتُبقي فقط على تواقيع الدوال وتعاريف الواجهات (Interfaces). أخيراً، حدد بوضوح الأصول مثل .svg و .json في ملف .claudeignore لإزالتها من رؤية الوكيل.
• النتيجة: تقليل مراحل الاستكشاف الأولية لتوفير أكثر من 50% من استهلاك توكنات الإدخال لكل جلسة، ورفع سرعة الاستجابة للضعف تقريباً.

أتمتة المراجعة النقدية لتقليل إصلاح الأخطاء بعد النشر

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

قبل أن يلمس نموذج التنفيذ الكود، أنشئ آلية تجعل Opus يقوم بمراجعة نقدية.

• الطريقة: قم بتسجيل موجه (Prompt) باسم 'Critical Review' في مهارات Claude Code المخصصة. حدد بوضوح في هذا الموجه ضرورة التحقق من ثلاثة عناصر: اتساق البيانات (Race Condition)، الثغرات الأمنية، وانخفاض الأداء (N+1 Query). يجب وضع قاعدة تقضي بعدم إصدار أمر التنفيذ إلا بعد الحصول على موافقة تفيد بعدم وجود عيوب خطيرة في هذه المراجعة.
• النتيجة: تتقلص العيوب المنطقية بشكل ملحوظ، مما يؤدي إلى خفض معدل حدوث الأعطال في بيئة التشغيل الفعلية بنسبة تزيد عن 30%.

حل الاختناقات في المهام واسعة النطاق

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

يمكن تنظيم العمليات المتوازية لتسريع العمل كالتالي:

• الطريقة: استخدم أمر git worktree add لإنشاء أدلة مستقلة لكل ميزة. افتح جلسة Claude Code منفصلة في كل مساحة عمل لإعادة هيكلة وحدات (Modules) مختلفة في وقت واحد. في النهاية، استخدم أدوات مثل Clash لمعالجة التضاربات بين مساحات العمل ودمجها في الفرع الرئيسي.
• النتيجة: ستختبر زيادة في الإنتاجية تنهي مهام إعادة الهيكلة التي كانت تستغرق أسابيع في غضون 20 ساعة فقط من العمل المكثف.

التدقيق الأسبوعي للمعمارية لمنع تراكم الديون التقنية للذكاء الاصطناعي

مع تراكم الكود الذي يكتبه الذكاء الاصطناعي، قد يحدث في لحظة ما "دين تقني" حيث ينهار الهيكل العام. الوكيل قد يصلح ملفاً واحداً بشكل مذهل، لكنه لا يتحمل مسؤولية الاتجاه الذي يجب أن يسلكه النظام ككل. المهمة الحقيقية للمهندس الأول في عام 2026 ليست طباعة الكود يدوياً، بل إدارة حالة التراصف والمحاذاة للمخرجات التي ينتجها الوكلاء.

قم بتشغيل روتين "تدقيق المعمارية" كل يوم جمعة قبل مغادرة العمل.

• الطريقة: أدخل جميع الالتزامات (Commits) التي تغيرت خلال الأسبوع إلى Opus واطلب منه العثور على الأماكن التي خالفت الاتفاقيات القائمة (مثل نمط Early Return). استخرج الدوال التي أصبحت معقدة للغاية أو الوحدات التي تفتقر إلى الاختبارات وأنشئ "قائمة ديون". ستكون هذه القائمة هي المهمة الأولى للوكيل في الأسبوع القادم.
• النتيجة: منع تدهور قاعدة الكود والحفاظ على الحالة النظيفة التي كانت عليها عند إدخال الذكاء الاصطناعي لأول مرة على المدى الطويل.