Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
यह शोध पत्र AIDev डेटासेट का विश्लेषण करता है ताकि उन 14 विशिष्ट कारणों की पहचान की जा सके जिनके कारण लगभग आधे AI-जनित पुल रिक्वेस्ट (pull requests) अस्वीकार कर दिए जाते हैं, और एजेंट के प्रदर्शन, कार्य प्राथमिकता और सॉफ्टवेयर विकास वर्कफ़्लो में एकीकरण को बेहतर बनाने के लिए कार्रवाई योग्य मार्गदर्शन प्रदान करने हेतु इन विफलता मोडों को वर्गीकृत करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपने अपने सॉफ़्टवेयर के बग्स (bugs) ठीक करने के लिए सुपर-फास्ट, अत्यधिक उत्साही रोबोट इंटर्न की एक टीम को काम पर रखा है। आप उन्हें एक समस्या देते हैं और वे तुरंत कोड टाइप करना शुरू कर देते हैं, एक "पुल रिक्वेस्ट" (Pull Request) बनाते हैं (जो कोड में बदलाव का एक प्रस्ताव है)।
यह पेपर मूल रूप से एक रिपोर्ट कार्ड है कि क्या होता है जब ये रोबोट इंटर्न (विशेष रूप से Copilot, Devin, Cursor, और Claude) चीज़ों को ठीक करने की कोशिश करते हैं। शोधकर्ताओं ने पाया कि एक चौंकाने वाला आंकड़ा यह है: लगभग आधी बार (46.41%), मानव बॉस रोबोट के काम को कचरे के डिब्बे में फेंक देता है।
यहाँ बताया गया है कि ऐसा क्यों होता है, सरल उपमाओं (analogies) का उपयोग करते हुए:
बड़ी समस्या: "बर्बाद प्रयास" का बिल
हर बार जब एक रोबोट द्वारा दिया गया समाधान खारिज कर दिया जाता है, तो यह दोहरा नुकसान होता है। पहले, रोबोट अपनी खुद की "दिमागी शक्ति" (कंप्यूटिंग संसाधन और टोकन) बर्बाद करता है। दूसरा, और अधिक महत्वपूर्ण बात यह है कि, एक इंसान को अपना काम रोकना पड़ता है, रोबोट के बिखरे हुए काम को पढ़ना पड़ता है, यह समझना पड़ता है कि वह गलत है, और यह समझाने के लिए एक टिप्पणी (comment) लिखनी पड़ती है कि वह क्यों गलत है। यह मानव समय की बर्बादी है।
शोधकर्ताओं ने इन खारिज किए गए प्रस्तावों के 306 मामलों का अध्ययन किया ताकि यह पता लगाया जा सके कि इंसानों ने "ना" क्यों कहा। उन्होंने पाया कि अस्वीकृति के चार मुख्य कारण थे:
1. "काम के लिए गलत औज़ार" (इम्प्लीमेंटेशन संबंधी मुद्दे)
कभी-कभी रोबोट समस्या को ठीक करने की कोशिश करता है, लेकिन वह गलत दृष्टिकोण अपनाता है।
- उपमा: कल्पना करें कि आपकी कार स्टार्ट नहीं हो रही है। आप एक मैकेनिक को इसे ठीक करने के लिए कहते हैं। वह आता है और इंजन के बजाय रेडियो को ठीक करने की कोशिश करता है, या वह रेंच (wrench) के बजाय हथौड़े से इंजन को ठीक करने की कोशिश करता है।
- क्या हुआ: रोबोट अक्सर निर्देशों को गलत समझ लेते थे, गलत चीज़ को ठीक कर रहे थे, या ऐसा समाधान प्रस्तावित कर रहे थे जो तकनीकी रूप से असंभव या अधूरा था।
2. "टूटा हुआ टेस्ट" (तकनीकी मुद्दे)
सॉफ्टवेयर में, किसी सुधार को स्वीकार किए जाने से पहले, उसे स्वचालित परीक्षणों (automated tests) की एक श्रृंखला से गुजरना पड़ता है (जैसे कि सुरक्षा निरीक्षण)।
- उपमा: रोबोट एक नया पुल बनाता है, लेकिन जब इंस्पेक्टर उस पर ट्रक चलाता है, तो पुल ढह जाता है। रोबोट ने यह जांचा ही नहीं कि क्या उसका अपना पुल भार सह सकता है।
- क्या हुआ: रोबोट द्वारा लिखे गए कोड अक्सर स्वचालित "सुरक्षा परीक्षणों" (CI pipelines) में विफल रहे या सॉफ़्टवेयर के उन अन्य हिस्सों को तोड़ दिया जो पहले से ही काम कर रहे थे।
3. "दिखाई न देने वाला इंटर्न" (प्रोवाइडर संबंधी मुद्दे)
कभी-कभी रोबोट बस काम करना बंद कर देता है या बीच में ही कट जाता है।
- उपमा: आप इंटर्न को एक रिपोर्ट लिखने के लिए कहते हैं, लेकिन काम के बीच में ही, इंटर्न इमारत से बाहर चला जाता है, या इंटरनेट कनेक्शन कट जाता है, जिससे आपके पास एक खाली पन्ना रह जाता है।
- क्या हुआ: AI सेवा स्वयं क्रैश हो गई, रोबोट "रेट-लिमिटेड" (rate-limited) हो गया (अनुरोधों की अनुमति समाप्त हो गई), या सत्र (session) काम पूरा करने से पहले ही समाप्त हो गया।
4. "बेकार सुधार" (प्रासंगिकता संबंधी मुद्दे)
कभी-कभी रोबोट ऐसी समस्या पर काम कर रहा होता है जो अब मायने नहीं रखती।
- उपमा: आप इंटर्न को किचन में लीकेज ठीक करने के लिए कहते हैं। जब तक इंटर्न मरम्मत पूरी करता है, तब तक किचन का नवीनीकरण हो चुका होता है, और लीकेज खत्म हो चुका होता है, या किसी और ने बेहतर तरीके से इसे पहले ही ठीक कर दिया होता है।
- क्या हुआ: रोबोट जिस समस्या को ठीक कर रहा था, वह कम प्राथमिकता वाली थी, समस्या पहले ही हल की जा चुकी थी, या रोबोट इतने लंबे समय तक निष्क्रिय रहा कि प्रोजेक्ट बिना उसके ही आगे बढ़ गया।
गलती की "लागत"
पेपर ने यह भी मापा कि अस्वीकार होने से पहले रोबोटों ने कितनी "गड़बड़ी" की।
- कोड चर्न (Code Churn): यह कहने का एक फैंसी तरीका है कि "कितना कोड लिखा गया और फिर डिलीट कर दिया गया।" शोधकर्ताओं ने पाया कि खारिज किए गए सुधारों में औसतन 81 से 293 लाइनों का कोड शामिल था। गलती करने के लिए यह बहुत सारा टाइपिंग कार्य है!
- कमेंट्स (Comments): इंसानों को यह समझाने के लिए औसतन 1 से 4.5 कमेंट्स लिखने पड़े कि सुधार क्यों खराब था। चूंकि लगभग आधे रोबोट सुधार खारिज कर दिए जाते हैं, इसका मतलब है कि इन रोबोटों को लिखे गए सभी मानव कमेंट्स में से आधे केवल यह कहने के लिए हैं कि, "नहीं, यह काम नहीं करता।"
निष्कर्ष: इंटर्नों को बेहतर तरीके से कैसे प्रशिक्षित करें
लेखकों का सुझाव है कि समय बचाने के लिए, इंसानों को काम शुरू करने से पहले रोबोटों को बेहतर निर्देश देने की आवश्यकता है। विशेष रूप से:
- एक नक्शा दें: रोबोट को ठीक-ठीक बताएं कि समस्या को कैसे ठीक करना है और क्या नहीं करना है।
- टेस्ट सेटअप करें: रोबोट को बताएं कि वह अपने काम की जांच कैसे करे ताकि वह बॉस को दिखाने से पहले सुरक्षा परीक्षणों को पास कर सके।
- सही काम चुनें: रोबोट को ऐसे छोटे, महत्वहीन बग्स ठीक करने के लिए न कहें जिन्हें मानव समीक्षा के समय के लायक नहीं माना जाता।
संक्षेप में: AI एजेंट शक्तिशाली हैं, लेकिन अभी वे उत्साही इंटर्न की तरह हैं जिन्हें समय और ऊर्जा बर्बाद करने से बचने के लिए बहुत स्पष्ट, विशिष्ट निर्देशों की आवश्यकता होती है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।