لماذا تفشل وكلاء البرمجة الذكية في الميزات المعقدة

وكلاء البرمجة بالذكاء الاصطناعي منتشرة في كل مكان في 2026. تكتب طلبات السحب، تصلح الأخطاء، وتولّد الاختبارات. يقبل المشرفون على المشاريع مفتوحة المصدر 83.8% من طلبات السحب التي يولّدها Claude Code، وأكثر من نصفها يُدمج بدون أي تعديل بشري. العناوين توحي بأننا اقتربنا من هندسة البرمجيات المستقلة.

لكن معيار قياس جديد يروي قصة مختلفة تماماً. FeatureBench، المنشور في فبراير 2026 من قبل باحثين من الأكاديمية الصينية للعلوم وهواوي، اختبر وكلاء الذكاء الاصطناعي الرائدة على تطوير ميزات معقدة متعددة الملفات. النتائج مذهلة: Claude Opus 4.5 الذي يحل 74.4% من مهام SWE-bench ينجح في 11.0% فقط من مهام FeatureBench. حتى أفضل تكوين — Codex مع GPT-5.1 — يحقق فقط 12.5%.

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

ما الذي يقيسه FeatureBench فعلاً

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

FeatureBench يغيّر قواعد اللعبة باختبار تطوير على مستوى الميزات — النوع من العمل الذي يمتد عبر عدة التزامات، يمس ملفات كثيرة، ويتطلب فهم كيفية ارتباط أجزاء قاعدة الكود المختلفة. مهمة FeatureBench النموذجية تتطلب:

• حوالي 790 سطراً من الكود الجديد
• تغييرات عبر 15 ملفاً أو أكثر
• اجتياز 60 نقطة اختبار أو أكثر
• فهم تبعيات معقدة عبر الملفات

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

ثلاثة أسباب لفشل الوكلاء في الميزات المعقدة

حدد باحثو FeatureBench ثلاثة أنماط فشل أساسية تفسر الانخفاض الدراماتيكي في الأداء.

1. عمى التبعيات عبر الملفات

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

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

2. مشكلة الكسل

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

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

3. الحجم والتخطيط طويل المدى

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

إصلاح الخطأ عملية تكتيكية. بناء الميزة عملية استراتيجية. الوكلاء أكفاء تكتيكياً لكن ضعفاء استراتيجياً.

الأدلة من المصادر المفتوحة

تتوافق نتائج FeatureBench مع بحث أوسع حول تبني وكلاء الذكاء الاصطناعي في المشاريع مفتوحة المصدر. دراسة MSR لعام 2026 التي حللت مئات طلبات السحب المولّدة بالذكاء الاصطناعي عبر مشاريع مفتوحة المصدر وجدت أنماطاً واضحة:

• مهام التوثيق تحقق معدل قبول 82.1%
• الميزات الجديدة تنخفض إلى 66.1%
• التغييرات الهيكلية مثل إعادة الهيكلة تحقق أدنى معدلات نجاح وأطول أوقات حل

النمط ثابت: كلما زاد تعقيد المهمة وتشعبها، زادت احتمالية فشل الوكيل أو حاجته لتدخل بشري كبير.

ماذا يعني هذا للمطورين

هذه البيانات لا تعني أن وكلاء البرمجة الذكية عديمة الفائدة — بل العكس تماماً. معدل القبول 83.8% لطلبات Claude Code حقيقي ومثير للإعجاب. لكنه يعني أن المطورين يجب أن يُعايروا توقعاتهم.

أين تقدم الوكلاء قيمة اليوم

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

أين تبقى الرقابة البشرية حاسمة

• تطوير الميزات متعددة الملفات عبر قاعدة الكود
• القرارات المعمارية حول تصميم النظام
• الاهتمامات المتقاطعة كالمصادقة والتخزين المؤقت والسجلات
• أعمال التكامل التي تربط أنظمة متعددة
• تحسين الأداء الذي يتطلب فهماً عميقاً للنظام

سير العمل الناشئ

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

الطريق للأمام

يشير FeatureBench إلى مجالات محددة تحتاج فيها الوكلاء للتحسين:

1. استكشاف أفضل للكود — يجب أن تقرأ الوكلاء قواعد الكود وتفهمها بشكل منهجي قبل محاولة التغييرات
2. إدارة السياق الطويل — الحفاظ على فهم متماسك عبر عشرات الملفات أثناء مهمة واحدة
3. التطوير القائم على الاختبارات — استخدام الاختبارات القابلة للتنفيذ كتغذية راجعة أثناء التنفيذ
4. التخطيط قبل البرمجة — إنشاء واتباع خطط تنفيذ للميزات متعددة الخطوات

هذه مشاكل قابلة للحل. الفجوة بين 11% و74% ليست دائمة — إنها خارطة طريق. لكن في الوقت الحالي، الرسالة واضحة: وكلاء البرمجة الذكية مساعدون أقوياء وليسوا مهندسين مستقلين. المطورون الذين يفهمون هذا الفارق سيبنون برمجيات أفضل وأسرع من أولئك الذين يتوقعون أن تفعل الوكلاء كل شيء.

المعيار لا يكذب. ولا معدل القبول 83.8% على المهام البسيطة. كلا الرقمين صحيح في نفس الوقت — وهذا بالضبط لماذا فهم الفجوة مهم.