أظهرت تجربة أجرتها JetBrains أن منح وكلاء الذكاء الاصطناعي وصولاً مباشراً إلى محرك إعادة الهيكلة في Rider يمكن أن يغيّر طريقة تنفيذ مهام C# جذرياً، بدلاً من دفع الوكيل إلى تعديل النصوص ثم تشغيل المترجم لاكتشاف ما أفسدته التغييرات. ففي اختبار شمل 15 مهمة، انخفض الزمن الوسطي للمهمة من 157.9 ثانية إلى 26.6 ثانية، أي بنسبة تحسن بلغت 83%، كما تراجع عدد استدعاءات الأدوات من 17 إلى 6.2 لكل مهمة.
تأتي هذه الإمكانية ضمن مهارة مدمجة باسم refactoring-code، وهي متاحة في Rider ابتداءً من الإصدار 2026.2.1. ووفق JetBrains، لا يحتاج المستخدم إلى تفعيلها يدوياً؛ إذ يستدعيها الوكيل تلقائياً عندما يُطلب منه تنفيذ إعادة هيكلة لشيفرة C#. ويعتمد المحرك على تقنيات ReSharper وبنية Rider التحليلية لفهم العلاقات بين الرموز والمراجع داخل المشروع.
المشكلة في أسلوب التعديل ثم البناء
قبل إتاحة المهارة، راقبت JetBrains نموذجاً متقدماً أثناء تنفيذ المهام نفسها. وخلال 2,513 استدعاء لأدوات مختلفة، لم ينفذ الوكيل أي عملية إعادة هيكلة بنيوية مباشرة، لأنه لم تكن لديه أداة مخصصة لذلك. بدلاً من ذلك، استخدم أوامر تفاعلية لإدخال النصوص 468 مرة، واستدعى git sebanyak 422 مرة وsed sebanyak 392 مرة، كما شغّل dotnet build 163 مرة.
لا يعني ذلك أن الوكيل كان يتجنب عمليات إعادة الهيكلة، بل كان يحاول تقريبها من خلال البحث والتعديل النصي ثم استخدام نتائج البناء لتقييم ما حدث. وتوضح JetBrains أن إعادة تسمية رمز، مثلاً، تتطلب التمييز بين المراجع المرتبطة بتعريف معين، واستدعاءات الدوال متعددة الأشكال، والأصناف الجزئية، وتطبيقات الواجهات الصريحة، ومراجع التوثيق. هذه العلاقات لا يمكن ضمانها بانتظام بسيط.
في المقابل، يعمل محرك Rider على شجرة بناء جملة محلولة تحدد التعريف الذي يرتبط به كل معرّف، والنسخة التي يستدعيها كل استدعاء، ومواقع المراجع عبر الحل البرمجي. وبهذا ينتقل الجزء البنيوي من المهمة إلى المحرك، بدلاً من أن يعيد الوكيل اكتشاف هذه العلاقات تدريجياً عبر دورات متكررة من التعديل والبناء وقراءة الأخطاء.
ما الذي قاستْه JetBrains؟
ركز التقييم على ثماني عمليات ذات نتائج قابلة للتحقق بوضوح، وهي:
- إعادة تسمية رمز وجميع المراجع إليه.
- استخراج مجموعة من التعليمات إلى دالة جديدة.
- استخراج واجهة من نوع موجود.
- استخراج صنف أساسي ونقل الأعضاء إليه.
- تغيير توقيع واجهة برمجية وتحديث مواضع الاستدعاء.
- نقل نوع إلى مساحة أسماء أخرى وإصلاح عبارات using.
- إعادة تنظيم مساحات الأسماء بما يطابق بنية المجلدات.
- حذف رمز بأمان عندما لا يعتمد عليه أي جزء آخر.
شملت المهام حالات مباشرة وأخرى أكثر تعقيداً، مع عدد أكبر من مواضع الاستدعاء أو اعتماديات متشابكة. وشغّل الطرفان النموذج نفسه، gpt-5.5، عبر Codex CLI، نحو عشر مرات لكل مهمة تقريباً. وكان الاختلاف الوحيد هو إتاحة مهارة refactoring-code من عدمها. واعتمدت المقارنات على الآثار المسجلة واختبار permutation مقترن.
النتائج العملية والتكلفة
مع تفعيل المهارة، انخفض عدد عمليات dotnet build من 163 إلى ثلاث عمليات فقط، وتراجع إجمالي استدعاءات الأدوات في التقييم من 2,513 إلى 926. ولم تتوقف التعديلات النصية، إذ ظل sed الأداة الأكثر استخداماً، لكن توزيع الأدوار تغير: بقيت التعديلات العادية ضمن أدوات التحرير النصي، بينما تولى المحرك التغييرات البنيوية التي قد تمتد آثارها إلى أجزاء لا يراها الوكيل مباشرة.
انخفض الزمن عند الشريحة المئوية 95 من 346.4 إلى 56.9 ثانية، وهو تحسن يرتبط خصوصاً باختفاء الحالات العالقة في دورة التعديل ثم البناء ثم معالجة الأخطاء. أما التكلفة الوسيطة لكل مهمة فتراجعت من 0.33 دولار إلى 0.12 دولار، وانخفضت التكلفة لكل مهمة ناجحة من 0.52 دولار إلى 0.19 دولار. كما تراجع عدد الرموز المُدخلة من 436,745 إلى 208,524 لكل مهمة، وقراءات الذاكرة المؤقتة من 2,973,158 إلى 1,257,600، والمخرجات من 32,532 إلى 15,538.
ماذا يعني ذلك للمستخدمين؟
توضح التجربة أن فائدة أدوات الوكلاء لا تعتمد فقط على قدرة النموذج على إنتاج الشيفرة، بل أيضاً على نوع الأدوات التي يستطيع استدعاءها. ففي ثماني مهام من أصل 15 كان الطرف المزود بالمهارة أسرع وأقل تكلفة ولم يستخدم عدداً أكبر من الأدوات، مع نجاح الطرفين في الاختبارات. وتحسنت المهام الست التي استغرق تنفيذها أكثر من دقيقتين في الوضع الأساسي بنسبة تراوحت بين 82% و94%.
لكن النتائج ليست مكسباً شاملاً لكل حالة. فقد فشل الطرفان في مهمتين، ونجح الوضع الأساسي في مهمة لم ينجح فيها الوضع المزود بالمهارة، بينما كانت أربع مهام سريعة أصلاً إلى حد لم يجعل استدعاء محرك Rider مفيداً اقتصادياً. لذلك تقدم الأرقام دليلاً على جدوى المهارة ضمن مجموعة محددة من عمليات إعادة الهيكلة، لا ضماناً بأن كل مهمة ستتحسن بالقدر نفسه.
ولتجسيد الفرق، عرضت JetBrains مهمة استخراج صنف أساسي من النوع ReportExporter. استغرق التنفيذ من دون المهارة 336.7 ثانية و24 استدعاءً بتكلفة 1.15 دولار، وتضمن دورات متعددة من تعديل الملفات وتشغيل البناء لمعالجة أخطاء الوراثة والمنشئات وحقوق الوصول. أما مع المهارة، فاستغرق 19.8 ثانية وثلاثة استدعاءات بتكلفة 0.09 دولار؛ إذ نفذ الوكيل عملية extract_base_class، وأنشأ ExporterBase، وحدّث أربعة ملفات وأعاد كتابة 11 مرجعاً.
يمكن تجربة الوظيفة عبر تحديث Rider إلى الإصدار 2026.2.1 وفتح حل C# ثم مطالبة الوكيل بإعادة تسمية عنصر أو استخراج واجهة أو نقل نوع. وتوصي المادة بأن تكون الطلبات محددة باسم العملية، مثل طلب استخراج واجهة من OrderProcessor، بدلاً من صياغة عامة مثل «نظّف هذا الصنف».