Claude Code والوكلاء الفرعيون يختصرون إعادة كتابة مشروع قديم من ثلاثة أشهر إلى أسبوع

لا يعود الفارق بين ثلاثة أشهر وأسبوع واحد في هذه القصة إلى أن النماذج بدأت فجأة تكتب شيفرة مثالية، بل إلى أن المؤلف توقف عن استخدام الذكاء الاصطناعي كأداة إكمال تلقائي ذكية، وحوّله إلى خط إنتاج هندسي متكامل. ومن خلال مشروعين بلغة Go بالحجم نفسه، يبيّن أنه عندما يُفكَّك المشروع القديم (legacy) يدويًا وبالحدس، تصطدم السرعة بالفوضى. أما عندما تتوافر للنموذج أدوار وإجراءات ومراجعة وحلقة اختبار، فإن إعادة كتابة المشروع الأحادي تتسارع أضعافًا.

قبل عام، كانت نقطة البداية هي الدين التقني المألوف لدى كثيرين بعد إطلاق المنتج الأولي (MVP). كان في المشروع ملف main.go واحد بنحو ألفي سطر، تتكدس فيه في مكان واحد منطق الأعمال والإعدادات ومعالجات HTTP والتعامل مع قاعدة البيانات وبقية الشيفرة المساندة. قد تصمد هذه البنية في مرحلة الإطلاق المبكر، لكنها تتحمل النمو بصعوبة: فكل تعديل يجرّ وراءه آثارًا جانبية، ويصعب توزيع الشيفرة على مناطق مسؤولية واضحة، وتتحول الاختبارات من سند إلى عبء إضافي. ويتذكر المؤلف أنه كان حينها ينقل النظام إلى بنية سليمة قطعة قطعة، باختبارات من صنعه ومراجعة يدوية متواصلة.

أجرى المؤلف إعادة الهيكلة الأولى في Cursor، واستغرقت منه نحو ثلاثة أشهر. كانت عملية حذرة أشبه بالجراحة: يستخرج كتلة واحدة، ويتحقق من أن السلوك لم ينكسر، ثم ينتقل إلى التالية.

أما المشروع الأخير، وهو بالحجم نفسه، فقد أعطى نتيجة مختلفة تمامًا. استخدم المؤلف Claude Code ونموذج Opus، وربط بهما ثلاثة وكلاء فرعيين يعملون كمراجعين، وبنى حولهم نحو ثلاثين مهارة (skills)، وهي سيناريوهات قابلة للتكرار للعمليات النمطية. وانتهت إعادة الكتابة في أسبوع، علمًا بأن جزءًا ملحوظًا من هذا الوقت لم يُصرف على نقل الشيفرة نفسه، بل على طبقة BDD المبنية فوق التنفيذ. وبحسب تقديره، كان يمكن إنجاز المهمة في نحو ثلاثة أيام لولا سيناريوهات godog.

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

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

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

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