تجربة Dan Luu: الـ coding agents تختبر أفضل حين لا تُعطى تعليمات عن الاختبار
الوكيل يفهم شكل الاختبار لا جوهره، والـ skills الكبيرة المضافة لتحسينه قد ترفع الفاتورة يوميًا دون أي تحسن في صحة الكود.
نشر المهندس Dan Luu في 7 سبتمبر 2026 تجربة واسعة عن مدى استفادة الـ coding agents من تقنيات الاختبار والتحقق. جرّب 26 صيغة مختلفة لتوجيه الوكيل إلى اختبار عمله، إضافة إلى 4 skills، بمتوسط 80 تشغيلًا لكل حالة، وكانت المهمة تنفيذ Zstd بلغة Rust. ثم أعاد التجربة على مواصفة IMAP بواقع 40 تشغيلًا لكل حالة، ولم تختلف النتيجة.
النتيجة الأبرز أن الحالة الافتراضية، أي دون أي تعليمات عن الاختبار، جاءت فوق المتوسط بفارق واضح.
وكان أداء TDD من الأسوأ. كتب الوكيل ضعف عدد الـ tests، لكن جودتها انخفضت، وفي 67 حالة من 160 كتب test فاشلًا قبل أن يكتب أي تنفيذ حقيقي. أما الـ formal methods مثل Lean وVerus وKani، فكان الوكيل يثبت فيها خصائص مجردة لا علاقة لها بالكود الذي كتبه.
يفسر Luu ذلك بأن الوكيل يفهم شكل الاختبار لا غايته. فحين يُطلب منه property-based testing، أي توليد مدخلات عشوائية للتحقق من خاصية عامة، يختار خاصية صحيحة بشكل بديهي، فتنجح الاختبارات بنسبة 100% دون أن تثبت شيئًا.
أثر الـ skills على التكلفة
الجزء الأقرب إلى فاتورة الفرق يتعلق بالـ skills الكبيرة. فإحداها تضم 34 ألف حرف وتحمّل معها مرجعًا إضافيًا، فيتجاوز الحجم 20 ألف توكن تُقرأ في بداية التشغيل ويُعاد الرجوع إليها باستمرار. رفع ذلك التكلفة 16% على مستوى الجهد medium و18% على xhigh، دون أي تحسن في صحة الكود. كما جاء أداء skill مشروع ECC، الذي يحمل 250 ألف نجمة، تحت المتوسط حين استُخدم فعلًا.
قد يعني ذلك أن كثيرًا من الـ skills التي تضيفها الفرق لتحسين أداء الوكيل تُحمّلها تكلفة يومية ثابتة دون مقابل قابل للقياس، وأن قياس أثر كل skill قبل اعتمادها صار جزءًا من إدارة التكلفة لا من تحسين الجودة فقط.