TDAD: Test-Driven Agentic Development - Reducing Code Regressions in AI Coding Agents via Graph-Based Impact Analysis
यह शोध पत्र TDAD को प्रस्तुत करता है, जो एक ओपन-सोर्स टूल है जो ग्राफ-आधारित प्रभाव विश्लेषण (graph-based impact analysis) का लाभ उठाकर AI कोडिंग एजेंटों को लक्षित परीक्षण संदर्भ (targeted test context) प्रदान करता है, जो बेसलाइन दृष्टिकोणों और प्रक्रियात्मक TDD निर्देशों दोनों की तुलना में कोड रिग्रेशन को काफी कम करता है और समस्या-समाधान दरों में सुधार करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपने अपने घर में एक लीकेज (रिसाव) ठीक करने के लिए एक बहुत ही प्रतिभाशाली, लेकिन थोड़े लापरवाह रोबोटिक सहायक को काम पर रखा है। आपका रोबोट लीकेज खोजने और उसे पैच करने (समस्या सुलझाने) में बहुत माहिर है। हालाँकि, क्योंकि रोबोट पूरी तरह से यह नहीं समझ पाता कि पाइप घर के बाकी हिस्सों से कैसे जुड़े हैं, इसलिए बाथरूम को ठीक करते समय वह अक्सर किचन का एक पाइप अनजाने में फोड़ देता है।
सॉफ्टवेयर की दुनिया में, इसे रिग्रेशन (regression) कहा जाता है। रोबोट उस बग को ठीक कर देता है जिसे आपने ठीक करने के लिए कहा था, लेकिन इस प्रक्रिया में वह कुछ और चीज़ें तोड़ देता है जो पहले ठीक काम कर रही थीं।
यह पेपर TDAD (टेस्ट-ड्रिवन एजेंटिक डेवलपमेंट) नामक एक नए टूल के बारे में बताता है जो इन दुर्घटनाओं को रोकने के लिए बनाया गया है। यह कैसे काम करता है, इसकी कहानी यहाँ सरल भाषा में दी गई है।
समस्या: "सब कुछ ठीक करने वाला" रोबोट
वर्तमान में, AI कोडिंग एजेंट उसी रोबोट की तरह हैं। हम उनकी सफलता को इस सवाल से मापते हैं: "क्या उन्होंने बग ठीक किया?" यदि हाँ, तो हम उन्हें एक गोल्ड स्टार देते हैं। हम शायद ही कभी पूछते हैं: "क्या उन्होंने इसके अलावा कुछ और तो नहीं तोड़ दिया?"
लेखकों ने पाया कि ये AI एजेंट वास्तव में बग्स को ठीक करने में काफी अच्छे हैं, लेकिन वे यह जानने में बहुत खराब हैं कि किसे नहीं छूना है। जब वे किसी समस्या को ठीक करने की कोशिश करते हैं, तो वे अक्सर प्रक्रिया के दौरान 6 या 7 अन्य चीज़ें तोड़ देते हैं। यही कारण है कि कई AI फिक्स वास्तविक कंपनियों में मानव बॉस द्वारा अस्वीकार कर दिए जाते हैं।
पुराना तरीका: "बस सावधान रहें!"
शोधकर्ताओं ने पहले एक सामान्य-समझ वाले दृष्टिकोण को आज़माया। उन्होंने AI से कहा: "हे, टेस्ट-ड्रिवन डेवलपमेंट याद रखो! पहले एक टेस्ट लिखो, फिर कोड को ठीक करो, फिर टेस्ट की जाँच करो।"
उन्हें लगा कि इससे AI अधिक सावधान हो जाएगा। यह उल्टा पड़ गया।
- उपमा: कल्पना कीजिए कि आप एक घबराए हुए ड्राइवर को कहते हैं, "सड़क के नियमों को याद रखो! बाएं देखो, दाएं देखो, शीशे चेक करो, संकेत दो, और फिर गाड़ी चलाओ।"
- परिणाम: ड्राइवर निर्देशों की लंबी सूची से इतना अभिभूत (overwhelmed) हो गया कि वह वास्तव में गाड़ी चलाना ही भूल गया और उसने अधिक बार दुर्घटनाएं कीं।
- पेपर का निष्कर्ष: AI को प्रक्रियाओं (चीज़ों को कैसे करना है) की एक लंबी सूची देने से वास्तव में इसने अधिक कोड तोड़ा क्योंकि इसने अपना दिमाग (मेमोरी) वास्तविक समस्या के बजाय निर्देशों पर खर्च कर दिया।
नया तरीका: TDAD ( "मैप" की रणनीति)
AI को यह बताने के बजाय कि कैसे सोचना है, लेखकों ने उसे एक मैप (नक्शा) दिया।
- मैप बनाना: काम शुरू करने से पहले, TDAD पूरे कोडबेस को स्कैन करता है और एक डिपेंडेंसी मैप (निर्भरता मानचित्र) बनाता है। यह हर कोड के टुकड़े को उन विशिष्ट टेस्ट्स से जोड़ता है जो यह जाँचते हैं कि वह कोड काम कर रहा है या नहीं।
- उपमा: यह एक मास्टर इलेक्ट्रीशियन के ब्लूप्रिंट की तरह है जो दिखाता है कि घर के कौन से स्विच किन लाइटों को नियंत्रित करते हैं।
- हैंडऑफ (सौंपना): जब AI को बाथरूम में लीकेज ठीक करने के लिए कहा जाता है, तो TDAD उसे एक स्टिकी नोट थमाता है जिसमें लिखा होता है: "आपने बाथरूम का पाइप बदला है। आपको यह सुनिश्चित करने के लिए इन 3 विशिष्ट स्विचों की जाँच करनी चाहिए कि आपने गलती से किचन की लाइटें तो बंद नहीं कर दीं।"
- परिणाम: AI को अनुमान लगाने की ज़रूरत नहीं है। उसके पास सत्यापित करने के लिए बिल्कुल स्पष्ट और छोटी सूची है।
परिणाम: सटीकता का चमत्कार
टीम ने एक प्रसिद्ध बेंचमार्क (SWE-bench) पर साधारण कंप्यूटरों (सुपरकंप्यूटरों पर नहीं) पर चलने वाले ओपन-सोर्स AI मॉडल्स का उपयोग करके इसका परीक्षण किया।
- "नो मैप" (बिना मैप वाला) ग्रुप: AI ने लगभग 6% चालू कोड को तोड़ दिया।
- "लॉन्ग इंस्ट्रक्शंस" (लंबे निर्देश वाला) ग्रुप: AI ने लगभग 10% कोड को तोड़ दिया (निर्देशों ने उसे भ्रमित कर दिया)।
- "TDAD मैप" ग्रुप: AI ने केवल 1.8% कोड को तोड़ा।
यह दुर्घटनाओं में 70% की कमी है!
इसके अलावा, एक अलग AI के साथ दूसरे प्रयोग में, इसे यह मैप देने से इसने वास्तव में अधिक समस्याओं को हल करने में मदद की (24% से बढ़कर 32%), क्योंकि AI अनुमान लगाने में अपनी ऊर्जा बर्बाद नहीं कर रहा था।
"स्व-सुधार" वाला मोड़
सबसे दिलचस्प बात? लेखकों ने एक लूप बनाया जहाँ AI खुद TDAD टूल को बेहतर बना सकता है।
- AI ने अपने स्वयं के निर्देशों को देखा और महसूस किया, "हे, ये निर्देश बहुत लंबे और भ्रमित करने वाले हैं। चलिए इन्हें छोटा बनाते हैं।"
- इसने निर्देशों को 107 लाइनों से घटाकर केवल 20 लाइनें कर दिया।
- परिणाम: सफलता दर 12% से बढ़कर 60% हो गई। AI ने महसूस किया कि कम बातें, अधिक डेटा ही सफलता का असली मंत्र है।
बड़ा सबक: संदर्भ > निर्देश (Context > Instructions)
यह पेपर हमें AI के साथ बात करने के बारे में एक मूल्यवान सबक सिखाता है:
- AI को अपना काम करने के तरीके (प्रक्रियाओं) पर लंबा भाषण न दें।
- AI को वे विशिष्ट, प्रासंगिक तथ्य दें जिनकी उसे अपना काम करने के लिए आवश्यकता है (संदर्भ/Context)।
यदि आप चाहते हैं कि एक AI एक अच्छा कोडर बने, तो उसे "सावधान रहने" के लिए न कहें। उसे खतरे वाले क्षेत्रों का एक मैप दें ताकि वह सुरक्षित रूप से आगे बढ़ सके।
सारांश
TDAD एक ऐसा टूल है जो AI कोडर्स के लिए एक "डिपेंडेंसी मैप" बनाता है। AI को कोड लिखने के तरीके पर लेक्चर देने के बजाय, यह बस यह बताता है कि यह सुनिश्चित करने के लिए कौन से टेस्ट चलाने हैं कि कुछ भी टूटे नहीं। इस साधारण बदलाव ने कोड टूटने की दर को 70% कम कर दिया और यह साबित किया कि AI के लिए, लंबे निर्देशों से बेहतर अच्छी जानकारी है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।