تختبر Cursor وMicrosoft Research ما إذا كانت وكلاء الذكاء الاصطناعي بحاجة إلى وصول كامل إلى منقح الأخطاء

وكيل الذكاء الاصطناعي لإصلاح الأخطاء لا يكتفي بقراءة الكود وجمع السجلات: عندما يحصل على إمكانية الوصول إلى أداة تصحيح حقيقية، يبدأ في التصرف بطريقة أقرب إلى مطور حي ويفهم بشكل أفضل كثيراً مكان انقطاع البرنامج بالضبط. في نهاية عام 2025، أطلقت Cursor وضع Debug Mode — وضع يمكن فيه للوكيل جمع السجلات مباشرة من وقت التشغيل واستخدامها كمصدر سياق إضافي. للتصحيح العملي، هذه خطوة مهمة: بدلاً من التخمين من آثار المكدس، يرى النموذج ما يحدث أثناء التنفيذ، وأي القيم تمر عبر الدوال وفي أي نقطة يتصرف النظام بشكل غير متوقع.

أثبتت هذه الطريقة أنها بديهية للمطورين أيضاً: من خلال رد فعل المجتمع، أصبح واضحاً أن الفكرة تُدرك ليس كوضع تسويقي آخر، بل كأداة مفيدة حقاً للعمل اليومي مع الأخطاء. لكن تسجيل السجلات ليس الطريقة الوحيدة لتقريب الذكاء الاصطناعي من الممارسة الهندسية العادية. السؤال التالي يبدو أكثر مباشرة: إذا كان الوكيل يعيش بالفعل بجانب بيئة التطوير، لماذا لا نعطيه نفس الأدوات التي يستخدمها البشر؟ نحن نتحدث عن نقاط التوقف، والتنفيذ خطوة بخطوة، ومشاهدة حالة البرنامج وتقييم التعبير في السطر الصحيح.

هذا بالضبط ما اختبره الباحثون في مختبر أبحاث مايكروسوفت في إطار عمل تجريبي يسمى Debug2Fix. في إعدادهم، تلقى وكيل فرعي منفصل أدوات للتفاعل مع أداة التصحيح وعلى مهام من GitBug-Java و SWE-Bench-Live تعامل مع الأخطاء بنسبة أفضل حوالي 20% من وكيل عادي بدون مثل هذا الوصول. هذا ليس تحسناً سطحياً: لمهام إصلاح الكود التلقائي، هذا الفرق يغير بالفعل القيمة العملية للأداة.

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

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

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

هذا فرق مهم عن النهج الذي يعتمد فيه النموذج بشكل أساسي على تسجيل السجلات والعلامات غير المباشرة للمشكلة. الأكثر إثارة للاهتمام في هذه القصة ليس فقط تحسن الجودة على المعايير، بل السؤال نفسه: ما الأفضل لمطور الذكاء الاصطناعي في المستقبل — الوصول الجيد إلى سجلات وقت التشغيل أم «أيدٍ» حقيقية داخل أداة التصحيح؟ لا توجد إجابة كاملة في تجربة واحدة حتى الآن، لكن من الواضح بالفعل أن السوق يتحرك في اتجاهين في نفس الوقت. يراهن أحد المسارات على ملاحظة جودة عالية لتنفيذ البرنامج، والآخر — على التدخل النشط في عملية التصحيح.

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