مطوّر CRM بإطار Django يبني خط إنتاج من خمسة أدوار للذكاء الاصطناعي يقود المهمة بنفسه حتى لقطة الشاشة

مشهد مألوف: تشغّل Claude أو Codex، وترسل موجّهاً (prompt)، فتتلقى «تم». تفتح الكود فتجد النماذج نفسها، وكل ما تغيّر هو أسماء المتغيرات. مؤلف المقال المنشور على Habr قادم من تطوير قواعد البيانات، وفي خريف 2025 شرع في بناء نظام CRM لتأجير السيارات ولنوادي الطيران. مرّ بهذه التجربة أربع مرات متتالية، وانتهى ببناء خط إنتاج يقود المهمة بنفسه ويأتي بالأدلة.

لماذا لا يكفي موجّه واحد

كان يبني على Django موارد مشتركة للسيارات والمدرّبين والمواقع. النماذج متشابهة، وكان يريد إعادة استخدام الكود. أبلغ Codex بأن إعادة الهيكلة أُنجزت، لكن المراجعة أظهرت أن شيئاً يُذكر لم يتغيّر. ثلاث جولات أخرى في محادثات مختلفة أعطت النتيجة نفسها. أبرز شكوى للمؤلف: لم يكن يفهم ما فعله النموذج فعلاً إلا في النهاية. كان عليه نقل المعرفة بين المحادثات يدوياً، وضغط السياق كان يُضيّع التفاصيل.

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

خمسة أدوار وملف واحد

نمت الأدوار من مجموعة أغلفة (wrappers) لسطر الأوامر لكل من Codex CLI وClaude Code وGLM. كانت في البداية أربعة:

• المعماري يضع الحل عالي المستوى (نماذج GPT في Codex)؛
• المخطِّط يحدد مجموعة الملفات ويضع مسودة للكود؛
• المبرمج يكتب التغييرات؛
• المراجع يفحص النتيجة. أُسند هذا الدور إلى GLM، ومن أسباب ذلك الالتزام بحدود الاشتراكات.

عندما استنزف العمل المتوازي في خمس شجرات عمل git (worktrees) انتباه المؤلف، ظهر المدير. وهو دور شبه آلي يمرّر الدور إلى التالي. جعله المؤلف وكيلاً لا سكريبتاً لأنه أراد أن يسأله «ما حالتنا الآن». وفي الوقت الحالي هناك مراجعان، بحسب مجالات المسؤولية.

يربط الجميع عنصر تنسيق واحد هو ملف الخطة. يتولى المعماري إدارته، ويضيف الآخرون أقسامهم، أما المدير فيقرأ فقط ويمرّر العمل. في الترويسة تُدوَّن الحالة ومن يحق له تعيينها: Ready for Planner وReady for Coder وReady for Review وDone. هذه الفكرة نفسها في أطر SDD مثل Spec Kit وOpenSpec وBMAD وKiro. تعيش المهمة في الملف وتصمد أمام ضغط السياق.

وهناك تفصيل طريف: لم تكن الأدوار تحب إعادة قراءة الخطة، وتعتمد على «الذاكرة». أعلن المعماري مرة أن الدور الآن على المخطِّط، مع أن الأخير كان قد أنهى عمله. العلاج بسيط: الحالة يقدّمها مساعد برمجي (helper)، والدور يسأله ولا يختلق شيئاً.

كيف يبدو ذلك في مهمة حقيقية

المهمة من CRM نوادي الطيران: حجز طائرة ومدرّب ومتدرّب حسب الوقت. لاحظ المخطِّط أنه لا يوجد في نموذج البيانات مكان للحقل «درس من قسم مركز التدريب (АУЦ)»، فوجّه سؤالاً إلى المعماري بوسم «عائق». حدّد المعماري أين تُربط الحقول، وبدأ المبرمج العمل دون أسئلة.

أعاد المراجع النموذج إلى المبرمج مرتين. في المرة الثانية ثبّت الاختبار الخطأ نفسه وكان ينجح، ولذلك فالاختبارات الخضراء وحدها لا تكفي. وفي المرة الثالثة شغّل المراجع الفحوص (119 و67 اختباراً، وفحص الترحيلات، وdoc-lint)، والتقط لقطات شاشة وفق السيناريو الوارد في الخطة، وطابق كل واحدة منها مع الخطة. فتح المعماري ست لقطات شاشة ولم يقبل المهمة من المرة الأولى: ثلاثة ملفات في الـcommit لم تكن ضمن المجموعة المعلنة. وبعد التصحيح قبلها. يقدّم الإنسان المهمة عند المدخل، ويتحقق من اتساق الخطة والمراجعة والاختبارات ولقطات الشاشة.

كما أن خط الإنتاج يحسّن نفسه. بعد كل خطة تنفّذ الأدوار docs closeout: تقترح ما ينبغي استكماله وكيف يمكن تحسين العملية. تتراكم الاقتراحات في سجلات، ويقرر الفرز (triage) ما يُعتمد. ويستمد المؤلف أفكاراً من الخارج أيضاً. فمفهوما golden paths، أي وصفات قصيرة من نوع «لنموذج اعتيادي افتح هذه الوثائق الـ3–5»، وdoc gardening، جاءا من مقال OpenAI عن harness engineering. وجرّبوا بحث QMD في ملفات markdown ثم تخلّوا عنه: كفى البحث النصي الكامل على SQLite. ويحمي من الدوران في حلقة مفرغة حدّ للتكرارات: بعد 12 تكراراً على خطة واحدة يوقف المدير العمل.

القيود وما يمكن أخذه لمشروعك

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

ما يستحق أخذه إلى مشروعك:

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

الدرس الرئيسي: الموجّه مناسب لحل لمرة واحدة. أما حين يحتاج المشروع إلى التطوير والصيانة، فتلزمك عملية يمكن فيها التحقق من النتيجة بالعين.