अगर आपको लगता था कि कोड लिखने की गति ही समस्या है, तो असल में उससे भी बड़ी समस्या है

• AI coding tools डेवलपमेंट की गति बढ़ाते हैं, ऐसा कहा जाता है, लेकिन वास्तविक bottleneck कोड लिखना नहीं बल्कि संगठन की अक्षम प्रक्रियाएँ हैं
• कोड उत्पादन बढ़ाने से review wait, deployment delay, अस्पष्ट requirements जैसी नॉन-डेवलपमेंट स्टेज की रुकावटें और गंभीर हो जाती हैं, और वास्तविक cycle time उल्टा बढ़ जाता है
• Eli Goldratt के Theory of Constraints के अनुसार, bottleneck न होने वाले चरण को optimize करने से सिस्टम तेज नहीं होता, बल्कि और बिगड़ता है
• जब AI द्वारा जनरेट किए गए कोड को उसका लेखक भी पूरी तरह नहीं समझता, तब incident response की surface area बढ़ती है और सिस्टम को समझकर reason कर सकने वाले लोग कम हो जाते हैं — ऐसा एक संरचनात्मक जोखिम पैदा होता है
• प्रतिस्पर्धात्मक बढ़त उस टीम को नहीं मिलती जो सबसे तेज कोड लिखती है, बल्कि उस टीम को मिलती है जो यह समझती है कि क्या बनाना है और उसे users तक पहुँचाती है

---

गलत optimization की शुरुआत

• AI coding assistant अपनाने के बाद code output 40% बढ़ा है, ऐसे दावे सामने आए हैं
  • लेकिन “यह गति आखिर किस दिशा में है?” यह सवाल गायब है
• पहले से तेज चरण, यानी code writing, में resources डालने पर पूरा सिस्टम और धीमा हो जाता है
  • bottleneck नहीं होने वाले हिस्से को तेज करने से अधूरे कोड का inventory जमा होता है, और quality गिरती है तथा अव्यवस्था बढ़ती है

bottleneck के बाहर optimize करने से सिस्टम और खराब होता है

• 1984 में Eli Goldratt के उपन्यास The Goal में प्रस्तुत Theory of Constraints का मुख्य विचार यह है: हर सिस्टम में ठीक एक bottleneck होता है, और पूरे throughput का निर्धारण उसी bottleneck की capacity से होता है
• bottleneck न होने वाले चरण को optimize करने से सिस्टम तेज नहीं होता, बल्कि अधूरे काम का inventory ही बढ़ता है, जिससे lead time बढ़ता है, भ्रम फैलता है और quality गिरती है
• उदाहरण के तौर पर, अगर station A widgets को तेजी से बनाता है लेकिन bottleneck station B की processing speed वही रहती है, तो A और B के बीच बस अनप्रोसेस्ड widgets का ढेर लग जाता है

“कोड output 3 गुना” होने पर वास्तव में क्या होता है

• डेवलपर्स पहले से कहीं तेज PR बना रहे हैं, लेकिन reviewers की संख्या वही है, इसलिए PR review queue में एक दिन, दो दिन, या एक हफ्ते तक पड़े रहते हैं
• लेखक तब तक अगले AI-assisted feature पर context switch कर चुका होता है, इसलिए 8 दिन पहले लिखे कोड पर आए review comments का जवाब देते समय उसे वह कोड लगभग याद नहीं रहता
• reviews इतने बढ़ जाते हैं कि ठीक से पढ़े बिना approve कर देने वाले rubber-stamp reviews होने लगते हैं
• CI को 45 मिनट लगते हैं, flaky tests की वजह से fail होने पर rerun करना पड़ता है, deployment pipeline meeting में बैठे owner की manual approval का इंतज़ार करती है, और feature staging में 3 दिन तक पड़ा रहता है
• डेवलपर तब तक 2 और PR खोल चुका होता है, WIP (Work In Progress) तेज़ी से बढ़ता है, और सब लोग 6-6 चीज़ें एक साथ कर रहे होते हैं जबकि कुछ भी पूरा नहीं होता
• कोड ज़्यादा बन रहा है लेकिन software कम ship हो रहा है; cycle time खराब हो चुका है, फिर भी dashboard पर productivity 40% बढ़ी हुई दिखती है
• AI-generated code का अतिरिक्त जोखिम यह है कि जिसने उसे “लिखा” है, उसने वास्तव में लिखा नहीं बल्कि prompt देकर सरसरी नज़र डाली होती है; इसलिए रात 2 बजे production incident होने पर न on-call engineer और न prompt लिखने वाला उस कोड को समझा पाता है
• कोड बढ़ना और समझ कम होना productivity gain नहीं, बल्कि एक ज़्यादा सुंदर dashboard के साथ लगा time bomb है

वास्तविक bottleneck 1: क्या बनाना है, यही नहीं पता

• PM ने 2 महीने से असली users से बात नहीं की, और requirements Jira ticket की 3 लाइनों और एक Figma link के रूप में पहुँचती हैं
• इंजीनियर्स हर दिन 50 तरह के micro-decisions — behavior, edge cases, error handling — बिना किसी स्पष्ट spec के अनुमान से लेते हैं
• एक टीम ने sales person द्वारा Slack में भेजी गई उस बात के आधार पर 6 हफ्ते तक एक feature बनाया जो शायद किसी संभावित ग्राहक ने किसी call में कही थी; अंत में उस ग्राहक ने खरीदारी नहीं की, और वह feature सिर्फ 11 लोगों ने इस्तेमाल किया, जिनमें 9 internal QA थे
• code writing को तेज करने से सिर्फ गलत चीज़ को जल्दी बनाने की गति बढ़ती है, यानी आप बस अनुमान लगाने को automate कर रहे हैं
• bottleneck असल में समस्या की समझ है, और इसे तेज typing से हल नहीं किया जा सकता

वास्तविक bottleneck 2: कोड “पूरा” होने के बाद की हर चीज़

• अधिकांश संगठनों में code writing पूरी यात्रा का सिर्फ लगभग 20% है, बाकी 80% समय कोड अलग-अलग queues में इंतज़ार करता है
• ऐसे उदाहरण मौजूद हैं जहाँ एक feature दोपहर भर में लिखा गया, लेकिन production तक पहुँचने में 2 महीने लग गए
• PR review, CI, staging, QA, security review, product approval, deployment window, canary rollout जैसी लंबी handoff, wait और queue की शृंखला मौजूद रहती है
• ज़्यादातर समय कोड चलता नहीं, बल्कि किसी के देखने, pipeline के चलने, और मौजूद रहने की अनुमति मिलने का इंतज़ार करता है
• तेज़ी से ship करने के लिए आपको उन बिंदुओं को ढूँढना होगा जहाँ काम इंतज़ार करता है, और actual work time की तुलना में queue wait time का ratio मापना होगा

वास्तविक bottleneck 3: deployment trust का दुष्चक्र

• जब tests flaky हों, observability खराब हो, और canary process पर किसी को भरोसा न हो, तो टीमें deployment से डरती हैं
• डर की वजह से changes को बड़ी releases में bundle किया जाता है; इससे risk और बढ़ता है, deployment और डरावना बनता है, और फिर चीज़ें और बड़े batches में bundle होती हैं — यह डर का vicious cycle है
• इसमें अगर और तेज code output जोड़ दिया जाए, तो कोड बढ़ेगा लेकिन deployment culture उतना ही भयभीत रहेगा; नतीजा यह कि batches और बड़े होंगे और release frequency और कम हो जाएगी

वास्तविक bottleneck 4: launch के बाद feedback की कमी

• feature बनाकर release करने के बाद न ठीक analytics होती है, न post-launch user interviews, और न ही कोई यह देखता है कि वह feature वास्तव में समस्या हल कर रहा है या नहीं
• अगला feature भी अनुमान, उसके बाद वाला भी अनुमान — पूरी product roadmap feedback के बिना लगाए गए अनुमानों की श्रृंखला बन जाती है
• तेज code output बस “बनाओ, रिलीज़ करो, कंधे उचकाओ” cycle को और तेज़ घुमाता है

वास्तविक bottleneck 5: calendar ही load-bearing wall है

• कभी-कभी bottleneck तकनीकी नहीं होता, बल्कि decision-making के लिए ज़रूरी meetings, एक महीने से बातचीत न करने वाली 3 teams के बीच API contract पर सहमति, या हर महत्वपूर्ण design के लिए single approval point बने architect का 2 हफ्तों का backlog होता है
• 6 हफ्ते चलने वाली quarterly planning process की वजह से urgent काम भी 5 हफ्ते इंतज़ार करता है
• वास्तव में ऐसे मामले होते हैं जहाँ feature सिर्फ इसलिए release नहीं हो पाता क्योंकि “हम छुट्टी पर गए व्यक्ति के साथ meeting का इंतज़ार कर रहे हैं”
• यह coordination की समस्या, मानवीय समस्या, और राजनीतिक समस्या है; इसका code writing speed से कोई लेना-देना नहीं

इसकी जगह क्या करना चाहिए

• value stream mapping: किसी एक feature को idea से production तक track करें, और हर चरण में लगा समय तथा चरणों के बीच का wait time दर्ज करें
• cycle time मापें: code lines, merged PRs, या story points नहीं, बल्कि commit से production तक और user के इस्तेमाल तक पहुँचने में लगा समय मापना चाहिए
• waiting state हटाएँ: अगर PR review में 2 दिन लगते हैं, तो pair programming, छोटे PR, dedicated review time, asynchronous review norms जैसे उपाय अपनाएँ। अगर deployment manual approval पर अटका है, तो उसे automate करें या कम से कम Slack button में बदलें
• शुरू करना रोकें, पूरा करने पर ध्यान दें: WIP limits किसी कारण से होती हैं; प्रगति पर चल रही 10 चीज़ों से पूरी हुई 3 चीज़ें बेहतर हैं। हर in-progress item context-switching cost लाता है
• काम करने वालों से बात करें: डेवलपर्स पहले से जानते हैं कि bottleneck कहाँ है; वे standup में शिकायत करते हैं और Slack में महीनों से memes बना रहे हैं। उन्हें बस लगा कि कोई सुन नहीं रहा

मुख्य निष्कर्ष

• VP को “code output 40% बढ़ा” कहने के बजाय यह कहना चाहिए था: “हमारे value stream analysis से पता चला है कि features चरणों के बीच औसतन 9 दिन इंतज़ार कर रहे हैं, और हम इसे आधा करेंगे”
• प्रतिस्पर्धात्मक बढ़त उस टीम को मिलती है जो सबसे तेज कोड नहीं लिखती, बल्कि जो यह समझती है कि क्या बनाना है, उसे बनाती है, और users तक पहुँचाती है
• bottleneck keyboard नहीं है