علينا أن نتوقف عن تسمية كل شيء بـ Vibe Coding

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

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

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

في تجربة يمكن التخلص منها ولا تغادر جهازك الخاص، قد تكون الفروق قليلة العواقب. بمجرد نشر البرنامج، واستخدامه من قبل الآخرين أو ربطه ببيانات حقيقية، تصبح الأهمية هائلة.

كيف فقدت “Vibe Coding” معناها

تم صك مصطلح “vibe coding” في فبراير 2025 بواسطة أندريه كارباتي، المؤسس المشارك لشركة OpenAI. كان مثالَه متعمدًا غير رسمي: “مشروع عطلة نهاية أسبوع عابر” تم بناؤه بالنقر تلقائيًا على “Accept All”، متجاهلاً الفروقات ومسموحًا للكود أن ينمو خارج نطاق فهمه.

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

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

الخط هو المسؤولية

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

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

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

ماذا يحدث عندما تكون السيطرة مفقودة

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

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

هذه ليست حالات معزولة تحدث فقط في “مشاريع سيئة”. وفقًا لتقرير DORA لعام 2025 الصادر عن Google، يستخدم 90٪ من المطورين الآن الذكاء الاصطناعي في العمل، بينما يبلغ نحو الثلث تقريبًا عن قلة الثقة أو عدم الثقة في ما يولده.

استخدام الذكاء الاصطناعي الآن واسع الانتشار، رغم أن الثقة لا تزال محدودة. وهذا يجعل المراجعة الدقيقة مهمة بشكل خاص عندما يتعامل الكود المولّد مع المصادقة أو الأذونات أو البيانات الحساسة.

التحكم يُبنى بطبقات، ليس مرة واحدة

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

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

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

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

مقارنةً بحالات Tea و Lovable، كانت هذه مشكلة عادية. وجدتها مبكرًا، أصلحتها وتقدمت. هذا هو ما تبدو عليه المراجعة عادةً في الممارسة. في معظم الأحيان، تمنع المشكلات الصغيرة من النمو إلى مشكلات أكبر.

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

من Vibe Coding إلى الهندسة الوكّالية

تحول كارباتي نفسه بعيدًا عن “vibe coding” نحو “agentic engineering” ليس مجرد تغيير في المفردات. “الهندسة الوكّالية” تمنحنا اسمًا أكثر فائدة للاتجاه الذي يتخذه التطوير المهني. قد يكتب المطورون خطوطًا أقل بأنفسهم، لكن ذلك لا يقلل من مسؤوليتهم. بل ينقل عملهم إلى تحديد ما يجب أن يفعله النظام، وتوجيه الوكلاء، واختبار مخرجاتهم، وتحديد ما هو آمن للإصدار.

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

قاعدة تستحق الحفاظ عليها

توقف عن استخدام “vibe coding” كوسم لكل أشكال التطوير المدعوم بالذكاء الاصطناعي – فهذا يخفّف من المصطلح ويمحو الفارق في التحكم الذي يهم. ضع قاعدة بسيطة: لا تُصدر ما لا يمكنك شرحه. وابنِ التحكم في المشروع مع نموه، طبقةً بعد طبقة، مضيفًا فحوصات تتماشى مع المخاطر التي تظهر.

قد يكتب الذكاء الاصطناعي معظم الكود. لا يستطيع تحمل المسؤولية عن إصداره. ذلك لا يزال يعود إلينا.