Skip to main content

لماذا تُرفض طلبات الدمج التي يكتبها وكلاء البرمجة؟ دراسة على 33 ألف طلب في GitHub

Updated 2 min readMarkdown

بدأت وكلاء البرمجة المدعومة بالذكاء الاصطناعي بإرسال طلبات دمج (Pull Requests) إلى مشاريع البرمجيات، وتعمل كمساهمين مستقلين لا كمساعدين فقط. تدرس ورقة بعنوان "Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub" (arXiv 2601.15195، لمؤلفيها Ramtin Ehsani وSakshi Pathak وShriya Rawal وAbdullah Al Mujahid وMia Mohammad Imran وPreetha Chatterjee، ومقبولة في مؤتمر MSR 2026) سبب رفض كثير من هذه الطلبات.

ما الذي درسه الباحثون

حلل الفريق نحو 33 ألف طلب دمج كتبها خمسة وكلاء برمجة على GitHub. بحسب الورقة، لا يُعرف الكثير عن سلوك هذه المساهمات في المستودعات الحقيقية ولا عن سبب عدم دمج كثير منها.

النتائج الكمية

قارن الباحثون بين الطلبات المدموجة وغير المدموجة من أربع جهات: نتيجة الدمج حسب نوع المهمة، والتغييرات في الشيفرة، ونتائج بناء التكامل المستمر (CI)، وديناميكيات المراجعة. وكانت النتائج:

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

أسباب الرفض

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

ما يمكن أن تتعلمه الفرق التي تبني وكلاء

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

كتب هذا المقال Yethikrishna R، مؤسس Mynd Labs ومهندسها الرئيسي، ومنسّق وعضو مؤسس في Compyle (YC F25). يبني أنظمة وكلاء الذكاء الاصطناعي وأدوات المطورين من مدينة ثريشور في الهند.

المصدر: Ehsani et al., "Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub", https://arxiv.org/abs/2601.15195

No comments yet. Be the first to comment.

More from this blog