[बॉटलनेक का स्थानांतरण] जब कोड लगभग मुफ्त हो जाए, तो सॉफ्टवेयर इंजीनियरिंग का बॉटलनेक कहाँ चला गया? AI युग में सॉफ्टवेयर इंजीनियरिंग का परिवर्तन — मैं धीरे-धीरे AI सीखता हूँ 173
जब कोड लगभग मुफ्त हो जाए, बाधा अब मांग, एकीकरण, प्रमाणीकरण और समन्वय में चली जाती है
जब कोड उत्पादन लगभग मुफ्त हो जाए, तो सॉफ्टवेयर डिलीवरी की बाधा “कोड लिखने” से बाहर चली जाती है: सही सवाल परिभाषित करना, टुकड़ों को एक कामकाजी पूर्णता में जोड़ना, यह सत्यापित करना कि वास्तव में यह सही है, और संगठन को समन्वित करना। यह सॉफ्टवेयर उद्योग में सीमा सिद्धांत (Theory of Constraints) की एक बार फिर से दोहराई गई घटना है। निर्माण उद्योग ने 40 साल पहले इस राह पर कदम रखा था: जब भी कोई चरण सस्ता हो जाता है, बाधा गायब नहीं होती — वह बस अगले सबसे महंगे चरण में चली जाती है। इस बात को समझने से आप एक सामान्य भ्रम को समझ सकते हैं: AI प्रोग्रामिंग टूल्स पूरी कंपनी में लागू हो गए हैं, कोड लिखना स्पष्ट रूप से तेज हो गया है, लेकिन डिलीवरी की गति में कोई खास बदलाव नहीं आया।
एक निर्माण समूह के CIO ने मुझे अपने पिछले छह महीने के डेटा दिखाए। IT टीम में 80 से अधिक लोग हैं, जिन्होंने AI प्रोग्रामिंग टूल्स को पूरी तरह से अपना लिया है। कोड उत्पादन की दृष्टि से, प्रति व्यक्ति कमिट और मर्ज रेट में 30% से अधिक की वृद्धि हुई है। लेकिन बिजनेस साइड का अनुभव बिल्कुल अलग है: एक इंटेलिजेंट स्केड्यूलिंग फीचर को लेकर, शुरुआत से लेकर लाइव तक अभी भी 3 महीने से अधिक का समय लगता है। उन्होंने मान लिया था कि टूल्स 2x स्पीडअप लाएंगे, लेकिन उन्हें बस “कोड जल्दी लिखने” की क्षमता मिली। उनकी बात सीधी थी: “मैंने कुछ मिलियन डॉलर लाइसेंस पर खर्च किए, और मुझे मिला — डेवलपर्स और बिजनेस दोनों अधिक तनावग्रस्त।”
उसने बॉटलनेक की स्थिति को गलत ढंग से अनुमान लगा लिया। उसका वास्तविक बॉटलनेक कुछ और था: हर नया फीचर MES, ERP, क्वालिटी चेक सिस्टम, शॉप फ्लोर टर्मिनल, और एक प्रायोजक रिपोर्टिंग फ्रेमवर्क के माध्यम से गुजरना पड़ता था—एकीकरण और समन्वय ने अधिकांश समय खा लिया; जबकि AI द्वारा उत्पन्न कोड के सामने किसी भी औपचारिक स्वीकृति बाधा और उत्पादन वातावरण के बीच नहीं थी। जितना तेज़ी से कोड लिखा जाए, वह केवल गलत बॉटलनेक के पीछे लाइन में खड़ा होता है। # एक, निर्माण: 40 साल पहले से पता था: बॉटलनेक घूम जाता है वर्तमान को समझने के लिए, पहले 40 साल पुरानी निर्माण उद्योग की आँखों से देखें। 1984 में, इज़राइली सलाहकार एलियाहू गोल्ड्रैट, जो एक भौतिक विज्ञानी थे, ने एक उपन्यास “द गोल” लिखा, जिसमें एक दिवालिया होने के कगार पर खड़े फैक्ट्री मालिक कैसे अपनी फैक्ट्री बचाता है, इसकी कहानी है। पूरी किताब का केंद्र एक ही वाक्य है: किसी भी प्रणाली का उत्पादन, उसके सबसे संकीर्ण चरण (प्रतिबंध, यानी बॉटलनेक) द्वारा निर्धारित होता है। गैर-बॉटलनेक चरणों को चौड़ा करने से कुल उत्पादन में कोई फर्क नहीं पड़ता; केवल बॉटलनेक को ही चौड़ा करने से पूरी प्रणाली तेज़ होती है। और जैसे ही आप बॉटलनेक को चौड़ा करते हैं, वह तुरंत अगले सबसे संकीर्ण स्थान पर चला जाता है। यही सीमा सिद्धांत (Theory of Constraints, TOC) है।
बाद के 40 वर्षों के उत्पादन क्षेत्र के स्वचालन का इतिहास, लगभग एक “बॉटलनेक का स्थानांतरण” का इतिहास है। जब सीएनसी मशीनों ने काटने की लागत कम कर दी, तो बॉटलनेक मोडल बदलने और गुणवत्ता जांच की ओर चला गया; जब लचीली उत्पादन लाइनों ने मोडल बदलने को तेज कर दिया, तो बॉटलनेक उत्पादन योजना और आपूर्ति श्रृंखला समन्वय की ओर चला गया; जब MES ने उत्पादन योजना को अधिक सटीक बना दिया, तो बॉटलनेक मांग भविष्यवाणी और बहु-कारखाना नियोजन की ओर चला गया। हर बार जब एक चरण स्वचालित होता है, तो अगला चरण उभर आता है। स्वचालन कभी बॉटलनेक को नहीं मिटाता, यह केवल बॉटलनेक की स्थिति बदल देता है। यह नियम केवल उत्पादन क्षेत्र का नहीं है। 2026 के जुलाई में, a16z के पॉडकास्ट “Software in the Age of Agents” में, पूर्व माइक्रोसॉफ्ट विंडोज अध्यक्ष स्टीवन सिनोफ्स्की ने उद्यम सॉफ्टवेयर के उदाहरण के साथ, इसी निष्कर्ष पर स्वतंत्र रूप से पहुंचे। उनके शब्द थे:
“The long tail got no shorter. It just got longer in a different way.”
उन्होंने Amazon कस्टमर सपोर्ट का उदाहरण दिया: फोन को हटा देना और chatbot को सीधे उत्पाद भेजने का अधिकार देना—ऐसा लगता है कि मानव शक्ति बच गई, लेकिन बैकएंड पर तुरंत यह प्रश्न उठता है कि “इसी तरह की समस्याओं को भविष्य में कैसे रोकें?”—जो फोन पर बात करने से भी अधिक जटिल है। बिल रिम्बर्समेंट प्रक्रिया भी ऐसी ही है: OCR द्वारा स्वचालित लेखांकन के बाद, फाइनेंस टीम का काम अब यात्रा प्रदर्शन अनुकूलन और डायनामिक प्राइस कंपेरिजन बन जाता है—काम गायब नहीं हुआ, बल्कि “एंट्री” से “विश्लेषण और निर्णय” पर स्थानांतरित हो गया। एक माइक्रोसॉफ्ट के वरिष्ठ कर्मचारी, a16z के साझेदार, ने Goldratt के सिद्धांत का उपयोग नहीं किया, लेकिन उन्हें निर्माण उद्योग के 40 साल पुराने निष्कर्ष के समान निष्कर्ष पर पहुँच गए। एक शॉपफ्लोर से, दूसरा एंटरप्राइज सॉफ्टवेयर से—दो स्वतंत्र मार्ग एक ही नियम की ओर इशारा करते हैं।
हालाँकि, इस नियम को एक सीमा के साथ पूरा करना आवश्यक है, ताकि इसे एक निरपेक्ष सत्य न बनाया जाए। वास्तव में कुछ बैंकनॉक्स स्थायी रूप से गायब हो गए हैं: टाइपिस्ट, टेलीफोन ऑपरेटर, लीड टाइपसेटर—इन पदों का “स्थानांतरण” नहीं हुआ, बल्कि वे वास्तव में लुप्त हो गए। यह निर्णय करने के लिए कि कोई कार्य स्थानांतरित होगा या लुप्त हो जाएगा, मुख्य बात यह है कि स्वचालन द्वारा मुक्त की गई क्षमता नए आवश्यकताओं को जन्म देती है (अर्थशास्त्र में इसे जेवन्स पैराडॉक्स कहते हैं), या केवल इस आवश्यकता को संकुचित कर देती है। उद्यम के कोर सिस्टम के चारों ओर के अधिकांश कार्य पहले वर्ग में आते हैं: जितना तेज़ी से बुक्स बनते हैं, उतना ही अधिक और विस्तृत विश्लेषण बॉस देखना चाहते हैं। इसलिए यहाँ निष्कर्ष यह नहीं है कि “स्वचालन कितने कार्यों को हटा सकता है”, बल्कि यह है कि “मानव और बजट को, स्वचालित हो चुकी परत से, नई उभरती परत पर स्थानांतरित कर दें।” (एंटरप्राइज सॉफ्टवेयर के दृष्टिकोण से लॉन्ग टेल ट्रांसफर—इसका पूर्ण विस्तार अतिरिक्त अध्याय “एंटरप्राइज सॉफ्टवेयर स्टिकनेस” में है।)
यह मामला सॉफ्टवेयर से उतना ही करीब है, जितना आप सोचते हैं। 2013 में, जीन किम ने गोल्डरैट की फैक्ट्री की कहानी को लगभग बिल्कुल वैसे ही आईटी ऑपरेशन्स में शामिल किया और “द फीनिक्स प्रोजेक्ट” लिखा: एक सीआईओ कैसे कंपनी को लगभग डुबो देने वाले आईटी विभाग को बचाने के लिए कंस्ट्रेंट थ्योरी का उपयोग करता है। इसलिए “उत्पादन के बैलेंस के दृष्टिकोण से सॉफ्टवेयर को देखना” एक पहले से सत्यापित रास्ता है, कोई अस्थायी उपमा नहीं। # द्वितीय: सॉफ्टवेयर में वापसी: कोड लिखना अब सबसे सस्ता चरण बन गया है
तीन संख्याएँ, “कोड उत्पादन लागत शून्य की ओर बढ़ रही है” इस बात को स्पष्ट करती हैं।
- Copilot: GitHub के अपने शोध से पता चलता है कि Copilot-सक्षम फ़ाइलों में लगभग 46% कोड Copilot द्वारा उत्पन्न होता है। ध्यान दें कि यह “Copilot-सक्षम फ़ाइलों के भीतर” का अनुपात है, न कि GitHub के सभी कोड का 46%।
- Stripe: इसका आंतरिक रूप से विकसित कोडिंग एजेंट “Minions” हर हफ़्ते 1,300 से अधिक PR उत्पन्न कर विलय करता है (शुरुआत में 1,000, लगातार बढ़ रहा है)। एक महत्वपूर्ण बात: हर PR को विलय से पहले मानव समीक्षा से गुज़रना पड़ता है। Stripe ने “लिखना” स्वचालित किया, लेकिन “स्वीकृति” मनुष्यों के लिए छोड़ दी — इसका उपयोग चौथे खंड में किया जाएगा।
- NVIDIA: जेन्सन हुआंग ने सार्वजनिक रूप से कहा कि 100% NVIDIA इंजीनियर Cursor जैसे AI प्रोग्रामिंग टूल इस्तेमाल कर रहे हैं, और “बिना AI के काम” NVIDIA में अब स्वीकार्य नहीं।
तीसरा: संकीर्णता चार जगहों पर पहुँच गई
इस बार, संकीर्णता चार चरणों पर केंद्रित है। हर एक, AI के लिए आने वाले कुछ सालों में असंभव है।
पहला: सही सवाल पूछना।
AI कुछ सेकंड में “आप जिस फीचर के बारे में बात कर रहे हैं” को लिख सकता है, लेकिन “आपको वास्तव में जिस फीचर की जरूरत है” को नहीं लिख सकता। ज्यादातर सॉफ़्टवेयर प्रोजेक्ट्स की विफलता का मूल कारण यह है कि बनाया गया चीज़ कोई इस्तेमाल नहीं करता—शुरुआत से ही यह स्पष्ट नहीं होता कि कौन सी समस्या हल करनी है। कोड उत्पादन सस्ता हो जाने के बाद, “एक अस्पष्ट व्यावसायिक चुनौती को एक स्पष्ट, हल करने योग्य, और हल करने लायक स्पेसिफिकेशन में तोड़ना” (problem formulation) सबसे दुर्लभ और सबसे महंगी क्षमता बन गई है। निर्माण उद्योग के साथी इसे अच्छी तरह जानते हैं: अगर प्रक्रिया रूट और इंजीनियरिंग ड्राइंग गलत हैं, तो जितना भी अच्छा और तेज़ आप मशीनों में काम करें, आप केवल बड़ी मात्रा में बर्बाद उत्पाद बना रहे होंगे।
दूसरा: सिस्टम एकीकरण।
AI “एक कोड स्निपेट”, “एक फ़ंक्शन”, “एक पेज” जैसी चीज़ें बनाने में अच्छा है। लेकिन एक लाइव सिस्टम, सैकड़ों ऐसे टुकड़ों का एकीकरण होता है, जिन्हें डेटा आदान-प्रदान करना होता है, सीमाओं को हैंडल करना होता है, सुसंगठित रहना होता है, और अपवादों का सामना करना होता है। टुकड़े बनाना सस्ता है, लेकिन उन्हें एक विश्वसनीय पूर्णता में जोड़ना महंगा है। यह लागत का मूल कारण संगठन और आर्किटेक्चर की समन्वयता में छिपा है—जिस पर कॉन्वे का नियम और टीम टोपोलॉजी ध्यान देते हैं (इस श्रृंखला के पिछले दो लेख देखें)। शुरुआत में जिस निर्माण CIO की बात की गई थी, उनका समय कोड लिखने में नहीं, बल्कि MES, ERP, क्वालिटी चेक और रिपोर्टिंग जैसी कई सिस्टम्स के इंटीग्रेशन में बीत गया।
चार: सबसे गहरी चाकू: पुष्टि, और टोयोटा का “जिडोका” हमें क्या सिखाता है
चारों बाधाओं में, सबसे अधिक गलत समझा जाने वाला है पुष्टि। बहुत से लोग इसे इस तरह समझते हैं: “चूंकि AI तेजी से कोड लिखता है, तो हम कई बार टेस्ट कर लें।” यह आधा सही है। पुष्टि क्यों महंगी हो रही है, यह समझने के लिए, हमें टोयोटा की उस अवधारणा को सही ढंग से समझना होगा जिसे सबसे ज्यादा गलत तरीके से उद्धृत किया जाता है: जिडोका (Jidoka)।
सबसे पहले, एक व्यापक रूप से फैली गलत धारणा को ठीक करते हैं। जिडोका का मतलब “AI या मशीनों द्वारा मनुष्यों को बदलना” नहीं है, और न ही “मनुष्यों को मशीन बना देना, जैसे मशीन की तरह बिना रुके काम करते रहें”। ये दोनों दिशाएँ उल्टी हैं।
“जिडोका” शब्द के शाब्दिक अर्थ में ही उत्तर छिपा है। जापानी में “自動化” (जिडोका) सामान्य स्वचालन है, लेकिन टोयोटा जानबूझकर “自働化” का उपयोग करती है — जिसमें “働” में “व्यक्ति” (人) अर्थात् मनुष्य का चिह्न है, जो “मानवीय स्पर्श वाले स्वचालन” (automation with a human touch) पर ज़ोर देता है। इसका सटीक अर्थ है: जब मशीन या उत्पादन लाइन असामान्यता पकड़ती है, तो वह स्वचालित रुक जाती है, मनुष्य हस्तक्षेप कर मूल कारण हल करता है, फिर उत्पादन फिर से शुरू होता है। इसमें दो समानांतर तंत्र हैं: मशीन में अंतर्निहित असामान्यता-संसूचक होता है जो स्वयं रुक सकती है; और उत्पादन लाइन पर कोई भी कर्मचारी असामान्यता देखकर एंडन रस्सी (andon) खींचता है, जिससे पूरी लाइन तुरंत रुक जाती है। गुणवत्ता अंत में जाँची नहीं जाती, बल्कि हर चरण में निहित होती है और वहीं हल की जाती है।
यहाँ एक प्रतिअंतर्ज्ञान निष्कर्ष है, जो सीधे सॉफ़्टवेयर क्षेत्र से जुड़ता है: स्वचालन जितना गहरा होगा, गुणवत्ता-द्वार और मानवीय हस्तक्षेप का भार उतना ही कम होने के बजाय बढ़ेगा। जिडोका मनुष्य को “दोहराव वाले संचालन” से मुक्त कर, “असामान्यता खोजना, लाइन रोकना, मूल कारण हल करना” की मूल भूमिका में पुनर्स्थापित करता है। टोयोटा ने अग्रिम श्रमिकों को पूरी उत्पादन लाइन रोकने का अधिकार दिया, क्योंकि उसे भली-भांति ज्ञात था: स्वचालन चाहे कितना भी मज़बूत हो, समस्या होने पर रोकने वाला कोई मनुष्य ज़रूरी है। यही “रोबोट को ज्ञान देना” नारे का वास्तविक अर्थ है: मशीन को रुकने और मनुष्य को बुलाने की क्षमता हासिल हो। मनुष्य हमेशा मौजूद रहता है, मूल कारण हल करने के लिए ज़िम्मेदार।
सॉफ्टवेयर इस राह पर वापस चल रहा है—और बहुत तेज़ी से। GitClear के AI-सहायता वाले कोड की गुणवत्ता पर किए गए अध्ययन में दोहराए गए कोड ब्लॉक्स की वृद्धि और अल्पकालिक churn कोड में वृद्धि के संकेत देखे गए हैं: AI तेज़ी से लिखता है, लेकिन वह “सब कुछ सही लगने वाला” भी लिखता है। जब बड़ी मात्रा में कोड किसी ने व्यक्तिगत रूप से लाइन-बाय-लाइन नहीं लिखा होता, तो पारंपरिक “डेवलपर को अंदाज़ा होता है” वाला विश्वास का तंत्र असफल हो जाता है। इस समय आपको चाहिए सॉफ्टवेयर का एन-अंग रस्सी और लाइन रोकने का तंत्र:
- टेस्टिंग (यूनिट, इंटीग्रेशन, एंड-टू-एंड) को “जहाँ तक संभव हो” से बढ़ाकर एक कठोर दरवाज़ा बना दिया जाए: जो टेस्ट पास न हो, वह मर्ज न हो;
- Code review का ध्यान “लिखावट चेक करने” से बदलकर “इरादे और सीमाओं की जाँच” पर हो जाए: यह कोड वास्तव में क्या समस्या हल करना चाहता है, क्या सभी बॉर्डर कंडीशन्स कवर किए गए हैं;
- ओब्ज़र्वेबिलिटी (मॉनिटरिंग, लॉग्स, ट्रेसिंग) एक मानक बन जाए, क्योंकि ऑनलाइन व्यवहार कोड से अधिक स्पष्ट रूप से बताता है कि क्या चल रहा है;
- ग्रेय-ब्लू डिप्लॉयमेंट / फीचर फ्लैग ऐसे करते हैं कि AI द्वारा उत्पन्न कोड पहले छोटे समूह में परीक्षण हो, और जब सुनिश्चित हो जाए कि कुछ गलत नहीं है, तभी इसे बड़े पैमाने पर जाने दिया जाए।
वापस दूसरे अनुच्छेद में Stripe के 1,300 PRs पर नज़र डालें: लिखना एजेंट करे, लेकिन मर्ज करने की प्रक्रिया पूरी तरह मानवीय review पर छोड़ दी गई। यही सॉफ्टवेयर में स्वयंचालितता का जीवंत उदाहरण है: उत्पादन को स्वयंचालित करें, लेकिन स्वीकृति को मानव के हाथों में छोड़ें—और मानव को “इसे रोकने” का अधिकार दें। उत्पादन सस्ता हो गया, गुणवत्ता नियंत्रण महंगा हो गया: यह एक 40 साल पुराना नियम है जो अभी तक अपरिवर्तित रहा है।
चार: सबसे गहरी चाकू: पुष्टि, और टोयोटा का “जिडोका” हमें क्या सिखाता है
चारों बाधाओं में, सबसे अधिक गलत समझा जाने वाला है पुष्टि। बहुत से लोग इसे इस तरह समझते हैं: “चूंकि AI तेजी से कोड लिखता है, तो हम कई बार टेस्ट कर लें।” यह आधा सही है। पुष्टि क्यों महंगी हो रही है, यह समझने के लिए, हमें टोयोटा की उस अवधारणा को सही ढंग से समझना होगा जिसे सबसे ज्यादा गलत तरीके से उद्धृत किया जाता है: जिडोका (Jidoka)।
सबसे पहले, एक व्यापक रूप से फैली गलत धारणा को ठीक करते हैं। जिडोका का मतलब “AI या मशीनों द्वारा मनुष्यों को बदलना” नहीं है, और न ही “मनुष्यों को मशीन बना देना, जैसे मशीन की तरह बिना रुके काम करते रहें”। ये दोनों दिशाएँ उल्टी हैं।
“जिडोका” शब्द के शाब्दिक अर्थ में ही उत्तर छिपा है। जापानी में “自動化” (जिडोका) सामान्य स्वचालन है, लेकिन टोयोटा जानबूझकर “自働化” का उपयोग करती है — जिसमें “働” में “व्यक्ति” (人) अर्थात् मनुष्य का चिह्न है, जो “मानवीय स्पर्श वाले स्वचालन” (automation with a human touch) पर ज़ोर देता है। इसका सटीक अर्थ है: जब मशीन या उत्पादन लाइन असामान्यता पकड़ती है, तो वह स्वचालित रुक जाती है, मनुष्य हस्तक्षेप कर मूल कारण हल करता है, फिर उत्पादन फिर से शुरू होता है। इसमें दो समानांतर तंत्र हैं: मशीन में अंतर्निहित असामान्यता-संसूचक होता है जो स्वयं रुक सकती है; और उत्पादन लाइन पर कोई भी कर्मचारी असामान्यता देखकर एंडन रस्सी (andon) खींचता है, जिससे पूरी लाइन तुरंत रुक जाती है। गुणवत्ता अंत में जाँची नहीं जाती, बल्कि हर चरण में निहित होती है और वहीं हल की जाती है।
यहाँ एक प्रतिअंतर्ज्ञान निष्कर्ष है, जो सीधे सॉफ़्टवेयर क्षेत्र से जुड़ता है: स्वचालन जितना गहरा होगा, गुणवत्ता-द्वार और मानवीय हस्तक्षेप का भार उतना ही कम होने के बजाय बढ़ेगा। जिडोका मनुष्य को “दोहराव वाले संचालन” से मुक्त कर, “असामान्यता खोजना, लाइन रोकना, मूल कारण हल करना” की मूल भूमिका में पुनर्स्थापित करता है। टोयोटा ने अग्रिम श्रमिकों को पूरी उत्पादन लाइन रोकने का अधिकार दिया, क्योंकि उसे भली-भांति ज्ञात था: स्वचालन चाहे कितना भी मज़बूत हो, समस्या होने पर रोकने वाला कोई मनुष्य ज़रूरी है। यही “रोबोट को ज्ञान देना” नारे का वास्तविक अर्थ है: मशीन को रुकने और मनुष्य को बुलाने की क्षमता हासिल हो। मनुष्य हमेशा मौजूद रहता है, मूल कारण हल करने के लिए ज़िम्मेदार।
सॉफ्टवेयर इस राह पर वापस चल रहा है—और बहुत तेज़ी से। GitClear के AI-सहायता वाले कोड की गुणवत्ता पर किए गए अध्ययन में दोहराए गए कोड ब्लॉक्स की वृद्धि और अल्पकालिक churn कोड में वृद्धि के संकेत देखे गए हैं: AI तेज़ी से लिखता है, लेकिन वह “सब कुछ सही लगने वाला” भी लिखता है। जब बड़ी मात्रा में कोड किसी ने व्यक्तिगत रूप से लाइन-बाय-लाइन नहीं लिखा होता, तो पारंपरिक “डेवलपर को अंदाज़ा होता है” वाला विश्वास का तंत्र असफल हो जाता है। इस समय आपको चाहिए सॉफ्टवेयर का एन-अंग रस्सी और लाइन रोकने का तंत्र:
- टेस्टिंग (यूनिट, इंटीग्रेशन, एंड-टू-एंड) को “जहाँ तक संभव हो” से बढ़ाकर एक कठोर दरवाज़ा बना दिया जाए: जो टेस्ट पास न हो, वह मर्ज न हो;
- Code review का ध्यान “लिखावट चेक करने” से बदलकर “इरादे और सीमाओं की जाँच” पर हो जाए: यह कोड वास्तव में क्या समस्या हल करना चाहता है, क्या सभी बॉर्डर कंडीशन्स कवर किए गए हैं;
- ओब्ज़र्वेबिलिटी (मॉनिटरिंग, लॉग्स, ट्रेसिंग) एक मानक बन जाए, क्योंकि ऑनलाइन व्यवहार कोड से अधिक स्पष्ट रूप से बताता है कि क्या चल रहा है;
- ग्रेय-ब्लू डिप्लॉयमेंट / फीचर फ्लैग ऐसे करते हैं कि AI द्वारा उत्पन्न कोड पहले छोटे समूह में परीक्षण हो, और जब सुनिश्चित हो जाए कि कुछ गलत नहीं है, तभी इसे बड़े पैमाने पर जाने दिया जाए।
वापस दूसरे अनुच्छेद में Stripe के 1,300 PRs पर नज़र डालें: लिखना एजेंट करे, लेकिन मर्ज करने की प्रक्रिया पूरी तरह मानवीय review पर छोड़ दी गई। यही सॉफ्टवेयर में स्वयंचालितता का जीवंत उदाहरण है: उत्पादन को स्वयंचालित करें, लेकिन स्वीकृति को मानव के हाथों में छोड़ें—और मानव को “इसे रोकने” का अधिकार दें। उत्पादन सस्ता हो गया, गुणवत्ता नियंत्रण महंगा हो गया: यह एक 40 साल पुराना नियम है जो अभी तक अपरिवर्तित रहा है।
फाइनेंस। एक क्रेडिट रिस्क मैनेजमेंट या एंटी-मनी लॉन्ड्रिंग नियम का अपडेट, एप्प, कोर सिस्टम, रिस्क एंजिन, डेटा प्लेटफॉर्म और रेगुलेटरी रिपोर्टिंग तक फैला हुआ है। यहाँ वेरिफिकेशन का वजन बहुत अधिक होता है, क्योंकि एक गलती ही कॉम्प्लायंस इंसिडेंट बन सकती है। बैलन्स पॉइंट व्याख्या योग्य, ऑडिट योग्य, ट्रेसेबल है: AI द्वारा लिखे गए नियम जितने भी सटीक हों, अगर रेगुलेटर का सवाल “इसे ऐसा क्यों फैसला किया?” का जवाब नहीं दे पाते, तो वे लाइव नहीं हो सकते। एंटी-मनी लॉन्ड्रिंग नियमों का अपडेट इसका एक उदाहरण है: AI नियम लिखने को तेज़ करता है, लेकिन मॉडल की व्याख्या योग्यता की जाँच और रेगुलेटरी रिपोर्टिंग के साथ एलाइनमेंट मिलकर अक्सर पूरे साइकिल का आधा से ज्यादा समय खा जाते हैं।
ई-कॉमर्स। एक प्रमोशन या ग्रेट सेल फीचर, जो प्रोडक्ट, ट्रांजैक्शन, मार्केटिंग, वेयरहाउस और कस्टमर सर्विस के बीच फैला हुआ है। AI पेज और एपीआई लिखने में तेज़ी लाता है, लेकिन बैलन्स पॉइंट अब प्रेशर टेस्टिंग, स्टॉक कंसिस्टेंसी, रिस्क मैनेजमेंट फॉर फ्रॉड, रिकॉन्सिलिएशन पर शिफ्ट हो गया है। ग्रेट सेल रात को डाउन होने वाली कोड ऐसी नहीं होती जो धीमी लिखी गई हो, बल्कि वो जिनकी बॉर्डर केसेस की वेरिफिकेशन नहीं हुई। ग्रेट सेल तैयारी इसका एक संक्षिप्त रूप है: AI प्रमोशन पेज को बहुत जल्दी जेनरेट कर सकता है, लेकिन एंड-टू-एंड प्रेशर टेस्टिंग और स्टॉक कंसिस्टेंसी वेरिफिकेशन अक्सर तैयारी के आधे से ज्यादा टाइम ले लेते हैं।
चारों इंडस्ट्रीज की सामान्य बात स्पष्ट है: AI “लिखने” को तेज़ करता है, लेकिन “जोड़ने, वेरिफाई करने, एलाइन करने” में रुकता है। बचे हुए डेवलपमेंट कैपेसिटी को इन तीन चीजों में लगाना ही असली एफिशिएंसी बढ़ाने का रास्ता है।
7. यदि निर्णय गलत हो गया तो क्या होगा: तीन सबसे आम बेमेल
पहला: “कोड तेज़ी से लिखना” को “डिलीवरी तेज़ हो जाना” समझना। यह सबसे आम भ्रम है। कोड केवल डिलीवरी श्रृंखला का एक चरण है; इसे चौड़ा करने से पूरी श्रृंखला तेज़ नहीं होती, बल्कि बॉटलनेक के पीछे अधिक अधूरे उत्पाद जमा हो जाते हैं। सीमा सिद्धांत इसे स्टॉक कहता है, सॉफ़्टवेयर में इसे अनमैन्डेटेड PR और अनटेस्टेड ब्रांच कहते हैं। परिणामस्वरूप, डेवलपर अधिक व्यस्त हो जाते हैं, बिज़नेस अधिक त्वरित हो जाता है, लेकिन आउटपुट वही रहता है—यही शुरुआत में उस CIO की स्थिति है।
दूसरा: उत्पादन को तेज़ करते समय, गुणवत्ता के गेट को हटा देना। यह स्वचालन के नियमों के खिलाफ एक आम गलती है। कुछ लोग सोचते हैं कि “AI तेज़ और अच्छा कोड लिखता है, इसलिए code review सरल कर दें, टेस्टिंग को हटा दें।” वास्तव में, उत्पादन जितना तेज़ होगा, अन्तर्निहित अन्तर्वाह उतना ही ज़रूरी होगा। अप्रूवल गेट हटाना, एक ऐसी लाइन को पूरी गति से खाली चलाने के बराबर है जहाँ कोई नहीं है—दोष उत्पादन वातावरण में तेज़ी से बढ़ने लगते हैं।
तीसरा: बॉटलनेक के बाहर पैसा खर्च करना। इंटीग्रेशन बॉटलनेक है, लेकिन आप अधिक AI प्रोग्रामिंग लाइसेंस खरीद रहे हैं; वेरिफिकेशन बॉटलनेक है, लेकिन आप अधिक डेवलपर भर्ती कर रहे हैं। सीमा सिद्धांत पहले से ही स्पष्ट कर चुका है: बॉटलनेक के बाहर संसाधन लगाने से कुल आउटपुट पर कोई प्रभाव नहीं पड़ता, बल्कि बुक की स्थिति और खराब हो जाती है। सही क्रम यह है: पहले बॉटलनेक की पहचान करें, फिर संसाधनों को बॉटलनेक पर केंद्रित करें।
अष्टम: निर्णय लेने वालों के लिए संकेत
सबक 1: टूल खरीदने से पहले, एक बॉटलनेक चार्ट बनाएं।
अपने पिछले तीन बार के डिलीवरी ब्लॉक को तोड़कर देखें कि समय कहाँ खर्च हुआ—कोड नहीं लिख पाने में? या चीजें जोड़ न पाने में? या कोई चेक नहीं कर रहा? या जरूरत स्पष्ट नहीं हुई? जिन चीजों को आप नहीं चिह्नित कर पा रहे, वे तकनीकी स्तर पर अनुमान लगा रही हैं। बॉटलनेक चार्ट किसी भी टूल खरीदारी की सूची से ज्यादा कीमती है—यह बड़े कंपनियों के आधे से ज्यादा बेकार के IT निवेश को रोक सकता है।
सबक 2: बचे हुए क्षमता को डिमांड और वेरिफिकेशन पर लगाएं।
AI ने डेवलपमेंट को तेज कर दिया है, जिसका मतलब है कि आपके पास लोगों का समय बच गया है। इन लोगों को आधिकारिक रूप से “डिमांड डिफिनिशन” और “वेरिफिकेशन एक्सेप्टेंस” दो भूमिकाओं में शामिल करें, और उन्हें आगे कोड लिखने में फंसे न रहने दें। AI के युग में इन दोनों भूमिकाओं का रिटर्न सबसे तेजी से बढ़ रहा है।
सबक 3: सॉफ्टवेयर में एक अन-डांग रस्सी लगाएं।
स्वयंचालितता का सबसे सीधा अमल आपके CI/CD में कठोर दरवाजे लगाना है: टेस्ट फेल हुआ तो मर्ज नहीं, रिव्यू में इरादा और सीमाएँ जरूर चेक करें, ग्रे डेलीवरी पहले छोटे स्कोप में, और ओब्जर्वेबिलिटी एक स्टैंडर्ड बन जाए। जितना अधिक उत्पादन स्वयंचालित होगा, उतना ही यह दरवाजा मजबूत होना चाहिए। यह “कोड मुफ्त” को “अटैक मुफ्त” नहीं बनने देता।
सबक 4: लोगों की जगह फिर से बदलें, उन्हें हटाएं नहीं।
स्वयंचालितता एक ही निष्कर्ष पर पहुँचती है: जितना अधिक ऑटोमेशन होगा, उतना ही लोगों को “निर्णय, स्वीकृति, और रूट कारण निकालने” की भूमिका में रखना होगा। लोगों को दोहराव वाले कार्यों से मुक्त करके, उन्हें वेरिफिकेशन और अलाइनमेंट पर फिर से तैनात करें—यह AI के युग में संगठन डिज़ाइन की केंद्रीय क्रिया है, और इस श्रृंखला के अगले कुछ लेखों में हम इसे विस्तार से देखेंगे।
नौ: आप पूछ सकते हैं
“हम सिर्फ़ स्थानीय स्तर पर AI पायलट कर रहे हैं, क्या पूरी कंपनी का बाधक-मानचित्र बनाना ज़रूरी है?”
पायलट हो तब भी, पहले स्पष्ट देखना होगा: यह पायलट चरण, वास्तविक बाधक तो नहीं? यदि असली रुकावट एकीकरण या सत्यापन में है, तो “कोड लिखने” के चरण में AI पायलट करना गैर-बाधक पर पैसा लुटाना है — ठीक वहीं, जो सातवें खंड का तीसरा बेमेल है। पहले एक छोटे दायरे का बाधक-निदान करें; तभी टूल का पैसा लाभदायक लगेगा।
“क्या सत्यापन-द्वार वितरण धीमा कर देगा?”
अल्पकाल में घर्षण होगा, दीर्घकाल में त्वरण। स्वीकृति-द्वार के बिना “तेज़ी”, दोषों को उत्पादन वातावरण में धकेलने की तेज़ी है; पुनर्कार्य की लागत कम-से-कम दस गुना बढ़ जाती है। जिडोका का अनुभव है: एक दोष को वहीं हल करने की लागत, उसे धारा-नीचे जाने देकर हल करने का मात्र एक छोटा अंश है।
“इसका हमारे चल रहे AI परिवर्तन से क्या संबंध है?”
संबंध बहुत प्रत्यक्ष है। AI परिवर्तन की सबसे आम भ्रांति यह मानना है कि बाधक “कोड लिखना / क्षमता” पर है, और फिर इस हिस्से को चौड़ा करने के लिए ढेरों टूल खरीद लेना। पहले बाधक-निदान करें, फिर तय करें कि पैसा कहाँ खर्च हो। यही कारण है कि मैंने “क्षमता मूल्यांकन” और “मूल्य-परिदृश्य पहचान” को AI परिवर्तन 7-चरण कोचिंग ढाँचे में आगे रखा है: पहले बाधक कहाँ है देखें, फिर टूल पर बात करें।
रिवर्स सेल्फ-चेक (जवाब देते समय सजावट न करें): आपकी हालिया सबसे बड़ी डिलीवरी में जो समय खर्च हुआ, वह कोड लिखने पर गया, या इसे जोड़ने, चेक करने, और अलाइन करने पर? आपके AI टूल्स द्वारा उत्पादित कोड में से कितना स्थिर रूप से प्रोडक्शन में लाया गया और वास्तविक उपयोगकर्ता इसका उपयोग कर रहे हैं? आपके CI/CD में क्या एक “टेस्ट फेल होने पर मर्ज नहीं” का कठोर गेट है? इन तीनों में से एक भी आपको असहज कर दे, तो अभी और AI टूल्स खरीदने की बजाय, पहले अपनी बॉटलनेक ढूंढें।
अगला कदम
यह “AI युग में सॉफ्टवेयर इंजीनियरिंग का परिवर्तन” श्रृंखला का तीसरा भाग है, जो कॉनवे (संगठन आर्किटेक्चर निर्धारित करता है) और टीम टोपोलॉजी (संगठन कैसे डिज़ाइन करें) से बॉटलनेक शिफ्ट पर आता है (जब कोड लगभग मुफ्त हो जाए, तो बॉटलनेक कहाँ चला जाता है?)। अगला भाग (चौथा) एक अधिक प्रैक्टिकल दृष्टिकोण पर जाता है: मुख्य AI प्रोग्रामिंग टूल्स कैसे चुनें। लेकिन निष्कर्ष अप्रत्याशित हो सकता है: चयन अंततः एक संगठनात्मक निर्णय है, जिसे आपकी परिपक्वता और गवर्नेंस स्तर के आधार पर चुनना चाहिए, न कि “कौन सा कोड सबसे शानदार लिखता है” के आधार पर।
श्रृंखला टिप्पणी: यह श्रृंखला AI प्रोग्रामिंग टूल्स, संगठनात्मक आर्किटेक्चर और सॉफ्टवेयर इंजीनियरिंग पैराडाइम के नवीनतम विकास का निरंतर अनुसरण करेगी, जैसे 2026 में AI एजेंट युग में कॉनवे के नियम के नए परिवर्तन, या नवीनतम टूल इकोसिस्टम की परिपक्वता। इस श्रृंखला को फॉलो करें और निरंतर अपडेट्स के लिए अपनी जानकारी अपडेट रखें।
इस श्रृंखला के बारे में
“AI युग में सॉफ्टवेयर इंजीनियरिंग का परिवर्तन” एक 15-भागों वाली गहन श्रृंखला है, जो टेलीकॉम, फाइनेंस, निर्माण, ई-कॉमर्स जैसे उद्योगों के CIO/CDO/CTO और डिजिटलाइजेशन लीडर्स के लिए लिखी गई है। यह 200+ शोध पत्रों और उद्योग रिपोर्ट्स पर आधारित है और साक्ष्य-स्तर चिह्नित निर्णय-संदर्भ प्रदान करती है।
मैं एक पूर्व IBM इंजीनियर और ICF प्रमाणित कोच हूँ, जिसने टेलीकॉम और बड़े उद्यमों में AI / डिजिटलाइजेशन प्रोजेक्ट्स के लागूकरण में हिस्सा लिया है। यहाँ लिखा गया सब कुछ उन व्यवसायों के साथ जुड़े गए वास्तविक अनुभवों से निकाला गया है, जिन्होंने मुश्किलों से गुजरना था।
संदर्भ स्रोत (सभी सत्यापित)
- a16z (2026). Software in the Age of Agents. The a16z Podcast. (पूर्व माइक्रोसॉफ्ट विंडोज अध्यक्ष स्टीवन सिनोफ्स्की का उद्धरण: “The long tail got no shorter, it just got longer in a different way” — उद्यम सॉफ्टवेयर के दृष्टिकोण से TOC बॉटलनेक बदलाव के नियम की स्वतंत्र पुष्टि; प्राथमिक स्रोत — पॉडकास्ट का मूल ऑडियो। स्थिति टिप्पणी: a16z के साझेदार / पूर्व माइक्रोसॉफ्ट अधिकारी, VC दृष्टिकोण। अतिथि सत्यापित: a16z एंटरप्राइज टीम पार्टनर सीमा अम्बल, पूर्व माइक्रोसॉ
buymeacoffee
