نهاية الـvibe coding: كيف تبني عملية تطوير بمساعدة LLM من دون أن تقتل المشروع

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

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

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

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

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

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

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

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

يبدو أن عهد الـ vibe coding الساذج يقترب من نهايته. المطورون الذين أتقنوا نماذج اللغة كأداة ينتقلون الآن إلى المرحلة التالية — بناء عمليات ناضجة حولها. وأولئك الذين يتمكنون من تحويل التوليد الفوضوي إلى خط أنابيب هندسي مُدار سيحصلون على ميزة تنافسية حقيقية — ليس فقط السرعة، بل السرعة دون فقدان الجودة.