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

لم يعد يكفي وكيلَ الذكاء الاصطناعي المخصص لإصلاح الأخطاء أن يقرأ الشيفرة ويجمع السجلات. فحين يحصل على وصول إلى مصحّح أخطاء حقيقي، يبدأ بالعمل بأسلوب أقرب إلى المطور البشري، ويفهم بدقة أكبر بكثير أين ينكسر البرنامج بالتحديد. في أواخر عام 2025 أطلقت Cursor وضع Debug Mode، وهو وضع يستطيع فيه الوكيل جمع السجلات مباشرة من بيئة التشغيل (runtime) واستخدامها مصدراً إضافياً للسياق.

وهذه خطوة مهمة للتصحيح العملي: فبدلاً من التخمين اعتماداً على تتبّع المكدس (stacktrace)، يرى النموذج ما يحدث لحظة التنفيذ، وما القيم التي تمر عبر الدوال، وفي أي نقطة يسلك النظام سلوكاً مغايراً للمتوقع. وبدا هذا النهج بديهياً للمطورين أيضاً: فمن خلال ردود فعل المجتمع اتضح أن الفكرة لا تُفهم على أنها مجرد وضع تسويقي آخر، بل أداة مفيدة فعلاً في العمل اليومي مع الأخطاء.

لكن تسجيل الأحداث ليس الطريقة الوحيدة لتقريب الذكاء الاصطناعي من الممارسة الهندسية السليمة. والسؤال التالي أكثر مباشرة: إذا كان الوكيل يعمل أصلاً إلى جانب بيئة التطوير المتكاملة (IDE)، فلماذا لا نمنحه الأدوات نفسها التي يستخدمها الإنسان؟ والمقصود نقاط التوقف (breakpoints)، والتنفيذ خطوة بخطوة، وفحص حالة البرنامج، وتقييم التعبيرات (evaluate expression) في السطر المطلوب. وهذا بالضبط ما اختبره باحثو Microsoft Research في إطار العمل التجريبي Debug2Fix. ففي تجربتهم حصل وكيل فرعي مستقل على أدوات للتفاعل مع المصحّح، وتعامل في مهام من GitBug-Java وSWE-Bench-Live مع الأخطاء بكفاءة أفضل بنحو 20% من وكيل عادي لا يملك هذا الوصول. وهذا ليس تحسيناً شكلياً: ففي مهام الإصلاح الآلي للشيفرة، يغيّر فرق كهذا القيمة العملية للأداة.

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

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

والأكثر إثارة في هذه القصة ليس تحسن الجودة في الاختبارات المعيارية (benchmarks) فحسب، بل طرح السؤال نفسه: ما الأنفع لمطوّر الذكاء الاصطناعي في المستقبل، وصول جيد إلى سجلات بيئة التشغيل أم «أيدٍ» حقيقية داخل المصحّح؟ لا توجد إجابة كاملة في تجربة واحدة حتى الآن، لكن يتضح أن السوق يتحرك في اتجاهين في آن واحد. أحد المسارين يراهن على جودة مراقبة تنفيذ البرنامج، والآخر على التدخل النشط في عملية التصحيح. وإذا أكد المسار الثاني تفوقه على عدد أكبر من الحالات الواقعية، فستتوقف مساعدات البرمجة بالذكاء الاصطناعي (AI coding assistants) سريعاً عن كونها مجرد أدوات إكمال تلقائي ذكية، وستتحول إلى شركاء متكاملين لا يكتفون بكتابة الشيفرة، بل يتتبعون جذر الخطأ بمنهجية حتى يصلوا إليه.