مؤسس يسرّح مطوّريه ويطوّر نظام CRM بمساعدة Claude Code: 22 مجموعة اختبارات

موقف مألوف لأي مؤسس: بُني المنتج على مدى سنوات، واضطر إلى حلّ الفريق، لكن الشيفرة بقيت. كاتب هذه القصة طوّر لسنوات نظام CRM للعمل مع العملاء المحتملين على Telegram. وعندما سُرِّح المطوّرون، وجد نفسه وجهاً لوجه أمام نظام لم يكتبه. وقد روى على موقع Habr كيف خرج من هذا الموقف بمساعدة Claude Code.

ما ورثه

يتكوّن النظام من ست خدمات: لوحة إدارة بتقنية React، وخلفية رئيسية بتقنية FastAPI مع MongoDB وRedis، ومحرّك رسائل يعمل في الخلفية، ووحدة للتعامل مع حسابات Telegram الحية عبر Telethon، وإثراء بيانات العملاء المحتملين، واستقبال الطلبات من الموقع. وفوق ذلك كله Docker وGitLab CI.

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

وكانت هناك اكتشافات مزعجة أيضاً. ففي المستودعات الستة كلها لم يوجد اختبار آلي واحد، مع أن pytest كان مدرجاً ضمن الاعتماديات. وفي ثلاثة سكربتات مساعدة كانت كلمات مرور قاعدة البيانات. أما أخطر مشكلة فلم تكن في الشيفرة: جميع العملاء المحتملين مخزّنون في قاعدة MongoDB واحدة، ولا توجد منها نسخة احتياطية. فالشيفرة يمكن استعادتها من GitLab، أما البيانات فلا.

كيف عمل Claude Code

كانت الخطوة الأولى تدقيقاً شاملاً. كان رمز GitLab للقراءة فقط، فلم يتضرر الأصل. استنسخ Claude عشرة مستودعات، وقرأ ملفات README، واستخرج الروابط بين الخدمات من مفاتيح env وملف docker-compose، ثم رسم خريطة للنظام.

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

الخطوة الثالثة: ظهرت حول النظام القديم طبقة ثانية قائمة على قواعد بيانات SQLite محلية تضم العملاء المحتملين والمراسلات الشخصية والدردشات. وفي قاعدة العملاء الآن نحو 99 ألف سجل، وفي الطبقة الجديدة 22 مجموعة اختبارات.

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

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

يحدّد الكاتب المهمة بكلماته الخاصة، وغالباً بالصوت. يفتح Claude جلسة منفصلة، ويقرأ الشيفرة والبيانات الحقيقية، ويشرح ما الذي سيتغير وما الذي قد ينكسر. ثم يكتب سكربتاً صغيراً واختبارات. وتراجع النتيجةَ نماذجُ أخرى أيضاً: Codex وGrok وGemini. ويرى الكاتب أن ذلك أكثر موثوقية.

كل عمليات الإرسال إلى Telegram تمرّ عبر safe_send.py، ويحسب budget.py الحدود، وهي عادةً 5 رسائل في اليوم لكل حساب. وفي الليل يخدم النظام نفسه بنفسه: ينزّل المراسلات، ويعيد حساب العملاء المحتملين «الدافئين»، ويذكّر بالمواعيد الموعودة. هذه سكربتات عادية بلا LLM، لذلك تكاد الرموز لا تُستهلك، ويجري التطوير ضمن الاشتراك.

القيود والخلاصة

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

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