تاريخ النشر:

من تجربة عادية إلى نتائج استثنائية كيف يمكن لـ Claude Code أن يكتب برمجيات متكاملة بدون تدخل بشري؟

كتب بواسطة:
  • اسم الكاتب
    تويتر الكاتب

بسم الله والحمد لله والصلاة والسلام على سيدنا محمد رسول الله وبعد،

منذ فترة ليست بالقصيرة وأنا أعتمد بشكل كبير على الذكاء الاصطناعي في مشاريعي الخاصة ومهامي اليومية، وبالأخص أداة Claude Code مع نموذج Opus 4.5.

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

ولكن، عندما أناقش هذا الأمر مع الأصدقاء والزملاء، أتفاجأ بأنهم لا يحصلون على نفس النتائج المرضية، ودائماً ما يطرحون عليّ السؤال ذاته: "كيف تحصل على هذه النتائج؟ وما الذي تفعله بشكل مختلف عنا؟"

لذا، قررت أن أكتب هذه التدوينة لأشارككم "سر الخلطة" وتجربتي الكاملة.

لماذا أصر على استخدام Opus 4.5؟

قد يتساءل البعض: لماذا Opus وهو أبطأ؟ أنا أستخدم Claude 4.5 Opus (مع ميزة التفكير "Thinking") لكل شيء تقريباً. نعم، هو أبطأ من نموذج Sonnet بسبب حجمه الكبير وقدراته التحليلية، لكنه في النهاية يعطيك نتيجة أفضل بكثير.

المعادلة بسيطة: الوقت الذي ستخسره في انتظار استجابة Opus، ستوفره أضعافاً مضاعفة لأنك لن تضطر لقضاء ساعات في تصحيح الكود أو إعادة التوجيه. Opus 4.5 يحتاج إلى توجيه أقل، وفهمه للسياق واستخدامه للأدوات (Tools) يتفوق بمراحل.

الأساس: إعداد بيئة العمل

السر لا يكمن فقط في هندسة الأوامر الـ "Prompt"، بل في البيئة المحيطة. إعداداتي بسيطة، لكنها تنقل النتيجة من "رائعة" إلى "خارقة".

1. تنظيم التبويبات (Terminal Tabs)

أول خطوة هي النظام. أقوم بترتيب التبويبات حسب كل ميزة (Feature) أو مشروع أعمل عليه. هذا الفصل يساعدني على التركيز التام ويمنع تشتت السياق (Context) بين المهام المختلفة.

2. العمل غير المتزامن (إشعارات النظام)

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

3. الصلاحيات الآمنة (Permissions)

نصيحة هامة: ابتعد تماماً عن استخدام --dangerously-skip-permissions. بدلاً من ذلك، أستخدم الأمر /permissions وأقوم بتفعيل أوامر Bash التي أنا متأكد منها ومناسبة لبيئتي. أغلب هذه الصلاحيات أحفظها داخل ملف .claude/settings.json.

المنهجية التي أتبعها: كلما طلب Claude إذناً لأمر جديد، أتأكد منه، وإذا كان آمناً ومكرراً، أطلب منه إضافته للملف ليكون تلقائياً في المرات القادمة.

ملف CLAUDE.md: ذاكرة المشروع الحية

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

مثال حي من ملفي:

# Project Guidelines

## Code Style
- Always use TypeScript strict mode
- Prefer functional components over class components
- Use named exports, not default exports

## Common Mistakes to Avoid
- Don't use inline styles, always use Tailwind
- Don't create new utility functions if similar ones exist in /utils
- Always handle loading and error states

ملاحظة جانبية: أعمل حالياً على تجهيز طريقة (Workflow) باستخدام GitHub Actions، بحيث عندما أقوم بمراجعة كود لزميل (Code Review)، أستطيع عمل "Tag" لـ Claude ليقوم هو بإضافة الملاحظة إلى CLAUDE.md تلقائياً. سأشاركها معكم فور انتهائها.

المهارات والإضافات المتخصصة (Skills, Plugins & MCP)

بدلاً من الاعتماد على Claude كـ "عامل عام"، أقوم بتزويده بأدوات (Plugins) ومهارات (Skills) وربطه بتطبيقات خارجية (MCP) تحوله إلى متخصص في كل مرحلة من مراحل العمل. لا أعتمد هنا على أدوات عشوائية، بل على مجموعة محددة أثبتت فعاليتها في الإنتاجية:

1. إدارة الميزات: أعتمد بشكل أساسي على feature-dev كـ Plugin. هو المحرك الذي لا يكتب الكود فحسب، بل يقوم بتشغيل العملاء ("Agents") اللازمة لأخذ الميزة المطلوبة وبنائها بشكل منظم.

2. الربط مع الأدوات الخارجية (MCP): أعطيت Claude "عيوناً" ليرى سياق المشروع بوضوح من خلال بروتوكول MCP. على سبيل المثال:

  • Figma: للوصول المباشر للتصاميم ومراعاتها أثناء التكويد.
  • shadcn: لفهم واستخدام المكونات الجاهزة في المشروع.
  • أدوات خاصة: أي أدوات داخلية يحتاج المشروع للربط معها.

3. مهارة التصميم: لأنني أهتم بجودة الواجهات، أضيف مهارة frontend-design لبيئة العمل. هذا يعطي Claude "عيناً تصميمية" وفهماً لأفضل ممارسات الواجهة الأمامية، فلا يخرج الكود "وظيفياً" فقط، بل "جميلاً" ومتناسقاً أيضاً.

4. ترسانة المراجعة: هنا تكمن القوة الحقيقية لضمان الجودة. لا أقبل الكود مباشرة، بل أمرره عبر "فلاتر" متخصصة تعتمد على Agents للمراجعة:

  • للمراجعة الأمنية: أستخدم الأمر /security-review لإجراء مسح شامل للتغييرات المعلقة (Pending Changes) والتأكد من خلوها من الثغرات.
  • لمراجعة الـ PR: أستخدم /pr-review-toolkit:review-pr لإجراء مراجعة شاملة ومعمقة للـ Pull Request باستخدام عملاء متخصصين.
  • للمراجعة السريعة: أحياناً أستخدم /code-review:code-review للمراجعات الخفيفة.

5. الإرسال: في النهاية، ولإتمام العملية، أعتمد على commit-commands لإدارة عمليات الـ Git (Commit, Push, PR) بشكل مؤتمت وسريع.

ملاحظة: يمكنكم استكشاف وتثبيت كافة الإضافات والمهارات المذكورة من خلال المستودع الرسمي: Claude Code Plugins.

استراتيجية العمل: كيف أحصل على "الكود المثالي"؟

هنا يكمن الفرق الحقيقي. للحصول على كود بجودة استثنائية، يجب أن توفر سياقاً تعليمياً وليس مجرد أوامر.

السر: التعلم من الأمثلة

جودة الكود الذي يكتبه Claude تتضاعف مرتين أو ثلاثاً إذا وفرت له "مصدر إلهام". قبل أن يبدأ بالكتابة، أجعله يرى كيف تم تنفيذ ميزة مشابهة في مشروع مفتوح المصدر (Open Source) موثوق وعالي الجودة.

خطواتي عند بناء ميزة جديدة:

  1. التحليل وتوفير السياق: أعطيه معلومات التصميم (عبر Figma/MCP) ووصفاً دقيقاً للمهمة.
  2. مراجعة التوثيق (Documentation): أطلب منه مراجعة توثيق المكتبات المستخدمة ليفهم التفاصيل التقنية الدقيقة والـ APIs.
  3. التعلم (The Learning Phase): أعطيه وصولاً لكود مصدري (Reference) لميزة مشابهة. الهدف هنا أن يتعلم "النمط" (Pattern)، طريقة التنظيم، وكيفية التعامل مع الحالات المختلفة.
  4. التخطيط (Plan Mode): قبل كتابة أي سطر كود، نبدأ بوضع التخطيط (Shift+Tab مرتين). نتناقش في الخطة حتى أوافق عليها.
  5. التنفيذ: أطلب منه البدء بالتنفيذ بناءً على ما تعلمه، ولكن بما يناسب خصوصية مشروعي.
  6. المراجعة: غالباً ما تكون النتيجة مذهلة، وأتدخل فقط للمسات النهائية.
  7. الاختبار: أطلب منه كتابة اختبارات شاملة (Unit, Integration, E2E) لضمان الجودة.

ما أعمل عليه حالياً:

طموحي الحالي هو تحويل Claude إلى "شريك مؤسس" (Co-founder) حقيقي؛ ذلك الشريك التقني الذي يمكنني الاعتماد عليه لبناء مشاريع نهاية الأسبوع من الألف إلى الياء دون الغرق في التفاصيل، ويكون دوري مقتصرًا على مراجعة النتيجة النهائية فقط.

البيئة التي أعمل على تجهيزها حالياً تعتمد على سير عمل محدد: أقوم أولاً بكتابة وصف دقيق للميزة مع إرفاق المصادر اللازمة (توثيق، شرح، أمثلة)، ثم أقوم بإنشاء المهمة عبر منصة خارجية (مثل GitHub Issues أو Jira أو حتى Slack - لم أعتمد المنصة النهائية بعد)، وأقوم بعمل Tag لـ Claude أو استدعائه عبر MCP ليبدأ العمل.

بمجرد استلامه للمهمة، يقوم بتوزيعها على "فريق" من العملاء المتخصصين:

  1. مدير المنتج (Product Manager): لا يكتفي بالتنفيذ، بل يناقشني! في حال كانت الميزة جديدة، يقوم هذا العميل بالتفكير وتحليل المتطلبات بما يناسب المشروع، ويساعدني على فهم السوق ووضع الخطة المناسبة قبل كتابة سطر كود واحد.

  2. المهندس المعماري (Code Architect): مهمته تحليل الطلبات تقنياً ومراجعة خطة مدير المنتج. والأهم من ذلك، أنه يقوم بتقديم الاقتراح الأمثل للتنفيذ، ويقوم بتقسيم العمل (في حال كان كبيراً) إلى مراحل صغيرة أو أقسام (Chunks) سهلة المراجعة والاختبار، بدلاً من العمل ككتلة واحدة.

  3. مهندس برمجيات أول (Senior Software Engineer): يستلم الخطة المقسمة وينفذها، ملتزماً بقواعد صارمة قمت بتعريفها مسبقاً في ملف AGENTS.md. ميزته الأساسية أنه يشرح لي ما يتم إنجازه في كل مرحلة خطوة بخطوة.

في النهاية، يقتصر دوري على مراجعة النتيجة النهائية، والموافقة عليها، أو طلب تعديلات بسيطة.

ملاحظة: هذه الفكرة لا تزال قيد التجريب وبناء الـ Setup المناسب. بمجرد أن أصل لنتيجة متكاملة وناضجة، سأكتب مقالة مفصلة أشرح فيها كيف قمت بناء هذه البيئة بالتفصيل.

روابط مفيدة:

وأنت، ماذا تعتقد؟ هل تستخدم طريقة مختلفة؟ أو لديك حل أفضل من أجل التعامل مع حالات مشابهة؟ تواصل معي على X وأخبرني عن تجربتك ورأيك!