وكيل SonarQube للإصلاح: حلقة تحقق تجعل إصلاح الشيفرة بالذكاء الاصطناعي أكثر أمانًا

وهنا يظهر الفارق عن مساعد برمجي واسع الاستخدام: الوكيل لا يبدأ من سؤال عام مثل «اكتب لي هذه الميزة»، بل من نتيجة تحليل محددة، ثم يختبر التعديل المقترح وفق معايير التحليل نفسها قبل أن يراه المطور.

من مختبرات NUS إلى منتج تجاري

تعود التقنية إلى AutoCodeRover، وهي منصة لوكيل ذكاء اصطناعي مستقل طوّرها البروفيسور أبهيك رويشودري وفريقه في مجموعة أبحاث البرمجيات الموثوقة والآمنة بجامعة سنغافورة الوطنية (NUS Computing). جمعت المنصة بين النماذج اللغوية الكبيرة وتقنيات البحث داخل الشيفرة لمعالجة مهام مثل تصحيح الأخطاء، وإصلاح المشكلات، وإعادة هيكلة البرامج.

استحوذت Sonar على التقنية المنبثقة من AutoCodeRover في فبراير 2025، ما أتاح لها دمج أبحاث إصلاح البرامج بالوكلاء مع منصتها القائمة لتحليل جودة الشيفرة وأمانها.

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

لماذا كانت سنغافورة جزءًا من القصة؟

طُوّرت الأداة واختُبرت في سنغافورة بمشاركة مهندسين من Sonar وهيئة تطوير الإعلام المعلوماتي والاتصالات السنغافورية (IMDA)، قبل طرحها عالميًا. وأعلنت Sonar إطلاق وكيل SonarQube للإصلاح عالميًا خلال قمة ATxSummit 2026 في سنغافورة، في مايو 2026.

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

ما المشكلة التي تحاول الأداة حلها؟

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

صُمم وكيل SonarQube للتعامل مع النوعين. فهو يستخدم نتائج SonarQube لاقتراح إصلاحات للشيفرة التي كتبها البشر أو الوكلاء، مع إبقاء قرار اعتماد التغيير بيد المطورين.

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

مخاطر الأمن والتشغيل: ماذا يستطيع الوكيل أن يفعل؟

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

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

وتقول Sonar إن الوكيل لا يعمل إلا على مشكلات موثَّقة اكتشفها SonarQube، وإن معدل الإيجابيات الكاذبة في المشكلات التي يتعامل معها بلغ 3.2%. وهذه النسبة مقياس أعلنته الشركة، ولذلك ينبغي قراءتها باعتبارها وصفًا لسير العمل الذي تقدمه Sonar، لا ضمانًا مستقلًا للدقة في جميع المستودعات.

الحجم والموقع في السوق

تقول Sonar إن منصتها تحلل 750 مليار سطر من الشيفرة يوميًا، وتخدم أكثر من سبعة ملايين مطور، من بينهم مؤسسات تمثل 75% من شركات Fortune 100. وهذه أرقام تعلنها الشركة عن منصتها الأوسع، وليست مقياسًا لحجم الإصلاحات التي ينفذها وكيل المعالجة وحده.

وتضع Sonar المنتج بوصفه طبقة للتحقق من الشيفرة ومعالجة مشكلاتها في بيئات التطوير المدعومة بالذكاء الاصطناعي. وهذا يميّزه عن أدوات مثل Cursor وGitHub Copilot وClaude، التي تُستخدم بصورة أوسع لتوليد الشيفرة والمساعدة البرمجية؛ إذ يبدأ وكيل Sonar من مشكلة مكتشفة ويتحقق من التعديل المقترح قبل تقديمه للمراجعة.

ماذا يعني ذلك لفرق هندسة البرمجيات؟

يمكن تلخيص الوعد الرئيسي للأداة بهذه الصيغة:

يقترح الذكاء الاصطناعي إصلاحًا لمشكلة موثَّقة، ثم يفحص نظام التحليل هذا الإصلاح قبل أن يقبله المطور.

وقبل اعتماد هذا النهج، تحتاج الفرق إلى طرح أسئلة عملية:

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

توضح رحلة AutoCodeRover من أبحاث NUS إلى منتج Sonar التجاري كيف يمكن لأبحاث إصلاح البرامج الآلي أن تنتقل إلى سير عمل يستخدمه المطورون. لكن قيمة الأداة في الواقع لن تتحدد بمجرد قدرتها على توليد الشيفرة، بل بموثوقية المشكلات التي تلتقطها، وجودة حلقة التحقق، وانضباط البشر الذين يراجعون النتيجة.