हर review चरण रफ्तार को 10 गुना धीमा कर देता है

• जैसे-जैसे संगठन में approval और review चरण बढ़ते हैं, काम की गति घातीय रूप से धीमी हो जाती है — इसे समझाते हुए उदाहरण दिए गए हैं कि हर approval चरण लगभग 10 गुना देरी पैदा करता है
• AI coding tools भले ही code लिखने की गति नाटकीय रूप से बढ़ा दें, उसके बाद की review pipeline की latency कम नहीं होती, इसलिए कुल speed improvement बहुत सीमित रहती है
• W. E. Deming की manufacturing quality philosophy को software पर लागू करते हुए, यह तर्क दिया गया है कि QA चरण जोड़ने का तरीका उल्टा quality और speed दोनों को खराब करता है
• review को कम करना चाहिए, लेकिन साथ ही उसकी जगह modularity और trust-आधारित quality culture लानी होगी; असली बात ऐसी structural improvement है जो review को ही अनावश्यक बना दे
• AI युग में छोटे teams के पक्ष में परिस्थितियाँ हैं, और छोटे, सुंदर components को जोड़कर organization और systems को फिर से design करने की ज़रूरत है

---

review चरण 10 गुना delay पैदा करने का नियम

• network effect के नियम की तरह, team का आकार बढ़ने पर coordination overhead पैदा होता है; team को दोगुना कर देने से speed दोगुनी नहीं हो जाती
• कई दशक पहले सुना गया एक अनुभवजन्य नियम: हर बार एक review चरण बढ़ने पर process 10 गुना धीमा हो जाता है
• इसका कोई सख्त theoretical basis नहीं है, लेकिन वास्तविक दुनिया में यह बार-बार दिखाई देता है
• यहाँ मापा जाने वाला समय effort नहीं, बल्कि wall clock time है, और इस अतिरिक्त समय का अधिकांश हिस्सा waiting time होता है
• ठोस उदाहरण:
  • साधारण bug fix coding: 30 मिनट
  • बगल में बैठे सहकर्मी की code review: 300 मिनट (लगभग 5 घंटे, आधा दिन)
  • architect team से design document approval: 50 घंटे (लगभग 1 सप्ताह)
  • किसी दूसरे team के schedule में चढ़ाना (जैसे customer feature request): 500 घंटे (12 सप्ताह, 1 fiscal quarter)
• अगला चरण 10 quarters (लगभग 2.5 साल) भी अवास्तविक नहीं है; Tailscale जैसी अपेक्षाकृत छोटी company में भी product direction बदलने पर इस स्तर की देरी हो सकती है

AI इस समस्या को हल नहीं कर सकता

• अगर Claude 30 मिनट का coding काम 3 मिनट में कर दे, तब भी आप या तो बचे हुए 27 मिनट सीधे AI के साथ iterative review में लगाएंगे, या unverified code reviewer को सौंप देंगे
• reviewer को तब भी 5 घंटे लगेंगे, और अगर आपने ऐसा code भेजा जिसे आपने खुद पढ़ा भी नहीं, तो reviewer नाराज़ होगा
• कहा जाता है कि agentic coding की असली value 1 सप्ताह के बड़े project को कुछ घंटों में पूरा करने में है, लेकिन result इतना बड़ा होता है कि reviewer उसे एक बार में देख ही नहीं सकता
  • उसे छोटे हिस्सों में बाँटना पड़ेगा, और हर हिस्से के लिए 5 घंटे का review cycle बनेगा
  • design document के बिना intentional architecture भी नहीं होगा, इसलिए अंततः बात design review meeting तक पहुँचेगी
  • नतीजा यह कि 2 घंटे में पूरा हुआ project फिर से 1 सप्ताह पर लौट आता है

एकमात्र रास्ता review कम करना है

• Singularity theory की बुनियादी धारणा यह है कि system लगातार और अधिक intelligent systems बनाता है, और हर improvement unit पर लगने वाला समय 0 के करीब पहुँच जाए तो explosive growth होती है
• इस theory पर भरोसा न करने का कारण यह है कि किसी भी चीज़ को पूरा करने में लगने वाले समय का अधिकांश हिस्सा वास्तविक work time नहीं, बल्कि wall clock time — यानी wait और delay होता है
• latency को brute force से हराया नहीं जा सकता

क्या review किए बिना काम चल सकता है?

• pipeline का पहला चरण (AI-generated code) तेज हो गया है, लेकिन उसके बाद के review चरण bottleneck हैं — यह बात अब बहुत लोग पहचान रहे हैं
• सहज समाधान लगता है: review बंद कर दो → अगर output घटिया भी हो, तो 100 गुना सस्ता होने पर सिर्फ 1% value भी break-even करा सकती है
• लेकिन इस तर्क की नींव में काफी मूर्खतापूर्ण assumptions हैं
• AI Developer's Descent Into Madness:
  1. prototype चौंका देने वाली तेजी से बनता है → superpower जैसा एहसास
  2. prototype में bug आता है → AI को fix करने को कहते हैं
  3. हर बदलाव के साथ जितना fix होता है, उतने ही नए bug पैदा हो जाते हैं
  4. भ्रम होता है कि अगर AI agent अपना code review खुद कर ले, तो वह अपने bug पकड़ लेगा
  5. फिर आप खुद को agents के बीच data सीधे पास कराते हुए पाते हैं
  6. महसूस होता है कि agent framework चाहिए
  7. agent से ही agent framework लिखवाते हैं
  8. फिर वापस चरण 1 पर लौट आते हैं
• Claude Code कुछ ही महीने पहले उपयोगी बना है, इसलिए यह चक्र हाल में ही शुरू हुआ है, और बहुत से साथी व सम्मानित लोग इस cycle में फँसे हुए हैं

हम review करते ही क्यों हैं

• company के बढ़ने पर collaboration, review और management चरण बढ़ते हैं → उद्देश्य गलतियों को रोकना होता है, क्योंकि scale बढ़ने के साथ गलती की लागत भी बढ़ती है
• एक समय ऐसा आता है जब नए feature की औसत अतिरिक्त value, उससे पैदा होने वाले नए bug की औसत हानि से कम हो जाती है
• feature की value बढ़ाने का कोई आसान तरीका नहीं होता, इसलिए दिशा नुकसान घटाने की ओर मुड़ जाती है
• inspection और control बढ़ाने से speed धीमी पड़ती है, लेकिन quality monotonically increasing लगती है — मानो यही continuous improvement की नींव हो
• लेकिन “ज़्यादा inspection और control” quality सुधारने का एकमात्र तरीका नहीं है, और यह खतरनाक तरीका भी है

“quality assurance (QA)” उल्टा quality घटा देता है

• W. E. Deming द्वारा जापानी automobile manufacturing में लोकप्रिय की गई quality philosophy का संदर्भ
• factory में QA चरण की समस्या: widget बनाना → inspection/QA → reject हटाना → छूट न जाए इसलिए दूसरा QA जोड़ना
• साधारण mathematical model में यह तर्कसंगत लगता है (अगर हर QA चरण 90% defect पकड़ता है, तो 2 चरणों से 100 गुना कमी)
• लेकिन agentic humans वाले माहौल में incentives बिगड़ जाते हैं:
  • दूसरा QA team पहले QA team का मूल्यांकन करने लगता है → अपने साथियों की नौकरी पर असर डालने वाली चीज़ें ढूँढने का प्रोत्साहन नहीं होता
  • पहला QA team सोचता है कि दूसरा team पकड़ ही लेगा, इसलिए अपना effort घटा देता है
  • widget बनाने वाला team भी QA team के भरोसे अपनी self-checking ढीली कर देता है → 20% slow होना, 10% rejection rate से बेहतर लगने लगता है
  • quality सुधार के लिए full engineering redesign बहुत महँगा लगने के कारण टाल दिया जाता है
• Toyota Production System ने QA चरण पूरी तरह हटाकर, हर व्यक्ति को “line stop” button दिया
• अमेरिकी automobile manufacturers ने भी वही button लगाया, लेकिन किसी ने दबाया ही नहीं → नौकरी जाने का डर

trust

• जापानी system की सफलता और अमेरिकी system की विफलता के बीच का अंतर trust था
• व्यक्तियों के बीच trust: manager सचमुच हर defect के बारे में जानना चाहता है, और defect मिले तो line रोकनी चाहिए — इस पर भरोसा
• managers के बीच trust: leadership quality को सच में गंभीरता से लेती है — इस पर भरोसा
• leadership के भीतर trust: अगर सही systems और incentives दिए जाएँ, तो लोग उच्च-गुणवत्ता का काम करेंगे और अपने defect खुद पहचानेंगे
• एक और शर्त: यह trust कि system वास्तव में काम करता है — और उसके लिए पहले एक काम करने वाला system होना चाहिए

fallibility

• AI coders अक्सर खराब code लिखते हैं, और इस मामले में वे मानव programmers जैसे ही हैं
• Deming का approach कोई जादुई समाधान नहीं देता → engineers को पूरे system में bottom-up तरीके से quality design करनी होती है
• हर problem पर पूछना चाहिए, “यह हुआ कैसे?” और postmortem तथा Five Whys के जरिए root cause ढूँढकर उसे ठीक करना चाहिए
• “coder ने गलती की” root cause नहीं, बल्कि एक symptom है → वह structural कारण ढूँढना चाहिए जिससे coder गलती कर सका
• code reviewer की असली भूमिका code review करना नहीं, बल्कि अपने review comments को ही अनावश्यक बना देना है
  • system को इस तरह बेहतर बनाना कि उस तरह की टिप्पणी भविष्य में आए ही नहीं
  • लक्ष्य ऐसी स्थिति होनी चाहिए जहाँ review की जरूरत ही न रहे
• उदाहरण: “go fmt” बनाने वाले लोग → spacing से जुड़ी code review comments को हमेशा के लिए खत्म कर दिया → यही असली engineering है
• जब तक review कोई गलती पकड़ता है, तब तक गलती हो चुकी होती है → root cause तब तक पीछे छूट चुका होता है

modularity

• review pipeline (QA चरण) काम नहीं करती; यह speed घटाते हुए root cause को छिपा देती है, जिससे कारण को ठीक करना और कठिन हो जाता है
• AI coding का आकर्षण यह है कि pipeline का पहला चरण बेहद तेज हो गया है — superpower जैसा एहसास
• संभव है कि 20 साल की code review culture में छिपी समस्याओं को हल करने और उसकी जगह वास्तविक quality culture लाने का अब पर्याप्त प्रोत्साहन पैदा हो गया हो
• optimists आधे सही हैं: review चरण घटाने की ज़रूरत है, लेकिन बिना किसी replacement के घटाने पर बात Ford Pinto या हाल के Boeing aircraft जैसी स्थिति तक पहुँच सकती है
• जैसे Deming manufacturing में लाए थे, वैसे ही एक complete package वाला table flip चाहिए — “company-wide quality” system को आधा-अधूरा अपनाया नहीं जा सकता
• review हटाते समय उसे एक साथ अनावश्यक भी बनाना होगा
• छोटे स्तर पर नए system को पूरी तरह अपनाना संभव है:
  • इसकी तुलना पुराने अमेरिकी automobile makers द्वारा Japanese suppliers के उच्च-गुणवत्ता parts खरीदने से की जा सकती है
  • अगर parts अच्छी तरह बने हों, तो दूसरी जगहों के QA चरण हटाए जा सकते हैं → “parts assembly” की complexity बहुत घट जाती है
• छोटी और सुंदर चीज़ों को जोड़कर बड़ी और सुंदर चीज़ बनाई जा सकती है
• एक-दूसरे पर भरोसा करने वाली छोटी teams, अपने लिए quality का अर्थ क्या है, यह समझते हुए individual components बनाती हैं
• customer teams भी अपने लिए quality का अर्थ क्या है यह स्पष्ट रूप से बताती हैं → quality bottom-up तरीके से फैलती है

छोटे teams और AI युग की organization design

• छोटे startups नई दुनिया में अधिक लाभ में हो सकते हैं, क्योंकि कम लोगों का मतलब है कि review चरण शुरू से ही कम हैं
• कुछ startups जल्दी high-quality components बनाना सीखेंगे, बाकी असफल होंगे → natural selection से quality
• बड़ी companies में slow review systems जमे हुए हैं, इसलिए उन्हें हटाने पर पूरी अव्यवस्था फैल सकती है
• company का आकार चाहे जो हो, engineering teams छोटी की जा सकती हैं और teams के बीच interfaces अधिक स्पष्ट रूप से define किए जा सकते हैं
• एक ही company में कई teams द्वारा एक ही component को प्रतिस्पर्धात्मक रूप से develop करने वाला model संभव है
  • हर team कुछ लोगों और coding bots से बनी होगी
  • 100 तरीके आज़माकर सबसे अच्छा चुना जाएगा → evolution से quality
  • code सस्ता है, लेकिन अच्छे ideas अब भी महँगे हैं → नए ideas पहले से तेज़ी से आज़माए जा सकते हैं
• monolith-microservices continuum में कोई नया optimum उभर सकता है
  • microservices बहुत छोटे हो जाने के कारण बदनाम हुए, लेकिन मूल शब्दावली में “micro” service का अर्थ था ऐसा आकार जिसे “two-pizza team” बना और चला सके
  • AI युग में यह शायद “one pizza और थोड़ा token” जितना रह जाए
• नई तेज coding के साथ module boundaries को भी तेज़ी से experiment किया जा सकता है
  • feature अब भी कठिन हैं, लेकिन refactoring और automated integration testing AI की ताकत वाले क्षेत्र हैं
  • जिन modules को पहले अलग करने से डरते थे, अब उन्हें अलग करके देखा जा सकता है → code lines बढ़ेंगी, लेकिन दोनों तरफ maintenance करने वाले बड़े team के coordination overhead की तुलना में यह सस्ता है
• हर team के पास कुछ न कुछ बहुत बड़ा monolith और बहुत अधिक review चरण होते हैं
• Singularity तक पहुँचना ज़रूरी नहीं; फिर भी हम कहीं बेहतर दुनिया को engineer कर सकते हैं → यह समस्या हल की जा सकती है
• कुंजी है trust