Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
यह अनुभवजन्य अध्ययन पांच एआई कोडिंग एजेंटों के 8,000 से अधिक फिक्स-संबंधित पुल रिक्वेस्ट का विश्लेषण करता है ताकि यह पहचान की जा सके कि टेस्ट केस विफलताओं और डुप्लिकेट इश्यू समाधानों के कारण मर्ज करने में मुख्य बाधाएं आती हैं, जबकि बिल्ड विफलताएं दुर्लभ हैं, जिससे वर्तमान एआई एजेंटों की प्रमुख सीमाओं और सॉफ्टवेयर रखरखाव में मानव-एआई सहयोग को सुधारने की दिशाओं पर प्रकाश पड़ता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि एक सॉफ्टवेयर प्रोजेक्ट एक विशाल, हलचल भरे निर्माण स्थल (construction site) की तरह है। यहाँ "मेंटेनर्स" (maintainers) साइट मैनेजर हैं जो तय करते हैं कि कौन से ब्लूप्रिंट बनाए जाएंगे और किन्हें कचरे में फेंक दिया जाएगा। हाल ही में, उन्होंने AI एजेंट्स (जैसे कि रोबोटिक सहायक) को काम पर रखना शुरू किया है जो टूटे हुए हिस्सों को ठीक करने के लिए मरम्मत योजनाएं (जिन्हें "पुल रिक्वेस्ट" या PR कहा जाता है) तैयार करते हैं।
यह शोध पत्र एक जासूसी रिपोर्ट की तरह है जो यह पूछ रहा है: "ये रोबोटिक सहायक वास्तव में अपनी मरम्मत योजनाओं को कितनी बार स्वीकृत (approve) करवा पाते हैं, और जब वे ऐसा नहीं कर पाते, तो क्यों?"
यहाँ उनके निष्कर्षों का विवरण दिया गया, जिसमें सरल उपमाओं (analogies) का उपयोग किया गया है:
1. बड़ी तस्वीर: सफलता की दर (The Big Picture: The Success Rate)
शोधकर्ताओं ने पांच अलग-अलग प्रकार के AI रोबोट्स (OpenAI Codex, GitHub Copilot, Devin, Cursor, और Claude Code) द्वारा प्रस्तुत की गई 8,000 से अधिक मरम्मत योजनाओं का अध्ययन किया।
- अच्छी खबर: लगभग 65% बार, साइट मैनेजरों ने कहा, "हाँ, इसे बनाओ!" और उस सुधार को लागू (merge) कर दिया। रोबोट अच्छा काम कर रहे हैं।
- बुरी खबर: लगभग 26% मामलों में, मैनेजरों ने कहा, "नहीं," और बिना निर्माण किए योजना को बंद कर दिया। एक अन्य 9% अभी भी वेटिंग रूम में बैठे हैं, यानी अभी निर्णय नहीं लिया गया है।
- रोबोटों के बीच अंतर: सभी रोबोट एक समान नहीं हैं।
- OpenAI Codex एक मेधावी छात्र है: इसे 81% बार स्वीकृति मिली।
- Devin को सबसे अधिक संघर्ष करना पड़ा: इसे केवल 43% बार स्वीकृति मिली, जिसका अर्थ है कि इसके आधे से अधिक मरम्मत प्लान खारिज कर दिए गए।
2. "क्यों": योजनाएं क्यों खारिज की जाती हैं? (The "Why": Why Do Plans Get Rejected?)
शोधकर्ताओं ने 326 खारिज की गई योजनाओं की गहराई से जांच की ताकि पता चल सके कि वे वास्तव में क्यों विफल हुईं। उन्हें 12 अलग-अलग कारण मिले, जिन्हें उन्होंने तीन मुख्य श्रेणियों में बांटा:
A. "गलत सुधार" की समस्याएँ (तकनीकी मुद्दे) [The "Wrong Fix" Problems (Technical Issues)]
कभी-कभी रोबोट रिसाव (leak) को ठीक करने की कोशिश करता है, लेकिन वास्तव में वह पाइप को ही तोड़ देता है।
- टेस्ट फेलियर (सबसे आम तकनीकी कारण): रोबट का सुधार उसके अपने तर्क (logic) में तो सही था, लेकिन वह प्रोजेक्ट के सख्त सुरक्षा परीक्षणों (safety tests) में विफल रहा। यह एक ऐसे शेफ की तरह है जो एक ऐसा भोजन बनाता है जो दिखने में तो शानदार है लेकिन स्वास्थ्य निरीक्षक (test suite) द्वारा चखने पर उसका स्वाद बहुत खराब निकलता है।
- अधूरे या गलत सुधार: रोबोट ने समस्या का अनुमान तो लगाया लेकिन गलत चीज़ को हल कर दिया, या उसने केवल आधा हिस्सा ही ठीक किया।
- बिल्ड/डिप्लॉय फेलियर: दुर्लभ मामलों में, सुधार इतना खराब था कि पूरी इमारत का निर्माण ही नहीं हो सका (वह कंपाइल या रन नहीं हो सका)।
B. "गलत समय" की समस्याएँ (प्रक्रियात्मक मुद्दे) [The "Bad Timing" Problems (Process Issues)]
कभी-कभी सुधार वास्तव में अच्छा होता है, लेकिन समय गलत होता है।
- किसी और ने पहले ही कर दिया था (#1 कारण): यह 22% मामलों में हुआ। रोबोट एक टूटी हुई खिड़की को ठीक करने के लिए कड़ी मेहनत कर रहा था, लेकिन किसी इंसान (या दूसरे रोबोट) ने पाँच मिनट पहले ही उसे ठीक कर दिया था। रोबोट की योजना केवल इसलिए खारिज कर दी गई क्योंकि वह अनावश्यक (redundant) थी।
- निष्क्रियता (Inactivity): रोबोट ने एक योजना प्रस्तुत की, लेकिन फिर वह चुप हो गया। मैनेजरों ने जवाब का इंतजार करते-करते ऊबकर टिकट बंद कर दिया।
- कम प्राथमिकता: जिस समस्या को रोबोट ठीक करने की कोशिश कर रहा था, वह अब महत्वपूर्ण नहीं रह गई थी, या प्रोजेक्ट मैनेजरों ने उसे अनदेखा करने का फैसला किया।
C. "संचार विफलता" की समस्याएँ [The "Communication Breakdown" Problems]
- कोई समीक्षा नहीं: रोबोट ने समीक्षा (review) मांगी, लेकिन किसी भी मानव मैनेजर ने उस पर कभी ध्यान नहीं दिया।
- मौन अस्वीकृति (Silent Rejection): योजना को बिना किसी स्पष्टीकरण के बंद कर दिया गया, जिससे रोबोट (और शोधकर्ता) अंधेरे में रह गए कि वह क्यों विफल हुई।
3. "गति" का कारक (The "Speed" Factor)
शोधकर्ताओं ने यह भी मापा कि एक योजना को स्वीकृत होने में कितना समय लगा।
- तेज़ विलय (Fast Merges): कई अच्छे सुधार बहुत जल्दी स्वीकृत हो गए।
- धीमा विलय (Slow Merges): कुछ में काफी समय लगा। दिलचस्प बात यह है कि "मेधावी छात्र" (OpenAI Codex) के पास सबसे सुसंगत और तेज़ स्वीकृति समय था, जबकि अन्य के प्रतीक्षा समय बहुत अनिश्चित थे।
निचोड़ (The Bottom Line)
शोध पत्र यह निष्कर्ष निकालता है कि हालांकि AI रोबोट कोड लिखने में बेहतर हो रहे हैं, लेकिन केवल कोड लिखना ही पर्याप्त नहीं है।
वास्तविक दुनिया में एक मरम्मत योजना को स्वीकृत कराने के लिए, रोबोट को निम्नलिखित की आवश्यकता है:
- सख्त सुरक्षा परीक्षणों को पास करना (सिर्फ अच्छा दिखने के लिए नहीं)।
- यह सुनिश्चित करना कि वह उस काम को दोहरा न रहा हो जो इंसानों या अन्य रोबोटों ने पहले ही कर लिया है।
- मानव प्रबंधकों के साथ बातचीत में सक्रिय रहना।
वर्तमान में, सबसे बड़ी बाधा यह नहीं है कि रोबोट कोड नहीं लिख सकते; बल्कि यह है कि वे अक्सर परीक्षणों (tests) में विफल हो जाते हैं या अन्य लोगों द्वारा उसी समस्या को ठीक करने के चक्कर में पीछे छूट जाते हैं। अध्ययन सुझाव देता है कि AI के लिए एक विश्वसनीय "आभासी टीम के साथी" बनने के लिए, उसे केवल कोड ही नहीं, बल्कि प्रोजेक्ट के संदर्भ (context) और वर्कफ़्लो के समय (timing) को समझने में भी बेहतर होना होगा।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।