vibe coding أخلف وعده

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

الحلم الذي بعناه لأنفسنا قبل ستة أشهر يقف الآن على الباب ويطلب استرداد ماله.

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

لكن في مكان ما بين العرض والنشر جرى استبدال صامت. بدأنا نسمّي النماذج الأولية منتجات. وبدأنا نسمّي العروض برمجيات. وفاتورة هذا الالتباس تصل الآن.

التشخيص الخاطئ

أشيع تفسير أراه يلوم النموذج. الذكاء الاصطناعي ليس ذكياً بما يكفي بعد. يهلوس. يختار مكتبات خاطئة. يكتب شفرة كان مهندس متمرس سيمسكها ويعيد كتابتها.

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

لا أعتقد ذلك. ولا أعتقده لأن الطريقة التي يفشل بها هذا لا علاقة لها بجودة الشفرة.

أعلنت Microsoft في نتائج 2025 أن نحو 46 بالمئة من كل الشفرة التي يدفعها مستخدمو GitHub Copilot النشطون يولّدها الذكاء الاصطناعي الآن. وفي الفترة نفسها، نشرت شركة أمن التطبيقات Veracode بحثاً وجد أن الشفرة المُولَّدة بالذكاء الاصطناعي أدخلت ثغرات أمنية في نحو 45 بالمئة من العينات المدروسة. وهذه الأرقام ستسوء قبل أن تتحسن، ولن يصلحها نموذج أذكى.

المشكلة ليست النموذج. المشكلة هي المسار.

ما ينقص فعلاً

استعرض معي ولادة تطبيق صُنع بـ vibe coding وأرني أين يُتخذ القرار البنيوي.

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

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

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

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

ثلاثة قرارات لم تُتخذ قط

سأكون محدداً، لأن التجريد هو سبب دوران هذا الحوار في حلقة.

المصادقة ليست خصيصة تُضاف لاحقاً. إنها قرار بشأن من هم مستخدموك، وما يمكنهم رؤيته، وعلى أي حدّ ثقة يقف تطبيقك. وتثبيتها بالبراغي في تطبيق صُنع بـ vibe coding بعد أسبوعين من الإطلاق هو المكافئ البرمجي لتركيب باب أمامي لبيت بُني بلا جدران.

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

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

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

مشكلة السبعين بالمئة لها اسم الآن

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

الزمن إلى السحر صار شيئاً قابلاً للقياس. أما الزمن إلى الإنتاج فكان مشكلة شخص آخر.

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

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

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

القاعدة التي لم يغيّرها الذكاء الاصطناعي

إليك ما لا يريد أحد سماعه، لأنه يُسمَع كخطوة إلى الخلف في لحظة يُفترض أن تكون حركة إلى الأمام فقط.

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

لم يغيّر الذكاء الاصطناعي هذه القاعدة. لقد جعلها أهم لا أقل أهمية.

فحين تقترب تكلفة إنتاج الشفرة من الصفر، تقترب تكلفة إنتاج الشفرة السيئة من الصفر أيضاً. أي أن الشيء الوحيد الذي لا يزال يكلّف هو معرفة أي شفرة تكون صحيحة. وذلك العمل (عمل التعريف، وعمل البنية، والجزء الذي تحسم فيه ما تبنيه فعلاً قبل أن تبدأ البناء) هو الجزء الوحيد الذي لم يتحول إلى سلعة.

وهو في الوقت نفسه الجزء الذي تجاوزه جيل الأدوات الحالي.

إلى أين يمضي هذا فعلاً

لا أعتقد أن الجواب هو التمهّل. ولا أعتقد أن الجواب هو العودة إلى كتابة كل شيء باليد. القفزة كانت حقيقية والقفزة باقية.

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

الشاشة التي تعمل لم تكن يوماً الشيء نفسه كالنظام الذي يعمل. وكلنا على وشك أن نتذكر لماذا.

قراءات ذات صلة

ما احتل مكانه: التطوير الموجَّه بالمواصفات. وكيف حال الأدوات اليوم: أفضل مُولِّدات التطبيقات بالذكاء الاصطناعي في 2026.

الأسئلة الشائعة

ماذا يعني «vibe coding»؟ vibe coding هو كتابة البرمجيات بوصف ما تريد بلغة بسيطة وقبول ما ينتجه الذكاء الاصطناعي، دون تعريف البنية أو نموذج البيانات أو العقود تحته. أدخل Andrej Karpathy هذا المصطلح في أوائل 2025. وهو يصف طريقة عمل لا فئة أدوات: فـ vibe coding ممكن في كل مُولِّد ذكاء اصطناعي تقريباً.

لماذا تنكسر التطبيقات المصنوعة بـ vibe coding في الإنتاج؟ لأن العطل بنيوي لا مسألة جودة شفرة. فحلقة التوليد لا تنتج قط مخططاً ولا مجموعة معرَّفة من الحالات الصحيحة ولا عقداً بين الواجهة الأمامية والخلفية. فالتطبيق يعمل على المسار الذي عُرض عليه، ويتفكك خارجه. والنموذج الأذكى المطبَّق على مشكلة غير معرَّفة يعطي نتيجة غير معرَّفة كذلك.

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

هل الشفرة المُولَّدة بالذكاء الاصطناعي أقل أمناً؟ الأدلة الحالية تقول إنها تحتاج مراجعة. فقد وجد بحث Veracode أن الشفرة المُولَّدة بالذكاء الاصطناعي أدخلت ثغرات أمنية في نحو 45 بالمئة من العينات المدروسة، في الوقت الذي كانت Microsoft تعلن أن نحو 46 بالمئة من الشفرة التي يدفعها مستخدمو Copilot النشطون مُولَّدة بالذكاء الاصطناعي. فالحجم ينمو أسرع من التحقق.

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