यह Garry Tan (Y Combinator CEO) द्वारा X पर साझा किया गया एक लंबा निबंध है, जिसमें पिछले एक साल में AI agents (Claude Code, Codex आदि) के साथ दो open source projects बनाने के अनुभव को संक्षेप में रखा गया है। लगभग 9.7 लाख lines of code और 665 test files में से अधिकांश AI ने लिखीं, और साथ ही 15 agent sessions एक साथ चलाए गए। उनका दावा है कि इस प्रक्रिया से software engineering का पुराना सिद्धांत — "speed और quality में से एक ही चुना जा सकता है" — टूट गया है, और इसके मुख्य mechanism के रूप में वे 'Complexity Ratchet' की अवधारणा प्रस्तुत करते हैं.
मुख्य अवधारणाओं का सार
- Ratchet क्या है: यह एक ऐसे gear mechanism का रूपक है जो केवल एक दिशा में चलता है; यहाँ इसका अर्थ है ऐसी संरचना जो codebase की quality को पीछे जाने नहीं देती, केवल आगे बढ़ाती है।
- तीन तरह का संचय: agents के साथ हर coding session में तीन चीज़ें codebase में जुड़ती जाती हैं — tests (क्या सही है), documentation (ऐसा निर्णय क्यों लिया गया), और evaluation results (quality baseline)।
- context window का उपयोग: अगले session में AI agent इन तीनों को पढ़कर काम करता है, इसलिए tests तोड़ना, documentation को नज़रअंदाज़ करना, या evaluation score गिराना मुश्किल हो जाता है।
पारंपरिक तरीकों से अंतर
- error model में बदलाव: पिछले 50 वर्षों से software engineering इस मान्यता पर चली कि "errors घातक हैं, इसलिए उन्हें पहले से रोको"; इसी कारण code review, QA, staging जैसी जटिल प्रक्रियाएँ बनीं। अब अधिकांश errors को agent अगले turn में diagnose और fix कर सकता है।
- complexity limit का विस्तार: system complexity की ऊपरी सीमा अब "एक टीम अपने दिमाग में जितना रख सकती है" से बढ़कर "एक व्यक्ति और agents, जो पूरे codebase को context में load कर सकें" तक पहुँच गई है।
- institutional memory की स्थायित्व: लोग नौकरी छोड़ते हैं या burnout का शिकार होते हैं, लेकिन tests और documentation में बचा ज्ञान किसी भी model द्वारा, किसी भी समय, फिर से बुलाया जा सकता है।
90% test coverage का महत्व
- non-linear quality curve: Capers Jones के लगभग 10,000 projects के अध्ययन के अनुसार, 70% से कम coverage पर defect removal rate 65~75% तक रहता है, लेकिन 85~95% पर यह 92~97% तक तेज़ी से बढ़ता है; यानी एक 'knee point' मौजूद है।
- aviation industry की मिसाल: aviation software standard DO-178C, Level A (critical) systems के लिए MC/DC coverage अनिवार्य करता है, ताकि 99% से अधिक defect removal rate हासिल किया जा सके।
- AI ने लागत की बाधा तोड़ी: आख़िरी 20% coverage भरना इंसानों के लिए उबाऊ और महँगा काम था, लेकिन agents थकते नहीं; इसलिए वे रात में भी edge-case tests अनगिनत लिख सकते हैं।
लेखक द्वारा दिए गए वास्तविक उदाहरण
- GBrain की extraction accuracy में सुधार: 1 लाख से अधिक belief extractions में "यह दावा किसने किया" को 35% मामलों में गलत पहचानने की समस्या को 17 tests के ज़रिए fix किया गया, ताकि बाद की कोई version उस स्तर से नीचे न गिर सके।
- Superpowers का TTY test: AI agent द्वारा 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 और medical domains तक सीमित 90% test coverage अब एक व्यक्ति की रोज़मर्रा की कार्यशैली बन सकती है, और नतीजतन एक अकेला developer जितनी जटिल software system बना सकता है, उसकी सीमा नाटकीय रूप से बढ़ गई है। हालांकि, यह लेख अपने open source projects (Superpowers, GBrain) के प्रचार का तत्व भी रखता है, और कुछ statistical references (जैसे GPT-5.5) की स्वतंत्र पुष्टि अभी आवश्यक है; इसलिए इसे आलोचनात्मक दृष्टि से पढ़ना भी ज़रूरी है।
1 टिप्पणियां
https://www.youtube.com/watch?v=mJ2GZRV63TE
sqliteकी तुलना में 4 गुना ज़्यादा LOC के साथ RoR ब्लॉग बनाने वाले व्यक्ति...