ما المقصود باكتشاف الأخطاء وإصلاحها بالذكاء الاصطناعي؟

في 9 سبتمبر 1947، وجد مهندسو كمبيوتر Harvard Mark II فراشة في أحد مرحلاته ولصقوها في سجلهم مع عبارة—"أول حالة فعلية للعثور على خطأ برمجي"—وهي صفحة موجودة الآن في Smithsonian.¹ روجت عالمة الحاسوب Grace Hopper من فريق Mark II هذه القصة، رغم أن مصطلح الأخطاء البرمجية انتشر قبلها: فقد اشتكى Thomas Edison من وجود "أخطاء (حشرات)" في رسالة تعود لعام 1878، ويرجع قاموس Oxford الإنجليزي هذا الاستخدام الهندسي إلى سبعينيات وثمانينيات القرن التاسع عشر.²

تأتي الأخطاء الهندسية عادةً في ثلاثة أنواع.³ أخطاء بناء الجملة، وتتمثل في كسر قواعد لغة البرمجة (على سبيل المثال، قد يكون هناك قوس مفقود) ويُكتشف قبل تشغيل البرنامج. أخطاء التشغيل، وتحدث عندما تفشل التعليمات البرمجية الصحيحة في أثناء التشغيل، مثل القسمة على الصفر. الأخطاء المنطقية، وهي الأكثر خبثًا: يعمل البرنامج من دون أي مشكلة ولكنه يعطي إجابات خاطئة.

يمكن للمطورين التصدي لهذه الأخطاء من خلال الاختبارات الآلية—اختبارات الوحدة التي تتحقق من كل جزء صغير من التعليمات البرمجية مقابل النتائج المتوقعة—وباستخدام أدوات تصحيح الأخطاء، التي توقف البرنامج قيد التشغيل مؤقتًا للفحص. تتيح نقطة التوقف—وهي سطر مميز يتوقف عنده التنفيذ—للمطور تتبع البرنامج خطوة بخطوة، وفحص المتغيرات؛ وتُعد أداة PDB المدمجة في Python مثالاً نموذجيًا على ذلك. عادةً ما ينتج عن التعطل التام سجل تتبع المجموعة التقنية—وهو تقرير عن استدعاءات الدوال التي أدت إلى الخطأ.⁴

قدرت دراسة أجرتها كلية Cambridge Judge Business School عام 2013 أن المطورين يقضون في المتوسط نصف وقت برمجتهم في العثور على الأخطاء وإصلاحها، بتكلفة تقارب 312 مليار دولار سنويًا على مستوى العالم.⁵ ويَعد استكشاف الأخطاء وإصلاحها بمساعدة الذكاء الاصطناعي، بالطبع، بتقليل تلك التكلفة.

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

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

في سير عمل شائع لاستكشاف الأخطاء وإصلاحها بالذكاء الاصطناعي، يعطي المطور النموذج التعليمات البرمجية ذات الصلة ورسالة الخطأ أو سجل تتبع المجموعة التقنية؛ ثم يشرح النموذج السبب المحتمل ويقترح الإصلاحات المرشحة. تذهب أنظمة البحث مثل ChatDBG أبعد من ذلك، حيث تربط النماذج اللغوية الكبرى بأدوات تصحيح الأخطاء القياسية مثل GDB وLLDB وpdb الخاصة بلغة Python حتى يتمكن المطور من طرح أسئلة بلغة بسيطة—"لماذا x فارغ؟"—بينما يفحص النموذج البرنامج النشط، ويجري تحليلاً للسبب الأساسي، ويقترح الإصلاحات.6.

توجد بعض القيود التي يجب أن يكون المبتدئون في مجال استكشاف الأخطاء وإصلاحها بالذكاء الاصطناعي على دراية بها. أولاً، السياق مهم—وهي ممارسة مرتبطة بهندسة التوجيه. من المرجح أن تؤدي التوجيهات الغامضة إلى تشخيصات غامضة؛ والنهج الأكثر فائدة هو تقديم الخطأ الدقيق والاختبار الفاشل وجزء من التعليمات البرمجية المشتبه فيها. يحتاج المستخدمون أيضًا إلى معرفة حجم نافذة السياق الخاصة بالنموذج: الحد الأقصى لكمية النص (المقيسة "بالرموز"، أو أجزاء من عدة أحرف لكل منها) التي يمكن للنموذج معالجتها دفعة واحدة. وغالبًا ما تمتد الأخطاء الحقيقية في قواعد التعليمات البرمجية المعقدة عبر ملفات متعددة، كما يُظهر معيار SWE-bench لمشكلات GitHub الحقيقية، وقد يواجه النموذج الذي يعجز عن استيعاب جميع التعليمات البرمجية ذات الصلة في سياقه صعوبة في الاستدلال عليها.

عادةً ما يحدث استكشاف الأخطاء وإصلاحها بالذكاء الاصطناعي من خلال مساعدي البرمجة بالذكاء اصطناعي المدمجين في، أو المبنيين حول، مساحة عمل البرمجة الخاصة بالمطور—وغالبًا ما تكون بيئة تطوير متكاملة (أو IDE). على سبيل المثال، GitHub Copilot هو مساعد برمجة يمكنه اقتراح التعليمات البرمجية داخل بيئات التطوير المتكاملة الشهيرة؛ بينما تُعد Cursor وWindsurf مساحتي عمل برمجيتين موجهتين بالذكاء الاصطناعي تضعان مساعدة مماثلة في صميم تجربة البرمجة.⁷ ومع ازدياد شيوع "الهندسة القائمة على الوكلاء"، تُصمَّم بعض البرمجيات بحيث تكون نافذة دردشة مساعد البرمجة هي اللوحة الأساسية التي يتفاعل فيها المستخدم البشري مع بيئة التطوير المتكاملة (IDE)؛ وتُعد هذه إحدى الطرق لاستخدام IBM Bob، من بين طرق أخرى.

غالبًا ما يكون مساعدو البرمجة غير مرتبطين بنموذج معين؛ فعلى سبيل المثال، يمكن أن يستخدم GitHub Copilot نماذج من مزودين مثل OpenAI وAnthropic وGoogle؛ كما وصفت شركة xAI نموذجها Grok Code Fast 1 بأنه مصمم لسير عمل وكلاء البرمجة ومتوفر من خلال أدوات مثل Copilot وCursor وWindsurf. ^{8 9} ومن جانبه، يستخدم IBM Bob نماذج متنوعة، حيث يوجه الاستعلامات تلقائيًا إلى النموذج المناسب بناءً على التعقيد والتكلفة؛ تشير مستندات إصدار عام 2026 إلى "مزيج من النماذج الرائدة بما في ذلك Anthropic Claude، ونماذج Mistral مفتوحة المصدر، وIBM Granite، إلى جانب نماذج متخصصة مضبوطة بدقة للاستدلال على التعليمات البرمجية، والأمان، والتنبؤ بالتعديل التالي."

بعض وكلاء استكشاف الأخطاء وإصلاحها بالذكاء الاصطناعي هم وكلاء عامون؛ وهناك آخرون متخصصون. على الجانب العام، يمكن تكليف وكيل البرمجة Copilot في GitHub، الذي طُرح في عام 2025، بحل مشكلة على GitHub، والعمل في الخلفية باستخدام GitHub Actions، وإرسال التغييرات المقترحة كطلب سحب (وهو حزمة من تغييرات التعليمات البرمجية ليراجعها المطور البشري).¹⁰ وبفضل مزيج نماذجها، يميل IBM Bob أيضًا إلى أن يكون عامًا. وعلى الجانب المتخصص، هناك Copilot Autofix، الذي يستهدف تحديدًا الثغرات الأمنية. ويفعل ذلك من خلال دمج CodeQL، محرك فحص التعليمات البرمجية في GitHub، مع الشروحات المولدة بالذكاء الاصطناعي والإصلاحات المقترحة. توفير الوقت يمكن أن يكون مذهلاً؛ يسجل GitHub متوسط وقت إصلاح يبلغ 28 دقيقة مقابل ساعة ونصف بالطريقة اليدوية.¹¹

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

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

ومع ذلك، فإن الأدوات الأفضل والأكثر تخصصًا تعمل على تحسين التوقعات. على سبيل المثال، يربط ChatDBG نموذجًا لغويًا كبيرًا بأدوات تصحيح أخطاء مباشرة، ما يمنحه رؤية لما كان يفعله البرنامج بالضبط عندما فشل (بدلاً من الاقتصار على نص التعليمات البرمجية المشتبه فيها فقط). في أحد التقييمات، أنتج استعلام ChatDBG واحد إصلاحًا قابلاً للتنفيذ لبرامج Python بنسبة 67% من الوقت؛ وبعد أن سمح بسؤال متابعة واحد فقط، ارتفعت النسبة إلى 85%.¹³

وما يزيد الأمر تعقيدًا، أن المعايير التي يُجرى من خلالها تقييم النماذج تتغير باستمرار. يُعد معيار SWE-bench Pro خليفةً أكثر صعوبةً لمعيار SWE-bench¹⁴ الشهير، وقد صُمم ليكون أكثر واقعيةً ومقاومةً للأخطاء؛ وفي تقييم حديث، لم تتجاوز أفضل النماذج الرائدة نسبة 25%، حيث سجل نموذج GPT-5 نسبة 23.3%.¹⁵  

قد يتغير سلوك المطور بشكل أسرع مما يمكن قياسه علميًا. أظهرت تجربة عشوائية أجرتها مؤسسة METR في مطلع عام 2025 أن مطوري البرمجيات مفتوحة المصدر ذوي الخبرة استغرقوا وقتًا أطول بنسبة 19% عند استخدام أدوات الذكاء الاصطناعي، إلا أن المؤسسة سرعان ما اعتبرت هذه النتائج قديمة. وفي دراسة لاحقة أُجريت عام 2026، وُجدت بعض الأدلة على تسارع الإنتاجية، مع الإشارة إلى صعوبة قياس هذا التسارع بدقة.¹⁶ ويُعد تفسير METR لهذه الصعوبة وافيًا: "لقد لاحظنا زيادة ملحوظة في عدد المطورين الذين اختاروا عدم المشاركة في الدراسة لأنهم لا يرغبون في العمل من دون الذكاء الاصطناعي، وهو ما قد يقلل من تقديرنا لتسارع الإنتاجية الناتج عن الذكاء الاصطناعي". 

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