AI Agent Complexity Ratchet: 90% Test Coverage क्यों ज़रूरी है

AI कोडिंग युग का Complexity Ratchet - Garry Tan के निबंध का सार

यह Garry Tan (Y Combinator CEO) द्वारा X पर साझा किया गया एक लंबा निबंध है, जिसमें पिछले एक साल के दौरान AI एजेंट्स (Claude Code, Codex आदि) के साथ दो open source प्रोजेक्ट बनाने के अनुभव को संक्षेप में बताया गया है। उनके अनुसार, लगभग 9.7 लाख लाइनों का कोड और 665 test files में से अधिकांश AI ने लिखीं, और साथ ही 15 agent sessions एक साथ चलाए गए। वह इस प्रक्रिया के आधार पर दावा करते हैं कि software engineering का पुराना सिद्धांत, यानी "speed और quality में से एक चुनना पड़ता है", अब टूट चुका है, और इसके मुख्य मेकैनिज़्म के रूप में वह 'Complexity Ratchet' की अवधारणा पेश करते हैं।

मुख्य अवधारणाएँ

• Ratchet क्या है यह एक ऐसी दाँतेदार पहिए वाली युक्ति का रूपक है जो केवल एक दिशा में चलती है; यहाँ इसका मतलब ऐसी संरचना से है जो codebase की quality को पीछे लौटे बिना केवल आगे बढ़ने देती है।
• तीन तरह की संचयित संपत्तियाँ एजेंट के साथ हर coding session में codebase में तीन चीज़ें जुड़ती जाती हैं: tests (क्या सही है), documentation (ऐसा निर्णय क्यों लिया गया), और evaluation results (quality baseline)।
• context window का उपयोग अगली session में AI एजेंट इन तीनों को पढ़कर काम करता है, इसलिए वह tests तोड़ नहीं सकता, documentation को नज़रअंदाज़ नहीं कर सकता, या evaluation score को गिरा नहीं सकता।

पारंपरिक तरीकों से अंतर

• error model में बदलाव पिछले 50 वर्षों में software engineering ने इस धारणा पर code review, QA, staging जैसी जटिल प्रक्रियाएँ बनाई थीं कि "errors घातक हैं, इसलिए उन्हें पहले से रोकना होगा"; लेकिन अब अधिकांश errors को एजेंट अगली turn में diagnose करके ठीक कर सकता है।
• complexity limit का विस्तार system complexity की ऊपरी सीमा "एक टीम अपने दिमाग में कितना रख सकती है" से बढ़कर "एक व्यक्ति और पूरे codebase को context में लोड किए हुए एजेंट्स" तक पहुँच गई है।
• institutional memory की स्थायित्व लोग नौकरी छोड़ते हैं या burnout का शिकार होकर चले जाते हैं, लेकिन tests और documentation में बचा ज्ञान किसी भी model, किसी भी समय फिर से बुलाया जा सकता है।

90% test coverage का मतलब

• non-linear quality curve Capers Jones के 10,000 से अधिक प्रोजेक्ट्स के अध्ययन के अनुसार, 70% से कम coverage पर defect removal rate 65~75% तक सीमित रहता है, लेकिन 85~95% coverage पर यह 92~97% तक उछल जाता है; यानी एक स्पष्ट 'knee point' मौजूद है।
• aviation industry की मिसाल aviation software standard DO-178C, Level A (critical) systems के लिए MC/DC coverage अनिवार्य करता है, ताकि 99% से अधिक defect removal rate हासिल किया जा सके।
• AI ने cost barrier तोड़ा आख़िरी 20% coverage भरना इंसानों के लिए उबाऊ और महँगा काम था, लेकिन एजेंट थकते नहीं हैं, इसलिए वे रात के बीच में भी edge-case tests लगातार लिख सकते हैं।

लेखक द्वारा दिए गए वास्तविक उदाहरण

• GBrain में extraction accuracy सुधार 1 लाख से अधिक belief extractions में "यह दावा किसने किया" को 35% मामलों में गलत पहचानने की समस्या को 17 tests के जरिए स्थिर किया गया, ताकि कोई भी बाद का version उस स्तर से नीचे न जा सके।
• Superpowers के TTY tests AI एजेंट interactive review को skip कर रहा था; इसे Bun की pseudo-terminal capability से सीधे monitor और block किया गया, जिससे "क्या AI ने बातचीत की" जैसे गैर-पारंपरिक requirement को भी test में बदला गया।

फायदे और सीमाएँ

• फायदे बाहरी contributors को पूरे system को समझे बिना भी, केवल tests पास करवाकर सुरक्षित रूप से PR merge करने की सुविधा मिलती है, जिससे collaboration में entry barrier कम होता है।
• सीमाएँ state को नष्ट करने वाली errors (गलत DB migration, security breach, privacy leak) अब भी घातक हैं, और लगभग 10% integration points तथा infrastructure को स्वभावतः test करना कठिन रहता है।
• आपत्तियों का जवाब "जो लोग अच्छे tests लिखते हैं, वही मूल architecture भी अच्छा बनाते हैं" जैसी आपत्ति के जवाब में वह कहते हैं कि ratchet का मूल तत्व व्यक्ति नहीं, बल्कि अगली turn की safety net है।

इस लेख का मुख्य संदेश यह है कि AI coding का असली मूल्य "तेज़ी से कोड लिखना" नहीं, बल्कि "उस स्तर की verification को लगभग मुफ़्त बना देना" है जिसे अब तक बहुत महँगा होने के कारण छोड़ा जाता था। 50 वर्षों तक aviation और healthcare क्षेत्रों तक सीमित रही 90% test coverage अब एक व्यक्ति की रोज़मर्रा की प्रैक्टिस बन सकती है, और इसके परिणामस्वरूप एक डेवलपर द्वारा बनाए जा सकने वाले software की complexity ceiling नाटकीय रूप से बढ़ सकती है। हालाँकि, यह लेख स्वयं लेखक के open source प्रोजेक्ट्स (Superpowers, GBrain) के प्रचार का भी एक हिस्सा है, और कुछ statistical references (जैसे GPT-5.5) में verification की आवश्यकता है, इसलिए इसे आलोचनात्मक दृष्टि से पढ़ना भी ज़रूरी है।