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

 (apenwarr.ca)
17 पॉइंट द्वारा GN⁺ 2026-03-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • जैसे-जैसे संगठन में 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

संबंधित पढ़ाई

2 टिप्पणियां

 
bbulbum 2026-03-19

जब मैंने पहली बार go fmt देखा: अरे, format को अपनी पसंद के हिसाब से क्यों नहीं कर सकता..!

अब: format में पसंद की ज़रूरत ही क्यों है?
 
GN⁺ 2026-03-18
Hacker News की राय

  • हो सकता है कि review की ज़रूरत ही न पड़े
    review को left shift करके code design session में बदल दिया जाए, daily में issues उठाए जाएँ, और मुश्किल हिस्सों को pair programming से सुलझाया जाए, तो review के ज़्यादातर मकसद ख़त्म हो जाते हैं
    बचे हुए 10% जैसे variable names, whitespace, pattern जैसी चीज़ें linter से automate की जा सकती हैं
    आख़िर में सबसे अहम बात है ऐसी trust-based team culture बनाना, जहाँ team की सहमति वाले code पर भरोसा करके उसे लिखा जा सके

    • जैसे कहा जाता है, “planning पर कुछ घंटे खर्च करो तो coding के कुछ मिनट बचते हैं”
      हर architecture को whiteboard पर design नहीं किया जा सकता
      असली implementation के दौरान ही problems समझ में आती हैं
      बहुत कम बार चीज़ें पूरी तरह plan के मुताबिक़ चलीं। आख़िरकार iterative architecture meetings की ज़रूरत पड़ती है, लेकिन फिर वही weekly meetings के दलदल में बदल जाता है
    • मैंने उन engineers को भी यह तरीका छोड़ते देखा है जिन्हें मैं बहुत मानता था, जब उन्होंने coding agents से PR अपने-आप generate करवाने शुरू किए
      जब लोग अपने लिखे code को भी review नहीं करते, तो बनाई हुई trust पल भर में टूट जाती है
    • इस लेख का मूल बिंदु भी आख़िरकार trust का system ही है
      Toyota Production System की तरह अगर QA stage हटानी है, तो ऐसा भरोसा चाहिए कि कोई भी member defect देखते ही तुरंत रुकवा सके
      review pipeline सिर्फ़ problems छिपाती है और speed कम करती है
    • “review को left shift करो, उसे design session कहो, daily में issue उठाओ, और pair programming से solve करो”
      यह एक वाक्य अपने-आप में नरक की परिभाषा लगता है
    • हम नए लोगों से कहते हैं, “हम आप पर भरोसा करते हैं। लेकिन आपका phone number हमारे पास है”
      यह काफ़ी अच्छा काम करता है। लोग ख़ुद tests लिखते हैं, और manual verification भी साथ करते हैं
      हमने ऐसा safety net भी बनाया है जिससे ग़लत deploy को 10 मिनट में rollback किया जा सके

  • code review एक volunteer's dilemma है
    क्योंकि “मैंने बहुत PR review किए” की तुलना में “मैंने बहुत features release किए” performance evaluation में ज़्यादा गिना जाता है
    आख़िरकार लोग review में तभी सक्रिय होते हैं जब उसका सीधा असर उनके अपने काम पर पड़ता है
    लेकिन code लचीला होता है, इसलिए fast merge और बाद की fixes कभी-कभी ज़्यादा तेज़ convergence ला सकती हैं

    • कुछ reviewers, team lead की तरह, team output की ज़िम्मेदारी महसूस करते हैं
      ख़ासकर bugs पहले पकड़कर on-call stress कम करने की motivation भी बड़ी होती है
    • juniors को मैं सलाह देता हूँ कि वे हर PR review करें
      समझ न भी आए तो सवाल छोड़ना सीखने में बहुत मदद करता है
      अगर leader बनना है, तो code और design documents review बहुत करने चाहिए
    • दिलचस्प बात यह है कि ज़्यादातर developers जिन दो चीज़ों को सबसे अहम मानते हैं — code review और code deletion — उनका कोई reward नहीं मिलता

  • इस लेख ने मेरी intuition और experience को साफ़ शब्दों में समेट दिया
    मुझे Tailscale का product पहले से पसंद था, लेकिन अब शायद मैं उसके CEO का भी fan बन जाऊँ
    लेखक Avery का धन्यवाद, और मैं यह लेख व्यापक रूप से share करने वाला हूँ

  • Valve उन गिनी-चुनी companies में से है जो communication bandwidth की limits समझती हैं
    organization जितनी बड़ी होती है, communication overhead exponentially बढ़ता है

    • मुझे लगता है यह बात सबसे पहले Jeff Bezos ने समझी थी
      बाकी companies को भी अब तक समझ जाना चाहिए था, लेकिन अब भी ऐसा नहीं है

  • हैरानी होती है कि review 5 घंटे के भीतर हो जाता है
    ज़्यादातर जगह यह कई दिनों में होता है
    लेकिन अगर ऐसी culture हो जहाँ हर developer bug देखते ही तुरंत रुक सके, तो शायद review की ज़रूरत ही न रहे
    हक़ीक़त यह है कि release target miss होने पर नुकसान व्यक्ति को उठाना पड़ता है

    • पिछली company में review में कई दिन लगते थे, लेकिन code quality ठीक थी
      मौजूदा company में review कुछ मिनटों में हो जाता है, लेकिन technical debt तेज़ी से बढ़ रही है
    • एक FAANG team में review SLA 4 घंटे था
      समय सीमा पार होते ही अपने-आप “review pending” message आ जाता था
      सब कुछ मापा जाता था, और performance pressure बहुत ज़्यादा था
    • एक समय मुझे समझ आया कि review ही bottleneck है, और मैंने team code reviews को तुरंत handle करना शुरू कर दिया
      अगर team size ठीक-ठाक हो, तो यह आदत सीखी भी जा सकती है और फैल भी सकती है
    • पेज के नीचे जाकर पता चला कि लेखक Tailscale का CEO है
    • अब तक मैंने कोई ऐसा project नहीं देखा जहाँ reviews को गंभीरता से लिया जाता हो
      न business, न developers इसकी ज़्यादा परवाह करते हैं

  • review में value-to-effort ratio को अक्सर नज़रअंदाज़ किया जाता है
    अगर review वास्तव में quality नहीं बढ़ा रहा, तो वह समय की बर्बादी है
    बारीक बहसों में पड़ने के बजाय सिर्फ़ “क्या यह काम करता है?” देखकर जल्दी merge करना ज़्यादा efficient है
    बाद के commits में उसे बेहतर किया जा सकता है
    review एक छोटा checkpoint होना चाहिए जो सिर्फ़ दिशा सही है या नहीं, यह देखे

  • “reviewer का काम review को ख़त्म करना है” — इस बात से मैं पूरी तरह सहमत हूँ

  • लेख serialized process को आधार मानता है, लेकिन असल में काम parallel में चलता है
    अगर कई bugs एक साथ handle किए जा रहे हों, तो review delay इतनी बड़ी problem नहीं होती
    असली बात simultaneous work count (N) को control करने की है

    • इसके लिए मैंने एक queueing theory calculator बनाया
      लिंक
      PR review जितना धीमा होता है, context switching cost उतनी बढ़ती है
      calculation के नतीजे बताते हैं कि review speed बढ़ाने से productivity काफ़ी बेहतर होती है

  • “reviewer का लक्ष्य review को अनावश्यक बना देना होना चाहिए” — इस बात से सहमति है,
    लेकिन जब trust की सीमा company के बाहर तक फैलती है, तब बात बदल जाती है
    उदाहरण के लिए, अगर npm update से malicious code deploy हो जाए, तो बाद की response बहुत देर से आएगी
    trust-based system होने पर भी, कभी-कभी ऐसे बिंदु होते हैं जहाँ human verification ज़रूरी होती है

  • managers productivity पर ज़ोर देते हैं, लेकिन साथ ही speed कम करने वाले process भी बनाए रखते हैं
    यह जटिल समस्या है, इसलिए इसे बस अच्छा या बुरा कहना आसान नहीं है

    • इससे “How complex systems fail” की Rule 9 याद आती है
      operators को productivity और safety दोनों की ज़िम्मेदारी उठानी पड़ती है
      accident से पहले productivity पर ज़ोर होता है, और accident के बाद safety पर
      outsiders इस दोहरी भूमिका के संतुलन को अक्सर अच्छी तरह नहीं समझते
      संबंधित लिंक