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

أكثر من 70% من المطورين، وفقًا لمختلف الاستطلاعات، يستخدمون بالفعل أدوات الذكاء الاصطناعي بانتظام في كتابة الأكواد البرمجية — لكن منهجيات العمل معها ما زالت تتشكّل بشكل عفوي حتى الآن. وصف أحد المطورين، الذي يستخدم نماذج اللغة الكبيرة (LLM) في عمله اليومي منذ أكثر من عام، الطريق المؤلم من "الترميز بالحدس" (vibe coding) الساذج إلى نظام هندسي قائم على ثلاثة مبادئ يتيح استخدام مساعدي الذكاء الاصطناعي دون فقدان جودة قاعدة الأكواد.

ما هو الترميز بالحدس ولماذا يفشل؟

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

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

المبادئ الثلاثة للمنهجية

المبدأ الأول هو فصل السياق بحسب المحادثات. فبدلًا من حوار واحد لا ينتهي يفقد فيه النموذج الخيط تدريجيًا، يخصص الكاتب جلسات منفصلة لمهام محددة: القرارات المعمارية، وكتابة منطق العمل (business logic)، والاختبار، وإعادة الهيكلة. وتحصل كل محادثة على موجّه نظام (system prompt) خاص بها يصف المكدّس التقني (stack) والاتفاقيات الأساسية والحالة الراهنة للوحدة — وهذا لا يزيل مشكلة نافذة السياق المحدودة كليًا، لكنه يقلّل خطر أن "ينسى" النموذج تفاصيل بالغة الأهمية.

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

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

ثمن الانضباط ودور المطور

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

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

ما هو الترميز بالحدس؟

الترميز بالحدس (vibe coding) مصطلح ساخر يصف ممارسة يكتفي فيها المبرمج بتسليم المهام إلى نموذج اللغة وقبول كل ما يولّده تقريبًا دون مراجعة جدية. في البداية يبدو الكود نظيفًا ومرتّبًا، لكن مع نمو المشروع يتراكم دَين تقني خفي: منطق مكرّر، وسياق نسيَه النموذج، وأجزاء بديلة يسهل الخلط بينها وبين كود فعلي يعمل.

ما هي المبادئ الثلاثة التي يقترحها صاحب المنهجية؟

تقوم المنهجية على ثلاثة مبادئ: فصل السياق في محادثات منفصلة لمهام محددة (المعمارية، منطق العمل، الاختبار، إعادة الهيكلة)، لكل منها موجّه نظام خاص بها؛ ومخرجات منظّمة إلزامية في كل خطوة — تصف القرارات والتبعيات والافتراضات والأجزاء البديلة الصريحة؛ وقوائم تحقق بعد كل عملية توليد، تفحص الازدواجية والأسلوب وعلامات TODO والحالات الحدّية، وبعضها آلي عبر أدوات linters.

كم عدد المطورين الذين يستخدمون بالفعل أدوات الذكاء الاصطناعي في عملهم؟

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