شرحت SimpleOne لماذا يسرّع vibe coding الإصدارات، لكنه يضعف الكود وعمليات المراجعة

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

لماذا يختلف المطورون

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

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

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

لماذا الأعمال لا تنتظر

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

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

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

ومع ذلك، بالنسبة للبنوك والرعاية الصحية والبنية التحتية الحكومية، يبقى هذا النهج محفوفاً بالمخاطر.

أين يمر الحد

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

"الهدف من البرمجة بالإحساس هو تقديم منتج عاملي وقليل التكلفة بسرعة."

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

بهذا المعنى، البرمجة بالإحساس تتطلب ليس إيماناً بل مقاييس وانضباطاً.

ماذا يعني هذا

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

ستستفيد الفرق التي تتعلم الفصل بصدق بين التجارب السريعة ومناطق بتكلفة خطأ عالية أكثر من غيرها.