مقال يقارن Bend 2 بلغة SPARK: 500 سطر مقابل نحو 50 للنتيجة نفسها
النموذج لا يخبر المطور بأن مجالًا كاملًا حلّ مشكلته من قبل. يبني ما طُلب منه بسرعة وكفاءة، وهذه السرعة نفسها تغلق النافذة التي كان سيرى منها الحل الأفضل.
نشر Liam Powell في 18 سبتمبر 2026 مقالًا بعنوان Bend 2 and the Vibe-Coding Trap. وBend 2 لغة تقدّم نفسها لعصر الذكاء الاصطناعي بفكرة محددة: البشر يكتبون القوانين، والذكاء الاصطناعي يكتب التنفيذ والإثباتات، والـ compiler يتحقق من سلامة هذه الإثباتات.
في العرض الرسمي للغة، يكتب المطور 58 سطرًا تحدد قواعد لعبة، ثم يولّد نموذج لغوي 442 سطرًا من كود الإثبات للتحقق منها.
أعاد Powell العرض نفسه باستخدام SPARK، وهي لغة قائمة للتحقق الرسمي (formal verification)، أي إثبات صحة البرنامج رياضيًا بدل الاكتفاء باختباره، وتُستخدم في الأنظمة الحرجة. وجاء الحل في نحو 50 سطرًا إجمالًا، وأعاد التحقق الآلي سطرًا واحدًا: “Success: all checks proved (12 checks)”.
والجملة المحورية في المقال أن الـ vibe coding، أي البرمجة بتوجيه النموذج دون تعمّق في الكود، “يجعل من الممكن أن تبني حلًا كبيرًا قبل أن تتعلم عن المشكلة ما يكفي لتدرك أن حلًا أفضل بكثير موجود بالفعل”.
ولا يقول المقال إن Bend 2 كود رديء. فالمشكلة ليست في جودة ما كُتب، بل في أن سؤال “هل حلّ أحد هذه المشكلة من قبل؟” لم يُطرح أصلًا.
والآلية هنا تستحق الانتباه. فالنموذج لن يتطوع ليقول إن مجالًا كاملًا اسمه formal verification يعالج هذه المسألة منذ سنوات. هو ينفّذ ما طُلب منه، بسرعة وبجودة معقولة. وهذه السرعة بالذات تقلّص الوقت الذي كان المطور سيقضيه في البحث والقراءة قبل البناء، وهو الوقت الذي كانت تُكتشف فيه عادةً الحلول الموجودة.