ساعد Claude Code على بناء تطبيق Elixir للإنتاج من دون كتابة كود يدويًا خلال أربعة أشهر

وصف المؤلف تجربة استمرت أربعة أشهر: تم بناء تطبيق Elixir/Phoenix في الإنتاج من خلال Claude Code بدون كتابة يدوية للكود. خلال هذه الفترة، وصل المشروع إلى 1,702 التزام و 3,880 اختبار وتغطية 94.83٪، لكنه واجه حادثتين خطيرتين في الإنتاج على طول الطريق.

نطاق المشروع

لم تكن هذه تجربة توضيحية أو مشروع شخصي، بل كانت خدمة EasyStocksAI لتقييم أكثر من 1,000 سهم عبر 15 متوسط. يحسب التطبيق النقاط عبر أربع كتل ويدير المحافظ مع سجل المعاملات ويقارن النتائج مع استراتيجيات المعايير ويعرض الرسوم البيانية التفاعلية. كما بنى المؤلف مدونة بمحلل Markdown مخصص يمكنه تحويل الرموز والأوامر إلى روابط ورسوم بيانية مدمجة.

المكدس أيضاً جاهز تماماً للإنتاج: Elixir/Phoenix LiveView و PostgreSQL و Oban و Tailwind و Lightweight Charts.

من حيث الأرقام، تبين أن المشروع أقرب إلى منتج كامل منه إلى تجربة. قاعدة الكود تحتوي على 422 ألف سطر من كود Elixir وأكثر من 73 ألف سطر من الاختبارات وأكثر من 300 وحدة و 34 عامل Oban و 80 ترحيل قاعدة بيانات. يتم سحب البيانات من خمس API بآن واحد مع تراجع متسلسل: إذا لم ترد مصدر واحد، فإن النظام ينتقل تلقائياً إلى التالي. كان كل شيء يعمل على بنية تحتية متواضعة: VPS على Vultr و PostgreSQL في AWS RDS، بينما تم بناء CI/CD عبر GitHub Actions.

كيفية الحفاظ على الجودة

كان الآلية الرئيسية للتحكم هي ملف CLAUDE.md الذي يقرأه Claude Code في كل جلسة. يصفه المؤلف بأنه دستور المشروع: يتضمن الأوامر الإلزامية والحظر والقواعد المعمارية. بدون مثل هذه القيود، تكتب الذكاء الاصطناعي كود يعمل لكن يصعب إدارته؛ معها، تحافظ على نمط موحد ولا تنسى العملية. أصبح كل خطأ جديد قاعدة جديدة، لذلك نما الملف مع المنتج.

• بعد أي تغيير، mix format و mix credo --strict إلزامي
• ليس سطراً واحداً من كود الإنتاج بدون اختبار فاشل
• للبيانات المالية، float محظور؛ يُسمح فقط بـ Decimal
• لا يمكن لعمال Oban إجراء طلبات قاعدة البيانات داخل الحلقات
• تُعتبر قاعدة البيانات مصدر الحقيقة، وليس حالة العمليات

بعد ذلك، فصل المؤلف الأدوار ضمن تطوير الذكاء الاصطناعي نفسه. في وضع المدير، يتعامل النموذج مع العمارة والقرارات المعمارية وخطط التغيير؛ في وضع المنفذ، يكتب الكود بدقة وفقاً للخطة وفقط من خلال TDD. يتم تقسيم دورة العمل إلى ثلاث مراحل مختلفة: العصف الذهني والتخطيط التفصيلي والتنفيذ بخطوات صغيرة من 2-5 دقائق. يزيل هذا النهج انجراف العمارة: تقرأ كل جلسة ذكاء اصطناعي جديدة القرارات المعمارية والخطط وملفات الذاكرة وتستمر المشروع من السياق المثبت، وليس من الصفر.

حيث كسر الذكاء الاصطناعي الإنتاج

أقيم جزء من القصة ليس الأرقام، بل تحليل حادثتين في الإنتاج.

في الحالة الأولى، كان عمال Oban وطلبات الويب يتقاسمان مجموعة واحدة من 15 اتصالات بـ PostgreSQL. عندما تم إطلاق backfill بـ 923 مهمة، فشحت الواجهة فعلياً. تم حل المشكلة باستخدام ObanRepo مخصص بمجموعة منفصلة للعمليات الداخلية للطابور. بعد ذلك، تمت إضافة ميزانيات الاستعلام الإلزامية لكل عامل وحدود التزامن للطوابير إلى القواعد.

كانت الحالة الثانية أكثر إيضاحاً. أضاف الذكاء الاصطناعي ConnectionWatchdog لمراقبة صحة المجموعة وتجنب تكرار الحادثة الأولى. لكن المراقبة نفسها أصبحت سبب الفشل التالي: تحت الحمل، بدأت الطلبات ذات المهل الزمنية القاسية تقتل الاتصالات، وقام watchdog بإسقاط مجموعة Oban بأكملها في ثوانٍ قليلة. في النهاية، تم حذف المكون ببساطة، وتم تسجيل الدرس في ذاكرة المشروع.

"لا تستخدم أبداً pooled connections مع المهل الزمنية القاسية للمراقبة"

بشكل منفصل، دمج المؤلف MCP Debug Server في التطبيق حتى يتمكن Claude Code من الاتصال بالإنتاج كأداة: قراءة السجلات والتحقق من طوابير Oban وتنفيذ استعلامات SQL والتحقق من المقاييس وإعادة تشغيل العمال بدون SSH والتصحيح اليدوي. لكن حتى هنا هناك حدود: يقتصر الوصول على قائمة بيضاء من الإجراءات حتى لا يصبح التصحيح ثغرة أمنية.

الاستنتاج الرئيسي للمؤلف بسيط: يمكن للذكاء الاصطناعي بكل سهولة الحفاظ على الإنتاج الحقيقي، إذا كان لديه قواعد وذاكرة وتحليلات ما بعد الحادثة وحدود وصول واضحة.

ماذا يعني هذا

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