كيف يهيّئ مطوّر في YADRO أداة Claude Code وفق منهجية Spec-Driven Development

يعمل المبرمج والمهندس المعماري في YADRO دانييل بودولسكي منذ تسعة أشهر وفق منهجية Spec-Driven Development، ويدير وكلاء ذكاء اصطناعي يكتبون الشيفرة بدلًا منه. ولا يصف نفسه بأنه «فايب كودر»، بل مهندس، ويشرح السبب. هذا هو المقال الأول من سلسلته عن تنظيم بيئة عمل مطوّر SDD، ويتناول الإعداد الأساسي لأداة Claude Code للتبديل السريع بين النماذج دون إعادة تشغيل.

SDD مقابل الفايب كودينغ

الفايب كودينغ هو أن يصف المطوّر المهمة للذكاء الاصطناعي، ثم يطّلع على النتيجة ويكرّر المحاولة «بالإحساس». ويحظى هذا النهج بشعبية لأنه سريع ولا يتطلب تحضيرًا مسبقًا.

أما Spec-Driven Development فيقوم على مبدأ مختلف جذريًا. تُعدّ أولًا مواصفات متكاملة تشمل المتطلبات والبنية المعمارية وسلوك النظام والحالات الحدّية. وبعد ذلك فقط يبدأ وكيل الذكاء الاصطناعي العمل بالاستناد إلى الوثيقة بوصفها مواصفات فنية. يحدد المطوّر البنية ويتخذ القرارات المعمارية، فيما ينفّذ الذكاء الاصطناعي التفاصيل ويكتب الشيفرة.

يؤكد بودولسكي أن نهجه «أشمل من مجرد التحدث مع الذكاء الاصطناعي». فـ SDD يعيد الانضباط الهندسي إلى مجال بدأ يغيب عنه بسبب سرعة أدوات الذكاء الاصطناعي، وهي: المتطلبات، والتصميم، والتنفيذ، والتحقق. لقد تغيّر المنفّذ، لكن العملية نفسها تبقى هندسية. وهذا ما يميّز SDD عن الفايب كودينغ: الفارق ليس في الأداة، بل في المنهجية.

إعداد Claude Code لعدة مشاريع

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

لا يناسب الإعداد العام الافتراضي للنموذج هذه الحالة. فالمشاريع المختلفة لها متطلبات مختلفة: خدمة الإنتاج تحتاج إلى Opus بقدرات استدلال (reasoning) عميقة والتزام صارم بالتعليمات، بينما يكفي النموذج Sonnet أو Haiku تمامًا لنموذج أولي أو مهمة روتينية. وإذا كان كل انتقال بين المشاريع يتطلب إعادة ضبط يدوية وإعادة تشغيل الوكيل، يبدأ المطوّر بتجنّب تغيير النموذج، فيلجأ إلى نموذج «شامل» بدلًا من النموذج الأمثل.

أبرز مبادئ الإعداد:

• ملف `CLAUDE.md` في جذر المشروع: النموذج والسياق معزولان تمامًا على مستوى المستودع
• الأمر `/model` يبدّل النموذج فورًا دون إعادة تشغيل الجلسة الحالية
• ملف `settings.json` على مستوى المشروع يحفظ ملفات تعريف الوكلاء والأذونات ومجموعة الأدوات
• ملفات التجاوز (override) المحلية تفصل بين إعدادات التطوير (dev) والإنتاج (prod)
• متغيرات البيئة تتيح التحكم بالنموذج عبر CI/CD دون تعديل ملفات الإعداد

لماذا تغيّر سرعة التبديل الجودة؟

في منهجية Spec-Driven Development يستخدم المشروع الواحد عدة نماذج بالتتابع في مراحل مختلفة. فصياغة المواصفات تتطلب نموذجًا قويًا ذا استدلال متين وإجابات مفصّلة. أما التنفيذ بناءً على مواصفات جاهزة فيكفيه نموذج سريع يمكن التنبؤ بسلوكه، إذ تقل احتمالية الانحراف عن المهمة. وتتطلب المراجعة النهائية ملفًا مختلفًا من جديد.

إذا استغرق التبديل نصف دقيقة واحتاج إلى إجراءات يدوية، يبدأ المطوّر تدريجيًا بتجنّب تغيير النماذج. وهذا يضر بالسرعة والجودة معًا، خصوصًا في مرحلة كتابة المواصفات التي يكون فيها الاستدلال حاسمًا.

«نهجي في العمل أشمل من مجرد التحدث مع الذكاء الاصطناعي»، — دانييل

بودولسكي، YADRO.

ستتواصل السلسلة. وستتناول المقالات المقبلة تنسيق عدة وكلاء يعملون بالتوازي، وإدارة السياق، وبنية المواصفات نفسها.

ما أهمية ذلك

يتبلور Spec-Driven Development تدريجيًا بوصفه تخصصًا هندسيًا مستقلًا. فبينما يتقن معظم المطوّرين الفايب كودينغ، ينتقل بعضهم إلى منهجيات صارمة: التوثيق، فالمواصفات، فالوكيل، فالتحقق. ويُعدّ شرح إعداد Claude Code الذي قدّمه المهندس المعماري من YADRO من أولى المواد المنهجية الناطقة بالروسية حول هذا الموضوع. وتستحق السلسلة المتابعة حتى لمن لا يزال يتعامل مع أدوات الذكاء الاصطناعي بالحدس.