أفضل وكلاء الذكاء الاصطناعي يجتازون حتى 98% من الاختبارات، لكنهم لا يقدمون منتجًا يعمل بالكامل إلا في 65% من عمليات البناء كحد أقصى

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

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

لذلك أطلقت Replit مقياس ViBench 2.0. والنتيجة: تجتاز النماذج الثلاثة الأقوى حتى 98% من سيناريوهات الاختبار، لكنها لا تقدم منتجًا يعمل بالكامل إلا في 65% من عمليات البناء كحد أقصى.

تُسمّى نسبة عمليات البناء العاملة بالكامل من المحاولة الأولى pass@1. وإذا كنتم تبنون منتجًا على وكيل ذكاء اصطناعي، فهذا هو المؤشر الذي ينبغي النظر إليه.

كيف صُمّم الاختبار

يبدأ الوكيل من مشروع فارغ، ويتلقى المتطلبات وظيفةً وظيفةً ضمن حوار طويل واحد. يضم كل منتج من 9 إلى 18 طلبًا، وقد يتجاوز الحوار 200 ألف توكن، ويُخصَّص لكل مرحلة ما لا يزيد على 300 خطوة للوكيل وساعتين. يضم المقياس 17 منتج ويب متكاملًا مستوحاة من Amazon وAsana وDiscord وFigma وGitHub وGoogle Docs وJira وUber. وفيها 241 طلبًا لوظائف جديدة و544 سيناريو اختبار، ويفحص 85% من هذه السيناريوهات عدة وظائف معًا.

لا يتحقق أحد من النتيجة بين الطلبات. يُمنح التقييم مرة واحدة عندما يكتمل المنتج، ويجريه وكيل متصفح يفتح التطبيق في Chromium حقيقي ويتصرف كما يتصرف المستخدم. لا تُحتسب عملية البناء ناجحة إلا إذا اجتازت جميع سيناريوهات المنتج، وعددها لكل منتج بين 26 و41. يختار الوكيل بنفسه البنية المعمارية، ولذلك تفحص الاختبارات النتيجة لا تصميمًا بعينه. ولا يُعد وجود النص «Waiting at stop» بدلًا من «At Stop» خطأً.

واختبر المؤلفون المُقيِّم نفسه أيضًا. فهو يعيد فحص السيناريو الفاشل حتى أربع مرات، إلى أن تتطابق ثلاثة تقييمات. وقد اكتشف جميع الأخطاء الأربعة والثلاثين (34) التي أُدخلت عمدًا، ولم تتجاوز نسبة «حالات القبول» الخاطئة لديه 0,8%. ويعمل المُقيِّم وإعداد بيانات الاختبار على Opus 5.5.

الفجوة بين «تقريبًا» و«جاهز»

اختبر المؤلفون تسعة نماذج. يجتاز القادة، وهم GPT-6.1 Sol وGPT-6 Astra وOpus 5.5، حتى 98% من السيناريوهات. لكنهم لا يقدمون منتجًا يعمل بالكامل إلا في 65% من عمليات البناء كحد أقصى. وفي معظم عمليات البناء الفاشلة لدى هذه الثلاثة، أخفق سيناريو واحد أو سيناريوهان فقط. أي أن مجال التحسّن يكمن في الموثوقية، لا في القدرة على إنجاز شيء ما. ولم يقدم أي نموذج مفتوح منتجًا يعمل بالكامل ولو مرة واحدة.

ومع ذلك فالتحسّن سريع. ففي ثلاثة إصدارات من عائلة نماذج واحدة، ارتفع pass@1 على المنتجات العامة من 3% إلى 53%، وانخفضت تكلفة عملية البناء الواحدة بأكثر من النصف. وهذا مهم لمقاييس أخرى أيضًا: ففي Vibe Code Bench ارتفعت أفضل نتيجة من 61,8% في مارس 2026 إلى أكثر من 90% لدى ستة نماذج بحلول نهاية أكتوبر. أما الاختبارات التي ينفذ فيها الوكيل مهمة واحدة فتبلغ سقفها بسرعة. في المقابل، لم يبلغ البناء الطويل مع فحص المنتج النهائي سقفه بعد.

ما العمل؟

يُخفي متوسط نسبة الاختبارات المجتازة الأمر الأهم: فوظيفة قديمة واحدة معطلة تجعل عملية البناء غير صالحة. قيّموا النماذج بحسب نسبة عمليات البناء الخالية من العيوب. وافحصوا المنتج ككل كما كان سيفعل المستخدم، لا الخطوات المنفردة فقط. وتستخدم Replit نفسها ViBench 2.0 عند اختيار النماذج لمنصتها وعند تقييم التغييرات في وكيل الإنتاج لديها.

ثمة تحفظات أيضًا. فـ Replit هي مؤلفة الاختبار وهي من يستخدمه. لكن فريق Fireworks الخارجي تحقق من التشغيل: فقد شغّل المقياس المنشور وأجرى كل نموذج بأمر واحد ودون أي تعديلات. ونُشرت ثمانية منتجات على GitHub مع أداة التشغيل والمُقيِّم. أما المنتجات التسعة الأخرى فمخفية، لئلا تُدرَّب النماذج على الاختبار. وقد وُسمت الملفات العامة بسطر خاص يمكن بواسطته استبعادها من بيانات التدريب.