مقارنة Anthropic Claude Code بمطوّر مبتدئ واستخلاص 5 قواعد للإنتاج

يستطيع Claude Code أن يمنح المطوّر الفرد وتيرة عمل فريق صغير، لكنه لا يعمل في بيئة الإنتاج إلا تحت إدارة صارمة. هذا هو الاستنتاج الذي خلص إليه صاحب الحالة، الذي بنى خلال شهر واحد نظامًا للتحليل الدوري لأسعار المنافسين وعروضهم من المنتجات. ووفق تجربته، يتصرف النموذج كمطوّر junior مبادر: يكتب كمًّا كبيرًا من الكود بسرعة، ويقترح حلولًا غير تقليدية، ولا يعترض، لكنه يفقد السياق بسهولة بين الجلسات. وفي غياب انضباط خارجي يبدأ بإعادة ابتكار البنية المعمارية من جديد، وتجاوز حدود الوحدات (modules)، وإدخال تغييرات غير متسقة.

ولا يبدو المشروع نفسه عرضًا تجريبيًا (demo)، بل نظامًا عمليًا متكاملًا. فهو يضم حاليًا نحو 25 مصدرًا تعمل على محركات مختلفة، من المواقع الثابتة إلى تطبيقات SPA، ويُخطَّط لرفع عددها إلى نحو 60 مصدرًا بحلول نهاية العام. وتشمل مجموعة البيانات الحالية نحو 6000 صنف، ومن المتوقع أن تبلغ نحو 15000 على العيّنة الكاملة. واستُخدمت في التطوير SQLite وPostgreSQL، وفي الاستخراج (parsing) حزمة من requests وBeautifulSoup وlxml وPlaywright، مع نهج API-first حيثما أمكن جلب البيانات مباشرة. وفوق ذلك بُنيت طبقة تحليلية لقياس الأسعار مرجعيًا (benchmark)، وتحليل الفجوات (gap analysis)، ومقارنة خصائص المنتجات. أما المطابقة (matching) فتُنفَّذ على عدة مراحل: مرشِّح أولي، ثم embeddings، ثم LLM-as-judge للحالات الحدّية.

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

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

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

ويتضمن النص أيضًا واقعة تقنية معبّرة. ففي أثناء تحسين المطابقة، جعل Claude Code العمل مع sqlite3.Connection متوازيًا عبر ThreadPoolExecutor، فزادت السرعة، لكن ذلك أدى تحت الحمل على macOS إلى انهيارات. ولم تُكتشف المشكلة إلا بفضل مراجعة دقيقة واختبار تحميل، وجرى إصلاحها بالانتقال إلى اتصال منفصل لكل خيط (thread) عبر threading.local(). وبعد ذلك أمكن الحفاظ على الاستقرار وتحقيق زيادة في الأداء بعدة أضعاف. وهذا المثال مهم لا لذاته، بل بوصفه توضيحًا للفكرة الأساسية: يمكن للنموذج أن يقترح حلًّا يبدو صالحًا، لكنه في الواقع يحمل مخاطر خفية في بيئة الإنتاج.

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

والخلاصة الرئيسية للسوق بسيطة: أدوات AI لا تلغي التطوير على مستوى senior، بل ترفع المتطلبات منه. فـ Claude Code يسرّع التنفيذ، لكنه لا يتحمل المسؤولية عن بنية النظام وجودته وقدرته على الاستمرار. وكلما طال العمر المنتظر للمنتج، زادت أهمية الذاكرة الخارجية وحواجز الانحدار والرقابة الهندسية اليدوية. ومن دون ذلك لا ينتج نظام إنتاجي ناضج، بل مجرد انطباع مقنع بأنه جاهز بالفعل للتشغيل الطويل.