وصف على Habr لإطار عمل ذكاء اصطناعي لـ Claude يقوم على Clean Architecture ودورة TDD

نُشر على Habr تحليل مفصّل لإطار عمل ذكاء اصطناعي يُلزم نموذج LLM بكتابة الكود وفق عملية هندسية صارمة، لا بأسلوب «vibe coding» الحر. ويؤكد المؤلف أنه يمرّر عبر هذا النهج معظم أعمال التطوير التي يقوم بها، وأنه يعتمد على Clean Architecture وTDD ومراجعة بشرية إلزامية.

كيف يعمل سير العمل

تقوم فكرة النهج على مبدأ بسيط: البرمجيات الجيدة ليست مجموعة ملفات، بل مجموعة سيناريوهات سلوك مؤكَّدة. لذلك لا يبدأ العمل بتوليد الكود، بل بتقسيم المنتج إلى قصص مستقلة، تقدّم كل منها قيمة مستقلة للمستخدم.

لكل قصة، يمرّ Claude أولاً بمرحلة المواصفات: يجمع المقابلات، ويصوغ الوصف ومعايير القبول، ويصمّم الـ API، ويُعدّ النماذج الأولية، وبعد ذلك فقط يضع قائمة حالات الاختبار. ثم تبدأ مرحلة التنفيذ.

يقول المؤلف إنه اختبر هذه العملية عملياً على مدى 3,5 أشهر: فقد مرّ عبرها نحو 4 آلاف commit، و1500 اختبار، وقرابة 350 فحص e2e، ونحو 25 ألف سطر من كود الإنتاج، دون احتساب طبقة الاختبارات.

العنصر المحوري في المخطط هو الأمر /continue. فهو يطّلع على قائمة القصص وعلى الملف progress.md، ويحدّد الخطوة التي توقف عندها التطوير، ويدفع المهمة إلى الأمام دون الحاجة إلى اختيار الإجراء التالي يدوياً.

TDD والبوابات

لا يكتفي الإطار بطلب «اكتب الميزة» من النموذج، بل يقوده حرفياً عبر دورة ATDD وخطوات TDD المتداخلة. ففي الـ backend يبدأ الأمر باختبار قبول أحمر، ثم ينزل Claude إلى مستوى أدنى، أي إلى use case والـ adapters، ثم «يُخضِّر» كل مستوى تدريجياً. والمنطق نفسه ينطبق على بقية أجزاء المنتج: يُثبَّت السلوك القابل للتحقق أولاً، ثم يُكتب الكود، وليس العكس. وبهذا يحاول المؤلف ربط عمل النموذج بالعمارة البرمجية، لا بالحظ العشوائي.

• مقابلات وصياغة رسمية للمتطلبات لكل قصة
• توليد خطة الاختبار وحالاته قبل بدء التنفيذ
• دورة red-green-refactor للـ use case والـ adapters واختبارات القبول
• quality gates تفحص صرامة الاختبارات والعمارة والتغطية
• commit بعد كل خطوة ووقفة إلزامية للمراجعة البشرية

«لن تذهب بعيداً بالـ prompts المجرّدة».

فوق TDD أضاف المؤلف quality gates كشبكة أمان. ففي الخطوة الحمراء يتحقق النموذج بشكل منفصل من مدى صرامة الاختبارات ومن أنها لا تُخلّ بعمارة الاختبارات؛ وفي الخطوة الخضراء يعيد هيكلة الكود ويطابق التغطية. ولكل بوابة قائمة تحقق (checklist) يجب على الـ LLM أن تمرّ عليها صراحةً.

ويُولى تركيز خاص لإدارة السياق: إذ يُشغَّل كل خطوة فرعية في وكيل (agent) منفصل، ويتيح progress.md إعادة تعيين السياق بعد كل commit وتحميل الحد الأدنى فقط من البيانات للمرحلة التالية.

نوافذ IDE المتوازية

الجانب العملي في هذا النهج لا يقل أهمية عن العمارة نفسها. فقد يستغرق تشغيل /continue الواحد من 5 إلى 20 دقيقة، وعلى الاختبارات الثقيلة حتى 40 دقيقة أو حتى ساعة. ولتجنّب انتظار مسار واحد، ينصح المؤلف باستنساخ مستودع العرض التوضيحي عدة مرات أو استخدام worktrees وتشغيل قصص مختلفة بالتوازي في نوافذ IDE منفصلة. وفي عمله هو يفتح حتى ست نوافذ في آن واحد، أربع أو خمس منها مشغولة بعمل الوكيل، وفي الباقي تجري المراجعة وإعادة الهيكلة ومعالجة الديون التقنية.

وللحالات غير المعتادة توجد إلى جانب المسار الرئيسي أوامر إضافية. وللبدء نشر المؤلف مستودعين: demo لـ Kanban بلغة Java + React، وهيكل فارغ للإطار. الأمر /task مخصّص لإصلاح الأخطاء والبنية التحتية والمهام الطويلة التي لا تتسع لها قصة بطقس TDD الكامل. أما /prompt-update فهو لتطوير الإطار نفسه، إذا عادت المشكلة المتكررة ذاتها لتُربك النموذج.

ويعترف المؤلف صراحةً بالقيود: فقد نشأ الحل من حزمة ويب محددة، وهو مصمَّم لـ Clean Architecture وATDD، ويستهلك كثيراً من الـ tokens، ولا يجعل التطوير مستقلاً بالكامل. وإذا لم يُكتشف خطأ ما أثناء المراجعة، فسيصل بهدوء إلى بيئة الإنتاج.

ماذا يعني ذلك

يُظهر هذا النهج الاتجاه الذي يتحرك نحوه التطوير الناضج بالذكاء الاصطناعي: من الـ prompts المنفردة إلى خطوط عمل (pipelines) قابلة للتكرار، يعمل فيها النموذج داخل العملية لا بديلاً عنها. والخلاصة الرئيسية هنا حاسمة إلى حد ما: يمكن لـ LLM أن تُسرّع بالفعل تطوير كود الإنتاج، ولكن فقط إذا بقيت ضمن إطار من الاختبارات وقوائم التحقق والخطوات القصيرة والرقابة البشرية المستمرة.