AI एजेंट कॉम्प्लेक्सिटी रैचेट: 90% टेस्ट कवरेज क्यों आवश्यक है

मैं पिछले एक साल से AI के साथ कोडिंग कर रहा हूँ। सिर्फ प्रॉम्प्टिंग नहीं — असली सॉफ्टवेयर बना रहा हूँ। दो ओपन-सोर्स प्रोजेक्ट: GStack, जो AI कोडिंग एजेंट्स को बेहतर बनाता है, और GBrain, जो आपके द्वारा पढ़ी और लिखी गई हर चीज़ को एक खोजने योग्य नॉलेज बेस में बदल देता है जिसका उपयोग आपका AI कर सकता है। इन दोनों में मिलाकर, लगभग 970,000 लाइनें कोड और 665 टेस्ट फ़ाइलें हैं। ये लगभग सब कुछ Claude Code और Codex द्वारा मेरे निर्देशन में लिखा गया है (ज़्यादातर समय 15 एक साथ Conductor सेशन चलते हैं)।

पिछले हफ्ते मैंने 72 घंटों में चौदह पुल रिक्वेस्ट मर्ज कीं। लगभग 29,000 लाइनें नया कोड। हर रिलीज़ पिछले वाले से बेहतर टेस्टेड थी।

यह असंभव माना जाता था। गति और गुणवत्ता में समझौता होना चाहिए। तेज़ शिप करो, चीज़ें तोड़ो। धीरे चलो, सही शिप करो। एक चुनो।

अब आपको चुनने की ज़रूरत नहीं है। यह अनलॉक 90% टेस्ट कवरेज है — और AI एजेंट्स ने इसे हासिल करना मुफ़्त कर दिया है। पचास सालों तक, सत्यापन के उस स्तर की कीमत बहुत अधिक मानवीय इच्छाशक्ति थी जिसे बनाए रखना मुश्किल था। अब एजेंट कोड के साथ-साथ टेस्ट भी लिखता है। इसका परिणाम वह है जिसे मैं कॉम्प्लेक्सिटी रैचेट कहता हूँ: एक ऐसा सिस्टम जो केवल बेहतर हो सकता है, कभी बुरा नहीं।

(यह AI के साथ बिल्डिंग पर एक श्रृंखला का सातवाँ भाग है: 1 2 3 4 5 6

सॉफ्टवेयर पहले नाज़ुक हुआ करता था

पचास सालों तक, सॉफ्टवेयर इंजीनियरिंग का पूरा अनुशासन एक विचार के इर्द-गिर्द संगठित था: त्रुटियों को रोकना, क्योंकि त्रुटियाँ विनाशकारी होती हैं।

आपको कोड पहली बार में सही लिखना होता था। एक एज केस मिस करो और प्रोडक्शन में क्रैश हो जाओ। एक खराब डेटाबेस माइग्रेशन शिप करो और ग्राहक का डेटा खो दो। एक ऐसा फंक्शन लिखो जो कुछ सूक्ष्म करता है, और जब वह एक व्यक्ति जो इसे समझता है, नौकरी छोड़ देता है, तो कोई नहीं जानता कि यह क्यों काम करता है। पूरा सिस्टम मनुष्यों के सावधान रहने पर निर्भर था, और मनुष्य सावधान नहीं होते। इसलिए हमने विस्तृत प्रक्रियाएँ बनाईं — कोड रिव्यू, स्टेजिंग एनवायरनमेंट, QA टीमें, रिलीज़ ट्रेन — ये सब उपयोगकर्ताओं तक पहुँचने से पहले गलतियों को पकड़ने के लिए डिज़ाइन की गई थीं।

यह कुछ हद तक काम करता था। लेकिन यह धीमा था। और इसका मतलब था कि किसी भी सॉफ्टवेयर सिस्टम की जटिलता की एक कठोर सीमा थी: एक टीम एक साथ अपने दिमाग में रख सकने वाली चीज़ों की संख्या।

अब सॉफ्टवेयर लचीला है

मेरा मतलब लापरवाही से नहीं है। मेरा मतलब है एक ऐसी लचीलापन जो पहले संभव नहीं था।

जब मैं कहता हूँ "मॉडल यहाँ हैं," तो मेरा मतलब है कि AI कोडिंग एजेंट — Claude, GPT, Codex, और उनके आसपास बढ़ता हुआ इकोसिस्टम — अब कोड पढ़ सकते हैं, संदर्भ समझ सकते हैं, त्रुटियों का निदान कर सकते हैं, और फिक्स लिख सकते हैं। पूरी तरह से नहीं। लेकिन इतना अच्छा कि सॉफ्टवेयर के लिए त्रुटि मॉडल बदल गया है।

माइग्रेशन टूट गया? एजेंट एरर मैसेज पढ़ता है, 45 वर्ज़न में डेटाबेस स्कीमा हिस्ट्री को समझता है, फिक्स लिखता है, टेस्ट लिखता है। फ़ाइल सिंक एक मिलियन सिमलिंक पर अटक गया? एजेंट पार्सर टाइमआउट का निदान करता है, इसे 30 सेकंड पर बाउंड करता है, टेस्ट के साथ फिक्स शिप करता है। एक एक्सट्रैक्शन पाइपलाइन में एट्रिब्यूशन बग है? क्रॉस-मॉडल इवैल्यूएशन इसे पकड़ता है, प्रॉम्प्ट को दोहराया जाता है, डेटाबेस लेयर पर प्रवर्तन जोड़ा जाता है।

अधिकांश कोड-स्तरीय त्रुटियों के लिए — लॉजिक बग, पार्सिंग विफलताएँ, टूटे हुए एज केस — एजेंट अब अगले टर्न में उनका निदान और समाधान कर सकते हैं। यह वास्तव में नया है। जो त्रुटियाँ विनाशकारी रहती हैं, वे वे हैं जो स्थिति को नष्ट करती हैं: प्रोडक्शन डेटा पर खराब माइग्रेशन, पता लगने से पहले शोषित सुरक्षा छेद, प्राइवेसी लीक जिन्हें वापस नहीं लिया जा सकता। रैचेट यहाँ भी मदद करता है (अच्छे टेस्ट प्रोडक्शन से पहले इनमें से अधिकांश को पकड़ लेते हैं) लेकिन असली बदलाव यह है कि कोडबेस में अधिकांश त्रुटियाँ सुधारने योग्य प्रकार की हैं।

यह एक चरण परिवर्तन है कि सॉफ्टवेयर कैसे बनाया जाता है। लेकिन यह केवल तभी काम करता है जब आपके पास रैचेट हो।

एजेंट कॉम्प्लेक्सिटी रैचेट

रैचेट एक ऐसा तंत्र है जो केवल एक दिशा में गति की अनुमति देता है। एक सॉकेट रिंच एक बोल्ट को आगे घुमाता है और उसे पीछे मुड़ने से रोकता है। यही रूपक है।

एजेंट-कोडेड सॉफ्टवेयर में, AI एजेंट के साथ हर कोडिंग सेशन कोडबेस में तीन चीज़ें जोड़ता है:

टेस्ट जो यह एनकोड करते हैं कि "सही" का क्या अर्थ है — स्वचालित जाँच जो हर बार कोई कोड बदलता है तो चलती हैं, और जोर से विफल होती हैं यदि बदलाव कुछ तोड़ता है
दस्तावेज़ीकरण जो रिकॉर्ड करता है कि निर्णय क्यों लिए गए — सिर्फ कोड क्या करता है, बल्कि उसके पीछे तर्क और ट्रेडऑफ़ भी
मूल्यांकन परिणाम जो गुणवत्ता सीमाएँ स्थापित करते हैं — स्कोर के साथ आउटपुट गुणवत्ता का संरचित मूल्यांकन, ताकि आप जान सकें कि अगला संस्करण बेहतर है या बुरा

अगली बार जब कोई एजेंट कोडबेस पर काम करता है, तो वह तीनों को अपने कॉन्टेक्स्ट विंडो (वह टेक्स्ट जिसे AI देख और तर्क कर सकता है) में लोड करता है। यह टेस्ट सूट से नीचे नहीं जा सकता — टेस्ट विफल हो जाएँगे। यह दस्तावेज़ीकरण को अनदेखा नहीं कर सकता — यह कॉन्टेक्स्ट में ठीक है। यह मूल्यांकन बेसलाइन से नीचे की गुणवत्ता शिप नहीं कर सकता — स्कोर रिकॉर्ड किए गए हैं।

गुणवत्ता का फर्श हर टर्न के साथ ऊपर जाता है। केवल आगे की गति। यही रैचेट है।

व्यवहार में यह कैसा दिखता है

मैं इसे ठोस बनाता हूँ। GBrain एक नॉलेज सिस्टम है जिसे मैं बना रहा हूँ — यह AI एजेंट्स को दीर्घकालिक मेमोरी देता है, किसी व्यक्ति के नोट्स, मीटिंग्स, बातचीत और शोध को स्टोर, इंडेक्स और सर्च करके। इसे एक दूसरे दिमाग के रूप में सोचें जिसे आपका AI असिस्टेंट वास्तव में पढ़ सकता है।

इसकी एक विशेषता एपिस्टेमोलॉजिकल एक्सट्रैक्शन है: यह हज़ारों पेजों को पढ़ता है और निकालता है कि कौन क्या मानता है, किस आत्मविश्वास के साथ, समय के साथ। "गैरी सोचता है कि Bitcoin $300K तक पहुँचेगा (आत्मविश्वास: 0.45)।" "जेरेड सोचता है कि इस स्टार्टअप में मजबूत रिटेंशन है (आत्मविश्वास: 0.80)।" ऐसे ही, लेकिन 28,000 पेजों पर।

पहले एक्सट्रैक्शन रन ने 100,720 दावे निकाले। मैंने गुणवत्ता को ग्रेड करने के लिए क्रॉस-मॉडल इवैल्यूएशन का उपयोग किया — मैंने GPT-5.5 और Claude दोनों को स्वतंत्र रूप से आउटपुट को स्कोर करने दिया। कुल मिलाकर: 10 में से 6.8।

सबसे बड़ी समस्या? कुछ जिसे मैं होल्डर कन्फ्यूज़न कहता हूँ। दावा लें "AI 2027 तक 80% सॉफ्टवेयर इंजीनियरों को बदल देगा।" यह विश्वास किसका है? क्या यह उस व्यक्ति का है जिसने इसे लिखा है? क्या यह कोई है जिसका वे उद्धरण दे रहे हैं? या यह सिस्टम का विश्लेषण इंजन है, जिसने इसे एक पॉडकास्ट ट्रांसक्रिप्ट से अनुमान लगाया है? वर्ज़न 1 को यह अंतर 35% समय गलत मिला। यह मायने रखता है — यदि आप एक ऐसा सिस्टम बना रहे हैं जो ट्रैक करता है कि लोग क्या मानते हैं, तो आपको यह जानना होगा कि यह कौन मानता है।

इसलिए मूल्यांकन परिणाम दस्तावेज़ित किए गए। छह विशिष्ट विफलता मोड की पहचान की गई। वर्ज़न 2 प्रॉम्प्ट ने सभी छह को संबोधित किया। वेट राउंडिंग (आत्मविश्वास स्कोर) को डेटाबेस लेयर पर लागू किया गया — 0.74 जैसी झूठी सटीकता नहीं जब 0.75 ईमानदार उत्तर है। सत्रह टेस्ट ने अनुबंध को लॉक कर दिया।

अब एक्सट्रैक्शन का कोई भी भविष्य का संस्करण उन 17 टेस्टों को पास किए बिना शिप नहीं कर सकता। किसी को यह याद रखने की ज़रूरत नहीं है कि वेट राउंडिंग क्यों मायने रखती है या होल्डर कन्फ्यूज़न क्या है। टेस्ट याद रखते हैं।

गुणवत्ता का फर्श स्थायी रूप से ऊपर चला गया। यह रैचेट का एक टर्न है।

अधिकांश वाइबकोडेड प्रोजेक्ट क्यों मर जाते हैं

"वाइबकोडिंग" एंड्रेज कार्पथी का शब्द है AI के साथ कोडिंग के लिए, जिसमें आप प्राकृतिक भाषा में बताते हैं कि आप क्या चाहते हैं और मॉडल को कोड जनरेट करने देते हैं। यह शक्तिशाली है और इसी तरह मैं बनाता हूँ। लेकिन YC एप्लिकेशन और ओपन-सोर्स रिपॉजिटरी में मैंने जो देखा है, उससे अधिकांश वाइबकोडेड प्रोजेक्ट जो टेस्ट छोड़ देते हैं, मध्यम जटिलता तक पहुँचने पर बिखरने लगते हैं — कुछ हज़ार लाइनें, मुट्ठी भर इंटरैक्टिंग फीचर।

वे रैचेट छोड़ देते हैं। कोई टेस्ट नहीं, कोई डॉक्स नहीं, कोई इवैल नहीं। एजेंट जटिलता जोड़ता है लेकिन कुछ भी प्रतिगमन को नहीं रोकता है। हर नए फीचर में पुराने को तोड़ने की संभावना होती है, और टेस्ट के बिना, आपको तब तक पता नहीं चलता जब तक कोई उपयोगकर्ता इसकी रिपोर्ट नहीं करता। वर्ज़न 0.5 तक कोडबेस एक भूतिया घर है जहाँ हर बदलाव कुछ अप्रत्याशित तोड़ता है। फिर डेवलपर एक ब्लॉग पोस्ट लिखता है कि AI कोडिंग काम नहीं करती।

AI कोडिंग ठीक काम करती है। उन्होंने बस रैचेट नहीं बनाया।

आप तर्क दे सकते हैं कि जिस तरह का व्यक्ति टेस्ट लिखता है, वह भी वही है जो पहली बार में अच्छा आर्किटेक्चर लिखता है। उचित है। लेकिन रैचेट तंत्र व्यक्ति के बारे में नहीं है — यह इस बारे में है कि अगले टर्न पर क्या होता है। जब कोई नया योगदानकर्ता PR खोलता है, या जब मॉडल वर्ज़न बदलता है, या जब आप रात के 2 बजे कोडिंग कर रहे होते हैं और आपका निर्णय ख़राब होता है, तो टेस्ट प्रतिगमन को पकड़ते हैं, भले ही उन्हें किसने लिखा हो। रैचेट तब भी काम करता है जब मानव अपने सर्वश्रेष्ठ पर न हो। यही बात है।

टेस्ट के बिना, सुधार एक शोर प्रक्रिया है — एजेंट चीज़ों को बेहतर बनाने की कोशिश करते हैं, लेकिन प्रतिगमन संकेतों के बिना, अच्छे बदलाव और बुरे बदलाव समान रूप से अदृश्य होते हैं। एक घने टेस्ट सूट के साथ, आपको परीक्षण की गई सतह पर एक रैचेट मिलता है: आपके द्वारा एनकोड किए गए व्यवहारों के लिए गुणवत्ता केवल ऊपर जा सकती है। यह अधिकांश सिस्टम है, सब कुछ नहीं। लेकिन यह गति से आगे की गति बनाए रखने के लिए पर्याप्त है।

संस्थागत स्मृति के रूप में टेस्ट

पारंपरिक सॉफ्टवेयर कंपनियों में, संस्थागत स्मृति मनुष्यों में रहती है। वरिष्ठ इंजीनियर जो जानता है कि वह कैशिंग लेयर क्यों मौजूद है। आर्किटेक्ट जो उस माइग्रेशन को याद रखता है जिसने लगभग डेटाबेस को नष्ट कर दिया था। टेक लीड जो बिलिंग सिस्टम में अजीब एज केस समझा सकता है।

मनुष्य चले जाते हैं। वे रिटायर होते हैं, उन्हें पोच किया जाता है, वे बर्न आउट होते हैं। जब वे जाते हैं, तो ज्ञान उनके साथ चला जाता है। हर सॉफ्टवेयर कंपनी ने एक महत्वपूर्ण फ़ाइल खोलने और एक टिप्पणी खोजने का अनुभव किया है जो कहती है // इसे मत बदलो — डेव से पूछो और डेव तीन साल पहले चला गया।

एजेंट का कॉन्टेक्स्ट विंडो नौकरी नहीं छोड़ता। इसे पोच नहीं किया जाता। यह भूलता नहीं है। जब टेस्ट सूट एनकोड करता है "वेट राउंडिंग को 0.05 इंक्रीमेंट का उपयोग करना चाहिए" और दस्तावेज़ीकरण बताता है "क्योंकि क्रॉस-मॉडल इवैल ने दिखाया कि झूठी सटीकता आत्मविश्वास स्कोर में विश्वास को कम करती है," तो वह ज्ञान टिकाऊ है। कोई भी एजेंट, कोई भी मॉडल, कोई भी समय उस कॉन्टेक्स्ट को लोड कर सकता है और बाधा को समझ सकता है।

टेस्ट संस्थागत स्मृति हैं जो कर्मचारी कारोबार से बच जाते हैं। एक-व्यक्ति प्रोजेक्ट के लिए, वे और भी महत्वपूर्ण हैं — वे एकमात्र संस्थागत स्मृति हैं जो आपके पास है।

हर चीज़ जो हार्नेसेबल है, टेस्टेबल है

रैचेट सिर्फ पारंपरिक कोड के लिए काम नहीं करता। यह किसी भी चीज़ के लिए काम करता है जिसे कंप्यूटर देख सकता है।

एक आधुनिक सिस्टम की परतों के बारे में सोचें। OS आपको प्रोसेस ट्री, फ़ाइल सिस्टम स्टेट, नेटवर्क सॉकेट, क्रॉन शेड्यूल देता है। टर्मिनल आपको हर कीस्ट्रोक, आउटपुट की हर लाइन, हर इंटरैक्टिव प्रॉम्प्ट देता है। ब्राउज़र आपको रेंडर किए गए पेज, बटन स्टेट, नेविगेशन इवेंट देता है। APIs आपको संरचित प्रतिक्रियाएँ देते हैं जिन्हें आप पार्स और मान्य कर सकते हैं। और AI एजेंट आपको देखने योग्य व्यवहार देते हैं — वे क्या कहते हैं, वे कौन से टूल कॉल करते हैं, वे किस क्रम में चीज़ें करते हैं, क्या वे कार्य करने से पहले पूछते हैं।

ये सब हार्नेसेबल हैं। और यदि आप इसे हार्नेस कर सकते हैं, तो आप इसे देख सकते हैं। यदि आप इसे देख सकते हैं, तो आप इस पर दावा कर सकते हैं। यदि आप इस पर दावा कर सकते हैं, तो आप इसे रैचेट कर सकते हैं।

यह पारंपरिक यूनिट टेस्ट की तुलना में बहुत बड़ा सरफेस एरिया है। मुझे आपको दिखाने दें।

GStack मेरा ओपन-सोर्स कोडिंग एजेंट फ्रेमवर्क है — 93,000 GitHub स्टार, 701,000 लाइनें कोड, 46 स्किल। इसकी एक मुख्य विशेषता इंटरैक्टिव प्लान रिव्यू है: आप इसे अपने आर्किटेक्चर की समीक्षा करने के लिए कहते हैं, और यह प्लान के माध्यम से सेक्शन दर सेक्शन चलता है, सवाल पूछता है, एज केस की जाँच करता है, आपकी धारणाओं को चुनौती देता है। जैसे एक इंजीनियरिंग मैनेजर होना जो वास्तव में कोड पढ़ता है।

समस्या: Claude Code कभी-कभी पूरे इंटरैक्टिव भाग को छोड़ देता था। यह प्लान फ़ाइल पढ़ता, एक बार में सभी निष्कर्ष डंप करता, और बाहर निकल जाता — उपयोगकर्ता से एक भी सवाल पूछे बिना। समीक्षा का पूरा बिंदु आगे-पीछे की बातचीत है। इसे छोड़ना उद्देश्य को विफल करता है।

आप उसका परीक्षण कैसे करते हैं? आप यूनिट टेस्ट नहीं कर सकते "क्या AI ने बातचीत की।" कोई पारंपरिक टेस्टिंग फ्रेमवर्क इसे कवर नहीं करता।

इसलिए मैंने Bun के TTY कार्यक्षमता का उपयोग करके एक टेस्ट हार्नेस बनाया (PR #1354) जो सचमुच Claude Code को एक स्यूडो-टर्मिनल के अंदर स्पॉन करता है, इसे एक विशिष्ट रिपो वाला परिदृश्य खिलाता है, रिव्यू स्किल को ट्रिगर करता है, और वास्तविक समय में टर्मिनल आउटपुट देखता है। टेस्ट देखता है कि क्या एजेंट समाप्त करने से पहले एक इंटरैक्टिव प्रश्न फायर करता है। यदि यह बिना कुछ पूछे निष्कर्ष डंप करता है और बाहर निकलता है, तो टेस्ट विफल हो जाता है।

यह कोड का परीक्षण नहीं है। यह परीक्षण कर रहा है कि क्या AI एजेंट एक व्यवहारिक अनुबंध का पालन करता है। TTY स्तर पर। सचमुच इसे काम करते हुए देखकर।

रैचेट प्रतिक्रिया तीन परतों वाली थी:

स्किल निर्देशों में STOP गेट्स — स्पष्ट नियम जो कहते हैं "आपको अगले सेक्शन में जाने से पहले उपयोगकर्ता से पूछना चाहिए," एंटी-रैशनलाइज़ेशन क्लॉज़ के साथ जो विशिष्ट विफलता मोड का नाम देते हैं ताकि मॉडल खुद को छोड़ने के लिए मना न कर सके
एंटी-शॉर्टकट क्लॉज़ — "प्लान फ़ाइल इंटरैक्टिव रिव्यू का आउटपुट है, इसका विकल्प नहीं।" एक वाक्य जो उस सटीक लूपहोल को बंद करता है जिसका मॉडल शोषण करता रहता था।
गेट-टियर फ्लोर टेस्ट — TTY हार्नेस टेस्ट जो नियंत्रित परिदृश्यों में Claude Code को स्पॉन करते हैं और विफल हो जाते हैं यदि एजेंट कम से कम एक इंटरैक्टिव प्रश्न नहीं पूछता है

अब जब Anthropic एक नया मॉडल वर्ज़न शिप करता है, या जब मैं एक स्किल प्रॉम्प्ट बदलता हूँ, तो टेस्ट सूट इंटरैक्टिव अनुबंध में किसी भी प्रतिगमन को पकड़ लेता है। एजेंट चुपचाप सवाल पूछना बंद नहीं कर सकता। टेस्ट टर्मिनल देखता है और जाँच करता है।

या PR #880 लें, जिसने एक नया OpenClaw प्लगइन शिप किया। टेस्ट सिर्फ यह जाँच नहीं करता कि कोड कंपाइल होता है। यह स्रोत से प्लगइन बनाता है, एक अलग प्रोफ़ाइल में एक वास्तविक OpenClaw इंस्टेंस स्पॉन करता है, CLI के माध्यम से प्लगइन इंस्टॉल करता है, यह सत्यापित करने के लिए plugins inspect चलाता है कि रनटाइम ने इसे लोड किया, कॉन्फ़िग स्लॉट सेट करता है, कॉन्फ़िग को मान्य करता है, और शून्य डायग्नोस्टिक्स की पुष्टि करने के लिए plugins doctor चलाता है। दो अलग-अलग प्रोग्रामों में एक पूर्ण एंड-टू-एंड राउंड ट्रिप। 359 लाइनें टेस्ट कोड। जिस तरह का टेस्ट एक मानव लगभग कभी हाथ से नहीं लिखेगा क्योंकि सेटअप बहुत थकाऊ है। Claude ने इसे लगभग पाँच मिनट में लिखा। यह प्रयास की दीवार है जो वास्तविक समय में गायब हो रही है।

सिद्धांत सामान्यीकृत होता है। आप OS स्तर पर परीक्षण कर सकते हैं: क्या माइग्रेशन ने सही टेबल बनाई, क्या क्रॉन जॉब फायर हुआ, क्या प्रक्रिया अभी भी जीवित है? ब्राउज़र स्तर पर: क्या पेज रेंडर हुआ, क्या एजेंट ने फॉर्म सही ढंग से भरा। API स्तर पर: क्या मॉडल ने सही स्कीमा के साथ मान्य JSON लौटाया। व्यवहारिक स्तर पर: क्या एजेंट ने प्रोटोकॉल का पालन किया, क्या उसने हटाने से पहले पूछा, क्या वह रुका जब उसे रुकने के लिए कहा गया।

पूरा स्टैक टेस्टेबल है। रैचेट यह सब पर लागू होता है। अधिकांश लोगों को अभी तक इसका एहसास नहीं हुआ है क्योंकि वे अभी भी टेस्ट कवरेज के बारे में सोच रहे हैं "क्या मेरे फंक्शन ने सही नंबर लौटाया।" असली टेस्ट सरफेस वह सब कुछ है जो कंप्यूटर देख सकता है।

90% का आंकड़ा

तो 90% टेस्ट कवरेज वास्तव में आपको क्या खरीदता है?

कैपर्स जोन्स ने 10,000 से अधिक सॉफ्टवेयर प्रोजेक्ट्स का अध्ययन किया और डिफेक्ट रिमूवल एफिशिएंसी (DRE) को मापा — उपयोगकर्ताओं तक पहुँचने से पहले पकड़े गए बग का प्रतिशत। Applied Software Measurement से उनका डेटा एक नॉनलाइनियर कर्व दिखाता है: 70% कवरेज से नीचे, DRE लगभग 65-75% होता है। 85-95% कवरेज पर, DRE 92-97% तक बढ़ जाता है। संबंध रैखिक नहीं है। कर्व में लगभग 85% पर एक घुटना है जहाँ डिफेक्ट एस्केप तेजी से गिरते हैं।

एवियोनिक्स उद्योग ने दशकों पहले इसका पता लगा लिया था। DO-178C, उड़ान-महत्वपूर्ण सॉफ्टवेयर के लिए FAA मानक, लेवल A सिस्टम के लिए संशोधित कंडीशन/डिसीज़न कवरेज (MC/DC) की आवश्यकता है — वे जहाँ एक बग का मतलब विमान दुर्घटना है। ब्रांच कवरेज अकेले 10-20% दोषों को याद करता है। MC/DC, जो लाइन कवरेज से सख्त है, >99% DRE प्राप्त करता है। वे इसे अनिवार्य नहीं करते क्योंकि नौकरशाहों को कागजी कार्रवाई पसंद है। वे इसे अनिवार्य करते हैं क्योंकि डेटा ने दिखाया कि कुछ कवरेज सीमाओं से नीचे, महत्वपूर्ण दोष उन दरों पर बच जाते हैं जो लोगों को मारने के साथ असंगत हैं।

विश्वसनीयता इंजीनियरिंग समानांतर साफ है। कारखाने गुणवत्ता मापने के लिए सिक्स सिग्मा नामक एक प्रणाली का उपयोग करते हैं। विचार: गिनें कि आपको प्रति मिलियन उत्पादित इकाइयों में कितने दोष मिलते हैं, फिर इसे "सिग्मा स्तर" के रूप में व्यक्त करें — उच्च सिग्मा का अर्थ है कम दोष। 3-सिग्मा प्रक्रिया प्रति मिलियन लगभग 67,000 दोष पैदा करती है (बहुत बुरा)। 4-सिग्मा प्रक्रिया लगभग 6,200 पैदा करती है (दस गुना बेहतर)। 5-सिग्मा प्रक्रिया 233 पैदा करती है (अन्य 27x बेहतर)। 4 से 5 सिग्मा तक की छलांग वृद्धिशील सुधार नहीं है। यह एक चरण परिवर्तन है।

टेस्ट कवरेज उसी वक्र का अनुसरण करता है। 70% से 90% कवरेज तक जाना 30% बेहतर नहीं है। यह परिमाण के क्रम से कम एस्केप है। 70% पर जो दोष फिसलते हैं, वे 30% अप्रयुक्त कोड में छिपे होते हैं। 90% पर, छिपने के स्थान 10% तक सिकुड़ जाते हैं और अधिकांश खतरनाक रास्ते बंद हो जाते हैं।

अब, मुझे ईमानदार होना चाहिए कि शोध यह भी दिखाता है। Mockus, Nagappan, and Dinh-Trong ने Windows Vista का अध्ययन किया और पाया कि जबकि कवरेज कम पोस्ट-रिलीज़ दोषों से संबंधित है, 90%+ तक पहुँचने का प्रयास तेजी से बढ़ता है। अंतिम 20% कवरेज पहले 70% की तुलना में असम्मानजनक रूप से अधिक काम लेता है। यह दशकों से सच रहा है। यही कारण है कि अधिकांश टीमें 70-80% पर रुक जाती हैं और इसे काफी अच्छा कहती हैं।

लेकिन कुछ बदल गया है: AI कोडिंग एजेंट प्रयास का अनुभव नहीं करते।

वे चौदहवाँ एज केस टेस्ट लिखने से ऊबते नहीं हैं। वे शुक्रवार शाम 5 बजे कोने नहीं काटते। वे एक गंदे इंटीग्रेशन टेस्ट को देखकर नहीं सोचते "मैं बाद में इस पर वापस आऊँगा।" प्रयास वक्र जिसने मानव टीमों को 70% पर रोक दिया, एजेंटों पर लागू नहीं होता। आप Claude से किसी मॉड्यूल में हर एज केस के लिए टेस्ट लिखने के लिए कह सकते हैं और वह इसे खुशी से, पूरी तरह से, रात के 2 बजे, बिना शिकायत किए करेगा। वह क्रूर अंतिम 20% जिसने 90% कवरेज को मानव टीमों के लिए अव्यावहारिक बना दिया, ठीक उसी तरह का काम है जिसमें AI एजेंट सबसे अच्छे हैं।

यह असली अनलॉक है। यह नहीं कि AI आपको तेज़ी से कोड लिखने देता है। बहुत से लोगों ने यह देखा है। यह है कि AI आपको उस स्तर पर सत्यापित करने देता है जो पहले बनाए रखने के लिए बहुत महंगा था। 90% सीमा जो डेटा कहता है कि जादुई है? इसे हासिल करने के लिए बहुत अधिक मानवीय इच्छाशक्ति खर्च होती थी। अब यह मुफ़्त है।

यह मुख्य अंतर है। रैचेट लाइन कवरेज के बारे में एक वैनिटी मीट्रिक के रूप में नहीं है। यह उन टेस्टों के बारे में है जो व्यवहारिक अनुबंधों को एनकोड करते हैं — होल्डर कन्फ्यूज़न टेस्ट, वेट राउंडिंग टेस्ट, इंटरैक्टिव रिव्यू गेट। प्रत्येक टेस्ट एक विशिष्ट सीखे गए पाठ को लॉक करता है। कवरेज वह प्रॉक्सी है जो आपको बताता है कि सिस्टम का कितना व्यवहार अनुबंध के अंतर्गत है। 90% पर, लगभग हर व्यवहार परिवर्तन एक टेस्ट सिग्नल को ट्रिगर करता है। एजेंट या तो पास करता है (शिप करना सुरक्षित) या एक टेस्ट तोड़ता है (तुरंत पकड़ा गया)।

शेष 10% इंटीग्रेशन पॉइंट, इन्फ्रास्ट्रक्चर प्लंबिंग, और एज केस हैं जिनका परीक्षण करना वास्तव में कठिन है। यह ठीक है। 90% वह है जो अराजकता को एक रैचेट में बदल देता है।

90% तक पहुँचना एक वीरतापूर्ण प्रयास हुआ करता था। अब यह एक मंगलवार है। यही खेल परिवर्तन है।

अवधारणा का प्रमाण

मैंने दोनों प्रोजेक्ट अकेले शुरू किए। वे अब एकल नहीं हैं।

GStack में अब 37 योगदानकर्ता हैं। v1.30 ने एक ही रिलीज़ में 21 सामुदायिक PR शामिल किए। GBrain में 25 योगदानकर्ता हैं। v0.31.1.1 ने एक PR में 22 सामुदायिक फिक्स उतारे — ऑथ फ्लो, स्कीमा बूटस्ट्रैपिंग, सिंक, प्राइवेसी।

रैचेट ही इसे सुरक्षित बनाता है। हर बाहरी PR को मौजूदा टेस्ट सूट पास करना होता है। एक नए योगदानकर्ता को पूरे सिस्टम को समझने की ज़रूरत नहीं है। उन्हें टेस्ट पास करने की ज़रूरत है।

पिछले हफ्ते के GBrain रिलीज़ कहानी बताते हैं:

v0.31.0: रीयल-टाइम मेमोरी के लिए एक नया फैक्ट्स टेबल, साथ ही एक ड्रीम कंसोलिडेशन चरण जो अल्पकालिक यादों को दीर्घकालिक ज्ञान में बढ़ावा देता है
v0.31.1: 25 CLI कमांड को ठीक किया जो चुपचाप एक खाली स्थानीय डेटाबेस पर रूट कर रहे थे, उपयोगकर्ता के वास्तविक दिमाग के बजाय
v0.31.1.1: एक PR में बाईस सामुदायिक-रिपोर्टेड फिक्स
v0.31.2: एक कोड सिंक को ठीक किया जो बड़े रिपॉजिटरी पर सिमलिंक के साथ हमेशा के लिए अटक जाता था, 30-सेकंड टाइमआउट जोड़कर

प्रत्येक रिलीज़ पिछले वाले से अधिक टेस्ट के साथ शिप हुई। एजेंट कोड के साथ-साथ टेस्ट लिखता है। कवरेज फिसलता नहीं है क्योंकि इसे बनाए रखने का प्रयास अब मानवीय बोझ नहीं है।

नई जटिलता सीमा

सॉफ्टवेयर के लिए जटिलता की सीमा अभी बहुत अधिक हो गई है।

यह पहले एक टीम की सिस्टम को अपने दिमाग में रखने की क्षमता से बंधी थी। अब यह एक व्यक्ति प्लस एजेंटों से बंधी है जो पूरे कोडबेस, स्कीमा हिस्ट्री, टेस्ट सूट और दस्तावेज़ीकरण को कॉन्टेक्स्ट में लोड कर सकते हैं।

यह बहुत बड़ी संख्या है। और यह बढ़ती रहती है क्योंकि कॉन्टेक्स्ट विंडो बड़ी होती जाती है और मॉडल कोड के बारे में तर्क करने में बेहतर होते जाते हैं।

हर सॉफ्टवेयर कंपनी जो इस मॉडल को नहीं अपनाती — एजेंट प्लस स्वाद प्लस एक टेस्ट सूट जो केवल ऊपर जाता है — पहले से ही एक व्यक्ति की तुलना में धीमी और कम गुणवत्ता के साथ शिप कर रही है जिसके पास यह है।

उपकरण यहाँ हैं। कोड खुला है। टेस्ट रैचेट हैं। 90% कवरेज, हर PR, कोई अपवाद नहीं।

पचास सालों तक, 90% कवरेज एवियोनिक्स और चिकित्सा उपकरणों के लिए आरक्षित एक विलासिता थी — प्रयास की दीवार पर मानव घंटे फेंकने के बजट वाली टीमें। AI एजेंटों ने उस दीवार को ध्वस्त कर दिया। कवरेज सीमा जो सॉफ्टवेयर को विश्वसनीय बनाती है, अब महंगी नहीं है। यह सिर्फ एक सेटिंग है। सवाल यह नहीं है कि क्या आप 90% खरीद सकते हैं। यह है कि क्या आप नहीं खरीदने का जोखिम उठा सकते हैं।

रैचेट, स्किल और पूरा नॉलेज सिस्टम GitHub पर ओपन सोर्स और मुफ़्त है। जाओ बनाओ।

मेरे MIT-लाइसेंस प्राप्त ओपन सोर्स प्रोजेक्ट: