All Smoke, No Alarm: Oracle Signals in Agent-Authored Test Code
एजेंट-लिखित 86,000 से अधिक टेस्ट पैच का यह अनुभवजन्य अध्ययन प्रकट करता है कि जबकि 80.2% में सार्थक सत्यापन तर्क (verification logic) का अभाव है, मजबूत ओरकल संकेतों (oracle signals) की उपस्थिति किसी पुल रिक्वेस्ट के मर्ज होने की संभावना को काफी बढ़ा देती है, जो यह सुझाव देता है कि अभ्यासकर्ताओं को सरल टेस्ट-फ़ाइल गणनाओं से आगे बढ़कर ओरकल-जागरूक गुणवत्ता जांच अपनाने चाहिए।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपने एक घर बनाने के लिए सुपर-फास्ट, AI-संचालित निर्माण श्रमिकों की एक टीम को काम पर रखा है। आपने उनसे न केवल कमरे बनाने के लिए कहा, बल्कि हर नया कमरा जोड़ने के साथ एक "सुरक्षा निरीक्षण रिपोर्ट" (safety inspection report) लिखने के लिए भी कहा।
यह पेपर एक ऐसे गुणवत्ता निरीक्षक (quality inspector) की तरह है जो इन AI-जनरेटेड सुरक्षा रिपोर्टों के हजारों नमूनों की जांच करता है ताकि यह देख सके कि क्या वे वास्तव में अपना काम करती हैं या नहीं। उन्होंने यहाँ क्या पाया, इसे सरल शब्दों में नीचे दिया गया है:
समस्या: "सिर्फ धुआं, कोई अलार्म नहीं"
इस पेपर का शीर्षक एक मुहावरे "धुआं है, पर आग नहीं" (all smoke, no fire) का रूपांतरण है। इस मामले में, यह है "All Smoke, No Alarm" (सिर्फ धुआं, कोई अलार्म नहीं)।
जब आप एक पुल रिक्वेस्ट (एक सॉफ्टवेयर प्रोजेक्ट में नया कोड जोड़ने का अनुरोध) देखते हैं, तो वह अक्सर एकदम सही दिखता है। AI ने एक टेस्ट फ़ाइल लिखी है। कंप्यूटर कहता है, "ग्रीन लाइट! सभी टेस्ट पास हो गए!"
लेकिन शोधकर्ताओं ने पाया कि इनमें से कई "टेस्ट" एक ऐसे स्मोक डिटेक्टर की तरह हैं जिसका प्लग निकाल दिया गया हो। AI ऐसा कोड लिखता है जो एक टेस्ट जैसा दिखता है, लेकिन वह वास्तव में कभी यह जांच ही नहीं करता कि परिणाम सही है या नहीं।
- असली टेस्ट: "मैंने एक केक बनाया। क्या इसका स्वाद चॉकलेट जैसा है? हाँ/नहीं।"
- AI का नकली टेस्ट: "मैंने एक केक बनाया। मैंने सुनिश्चित किया कि ओवन चालू था। केक मौजूद है।"
AI पुष्टि करता है कि केक मौजूद है (कोड रन हुआ), लेकिन वह कभी यह जांच ही नहीं करता कि केक खाने योग्य है या नहीं (आउटपुट सही है या नहीं)। शोधकर्ता इसे "टेस्ट थिएटर" (Test Theater) कहते हैं—यह एक प्रदर्शन की तरह दिखता है, लेकिन वास्तव में कोई वास्तविक सत्यापन (verification) नहीं हो रहा होता।
जांच: "ओरैकल्स" (Oracles) की गिनती
सॉफ्टवेयर टेस्टिंग में, टेस्ट का वह हिस्सा जो यह बताता है कि "क्या यह सही है?" उसे टेस्ट ओरकल (Test Oracle) कहा जाता है। शोधकर्ताओं ने पांच अलग-अलग AI एजेंटों (जैसे GitHub Copilot, Devin, और Claude Code) द्वारा लिखे गए 86,000 से अधिक टेस्ट फ़ाइलों का अध्ययन किया।
उन्होंने यह देखने के लिए एक "ग्रेडिंग सिस्टम" बनाया कि AI के "सुरक्षा चेक" कितने अच्छे थे:
- कमजोर संकेत (Weak Signals - "नकली" अलार्म): AI केवल यह जांचता है कि कोड चला या नहीं, क्या कोई फ़ाइल मौजूद है, या क्या कोई फंक्शन कॉल हुआ। यह परिणाम की जांच नहीं करता।
- मजबूत संकेत (Strong Signals - "असली" अलार्म): AI वास्तव में परिणाम की तुलना एक विशिष्ट अपेक्षित मान (expected value) से करता है (जैसे, "योग 5 है, 6 नहीं")।
बड़ा खुलासा:
AI द्वारा लिखी गई सभी टेस्ट फ़ाइलों में से 80.2% "कमजोर" थीं। वे ज्यादातर केवल यह जांच रहे थे कि कोड चला या नहीं, न कि यह कि क्या वह सही ढंग से काम कर रहा था। केवल 5 में से लगभग 1 टेस्ट में वास्तव में एक मजबूत, सार्थक जांच मौजूद थी।
चौंकाने वाला मोड़: क्या "नकली" टेस्टिंग स्वीकार की जाती है?
आप सोच सकते हैं, "अगर AI खराब टेस्ट लिखता है, तो निश्चित रूप से इंसान उन कोड बदलावों को खारिज कर देंगे, है ना?"
वास्तव में, शुरुआत में इसके विपरीत हुआ।
- कमजोर टेस्ट वाले पुल रिक्वेस्ट 72.6% बार मर्ज (स्वीकार) किए गए।
- मजबूत टेस्ट वाले पुल रिक्वेस्ट केवल 59.7% बार मर्ज किए गए।
क्यों? क्योंकि जब AI मजबूत टेस्ट लिख रहा था, तब उससे अधिक कठिन और जटिल काम करने के लिए कहा जा रहा था। वे अनुरोध बड़े थे, उनमें अधिक कोड था, और वे अधिक लोकप्रिय प्रोजेक्ट्स में थे। वे स्वाभाविक रूप से कठिन थे और उन्हें अप्रूव कराना मुश्किल था।
असली कहानी:
जब शोधकर्ताओं ने गणित का उपयोग करके "मैदान को बराबर" (apples to apples की तुलना करने के लिए, यानी प्रोजेक्ट के आकार और लोकप्रियता को नजरअंदाज करके) किया, तो उन्हें एक छिपा हुआ सच मिला:
मजबूत टेस्टों ने वास्तव में कोड को स्वीकार कराने में मदद की।
एक बार जब उन्होंने कार्य की कठिनाई को ध्यान में रखा, तो एक वास्तविक, काम करने वाले सुरक्षा चेक के होने से AI का काम मानव समीक्षकों द्वारा स्वीकृत होने की संभावना 28% बढ़ गई।
निष्कर्ष (The Takeaway)
पेपर यह निष्कर्ष निकालता है कि केवल AI द्वारा लिखे गए टेस्ट फ़ाइलों की संख्या गिनना गुणवत्ता मापने का एक बुरा तरीका है। यह एक शेफ का मूल्यांकन केवल इस आधार पर करने जैसा है कि उसने कितनी रेसिपी लिखीं, बिना खाना चखे।
- भ्रम (The Illusion): AI बहुत सारी टेस्ट फ़ाइलें लिखता है, इसलिए सब कुछ सुरक्षित दिखता है।
- वास्तविकता (The Reality): अधिकांश फ़ाइलें खाली खोल (empty shells) हैं जो वास्तव में किसी भी चीज़ को सत्यापित नहीं करती हैं।
- समाधान (The Solution): इंसानों और टूल्स को गहराई से देखने की जरूरत है। उन्हें यह जांचने की जरूरत है कि "सुरक्षा अलार्म" वास्तव में "धुएं" से जुड़ा है या नहीं, न कि केवल मेज पर रखा हुआ है।
शोधकर्ता सुझाव देते हैं कि हमें ऐसे नए टूल्स की आवश्यकता है जो इन "खाली" टेस्टों को पहचान सकें और उन्हें फ्लैग कर सकें, ताकि हम अनजाने में अपने सॉफ़्टवेयर में खराब कोड को सिर्फ इसलिए शामिल न कर लें क्योंकि वह एक शानदार दिखने वाले (लेकिन बेकार) टेस्ट फ़ाइल के साथ आया है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।