जब कोड लगभग मुफ्त हो जाए, बाधा अब मांग, एकीकरण, प्रमाणीकरण और समन्वय में चली जाती है

जब कोड उत्पादन लगभग मुफ्त हो जाए, तो सॉफ्टवेयर डिलीवरी की बाधा “कोड लिखने” से बाहर चली जाती है: सही सवाल परिभाषित करना, टुकड़ों को एक कामकाजी पूर्णता में जोड़ना, यह सत्यापित करना कि वास्तव में यह सही है, और संगठन को समन्वित करना। यह सॉफ्टवेयर उद्योग में सीमा सिद्धांत (Theory of Constraints) की एक बार फिर से दोहराई गई घटना है। निर्माण उद्योग ने 40 साल पहले इस राह पर कदम रखा था: जब भी कोई चरण सस्ता हो जाता है, बाधा गायब नहीं होती — वह बस अगले सबसे महंगे चरण में चली जाती है। इस बात को समझने से आप एक सामान्य भ्रम को समझ सकते हैं: AI प्रोग्रामिंग टूल्स पूरी कंपनी में लागू हो गए हैं, कोड लिखना स्पष्ट रूप से तेज हो गया है, लेकिन डिलीवरी की गति में कोई खास बदलाव नहीं आया।

एक निर्माण समूह के CIO ने मुझे अपने पिछले छह महीने के डेटा दिखाए। IT टीम में 80 से अधिक लोग हैं, जिन्होंने AI प्रोग्रामिंग टूल्स को पूरी तरह से अपना लिया है। कोड उत्पादन की दृष्टि से, प्रति व्यक्ति कमिट और मर्ज रेट में 30% से अधिक की वृद्धि हुई है। लेकिन बिजनेस साइड का अनुभव बिल्कुल अलग है: एक इंटेलिजेंट स्केड्यूलिंग फीचर को लेकर, शुरुआत से लेकर लाइव तक अभी भी 3 महीने से अधिक का समय लगता है। उन्होंने मान लिया था कि टूल्स 2x स्पीडअप लाएंगे, लेकिन उन्हें बस “कोड जल्दी लिखने” की क्षमता मिली। उनकी बात सीधी थी: “मैंने कुछ मिलियन डॉलर लाइसेंस पर खर्च किए, और मुझे मिला — डेवलपर्स और बिजनेस दोनों अधिक तनावग्रस्त।”

उसने बॉटलनेक की स्थिति को गलत ढंग से अनुमान लगा लिया। उसका वास्तविक बॉटलनेक कुछ और था: हर नया फीचर MES, ERP, क्वालिटी चेक सिस्टम, शॉप फ्लोर टर्मिनल, और एक प्रायोजक रिपोर्टिंग फ्रेमवर्क के माध्यम से गुजरना पड़ता था—एकीकरण और समन्वय ने अधिकांश समय खा लिया; जबकि AI द्वारा उत्पन्न कोड के सामने किसी भी औपचारिक स्वीकृति बाधा और उत्पादन वातावरण के बीच नहीं थी। जितना तेज़ी से कोड लिखा जाए, वह केवल गलत बॉटलनेक के पीछे लाइन में खड़ा होता है। # एक, निर्माण: 40 साल पहले से पता था: बॉटलनेक घूम जाता है वर्तमान को समझने के लिए, पहले 40 साल पुरानी निर्माण उद्योग की आँखों से देखें। 1984 में, इज़राइली सलाहकार एलियाहू गोल्ड्रैट, जो एक भौतिक विज्ञानी थे, ने एक उपन्यास “द गोल” लिखा, जिसमें एक दिवालिया होने के कगार पर खड़े फैक्ट्री मालिक कैसे अपनी फैक्ट्री बचाता है, इसकी कहानी है। पूरी किताब का केंद्र एक ही वाक्य है: किसी भी प्रणाली का उत्पादन, उसके सबसे संकीर्ण चरण (प्रतिबंध, यानी बॉटलनेक) द्वारा निर्धारित होता है। गैर-बॉटलनेक चरणों को चौड़ा करने से कुल उत्पादन में कोई फर्क नहीं पड़ता; केवल बॉटलनेक को ही चौड़ा करने से पूरी प्रणाली तेज़ होती है। और जैसे ही आप बॉटलनेक को चौड़ा करते हैं, वह तुरंत अगले सबसे संकीर्ण स्थान पर चला जाता है। यही सीमा सिद्धांत (Theory of Constraints, TOC) है।
产量瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐

工期去哪了：写代码缩成一条，四道工序膨胀
AI 之前
写代码近乎免费之后

写代码
占工期近半
需求
集成
验证
对齐

写代码 ↓缩成一条
需求 ↑
集成 ↑
验证 ↑（涨最多）
对齐 ↑
比例为方向性示意（综合行业经验），非单一调研的精确数字

बाद के 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 में, जीन किम ने गोल्डरैट की फैक्ट्री की कहानी को लगभग बिल्कुल वैसे ही आईटी ऑपरेशन्स में शामिल किया और “द फीनिक्स प्रोजेक्ट” लिखा: एक सीआईओ कैसे कंपनी को लगभग डुबो देने वाले आईटी विभाग को बचाने के लिए कंस्ट्रेंट थ्योरी का उपयोग करता है। इसलिए “उत्पादन के बैलेंस के दृष्टिकोण से सॉफ्टवेयर को देखना” एक पहले से सत्यापित रास्ता है, कोई अस्थायी उपमा नहीं।
产量瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐
# द्वितीय: सॉफ्टवेयर में वापसी: कोड लिखना अब सबसे सस्ता चरण बन गया है
तीन संख्याएँ, “कोड उत्पादन लागत शून्य की ओर बढ़ रही है” इस बात को स्पष्ट करती हैं।

Copilot：GitHub 自己的研究发现，在启用 Copilot 的文件中，约 46% 的代码由 Copilot 生成。请注意，这是指“启用 Copilot 的文件内部”的占比，而非 GitHub 全部代码的 46%。
Stripe：其内部自研的编码代理“Minions”每周产出并合并的 PR 超过 1,300 个（早期为 1,000，持续增长）。这里有一个关键细节：每一个 PR 都需经过人工审查后才能合并。Stripe 将“编写”自动化，而将“验收”留给人类——这一点将在第四节用到。
NVIDIA：黄仁勋曾公开表示，100% 的 NVIDIA 工程师都在使用 Cursor 等 AI 编程工具，“不用 AI 工作”在 NVIDIA 已不再被接受。

将这三组数字叠加，结论非常明确：生成一行代码的单位成本，正迅速趋近于零。随之而来一个尖锐问题：既然写代码几乎免费了，为什么软件依然昂贵、缓慢、难以交付？答案正是约束理论给出的：你拓宽了“写代码”这一环节，瓶颈只是被挪走了。它挪去了哪里？
产量瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐

工期去哪了：写代码缩成一条，四道工序膨胀
AI 之前
写代码近乎免费之后

写代码
占工期近半
需求
集成
验证
对齐

写代码 ↓缩成一条
需求 ↑
集成 ↑
验证 ↑（涨最多）
对齐 ↑
比例为方向性示意（综合行业经验），非单一调研的精确数字

तीसरा: संकीर्णता चार जगहों पर पहुँच गई

इस बार, संकीर्णता चार चरणों पर केंद्रित है। हर एक, AI के लिए आने वाले कुछ सालों में असंभव है।

पहला: सही सवाल पूछना।
AI कुछ सेकंड में “आप जिस फीचर के बारे में बात कर रहे हैं” को लिख सकता है, लेकिन “आपको वास्तव में जिस फीचर की जरूरत है” को नहीं लिख सकता। ज्यादातर सॉफ़्टवेयर प्रोजेक्ट्स की विफलता का मूल कारण यह है कि बनाया गया चीज़ कोई इस्तेमाल नहीं करता—शुरुआत से ही यह स्पष्ट नहीं होता कि कौन सी समस्या हल करनी है। कोड उत्पादन सस्ता हो जाने के बाद, “एक अस्पष्ट व्यावसायिक चुनौती को एक स्पष्ट, हल करने योग्य, और हल करने लायक स्पेसिफिकेशन में तोड़ना” (problem formulation) सबसे दुर्लभ और सबसे महंगी क्षमता बन गई है। निर्माण उद्योग के साथी इसे अच्छी तरह जानते हैं: अगर प्रक्रिया रूट और इंजीनियरिंग ड्राइंग गलत हैं, तो जितना भी अच्छा और तेज़ आप मशीनों में काम करें, आप केवल बड़ी मात्रा में बर्बाद उत्पाद बना रहे होंगे।

दूसरा: सिस्टम एकीकरण।
AI “एक कोड स्निपेट”, “एक फ़ंक्शन”, “एक पेज” जैसी चीज़ें बनाने में अच्छा है। लेकिन एक लाइव सिस्टम, सैकड़ों ऐसे टुकड़ों का एकीकरण होता है, जिन्हें डेटा आदान-प्रदान करना होता है, सीमाओं को हैंडल करना होता है, सुसंगठित रहना होता है, और अपवादों का सामना करना होता है। टुकड़े बनाना सस्ता है, लेकिन उन्हें एक विश्वसनीय पूर्णता में जोड़ना महंगा है। यह लागत का मूल कारण संगठन और आर्किटेक्चर की समन्वयता में छिपा है—जिस पर कॉन्वे का नियम और टीम टोपोलॉजी ध्यान देते हैं (इस श्रृंखला के पिछले दो लेख देखें)। शुरुआत में जिस निर्माण CIO की बात की गई थी, उनका समय कोड लिखने में नहीं, बल्कि MES, ERP, क्वालिटी चेक और रिपोर्टिंग जैसी कई सिस्टम्स के इंटीग्रेशन में बीत गया।

तीसरा बाधा: पुष्टि। कोड की मात्रा तेजी से बढ़ रही है, विश्वसनीयता असमान है। कौन फैसला करेगा कि “यह सही है”? परीक्षण, कोड रिव्यू, ऑब्जर्वेबिलिटी, ग्रे डिप्लॉयमेंट—ये सभी “पुष्टि” के कार्यों का भार कम नहीं, बल्कि बढ़ रहा है। यह सबसे कम मूल्यांकित बाधा है, और निर्माण के प्रतिबिंब में सबसे गहरी बाधा है। इसकी चर्चा अलग से अनुच्छेद 4 में की जाएगी।

चौथा बाधा: संगठनात्मक समन्वय। जब टीम में AI एजेंट शामिल हो जाते हैं, तो कौन तय करता है कि क्या करना है, कौन समीक्षा करता है, और कौन परिणामों के लिए जिम्मेदार है? यह भी कॉन्वे के नियम और टीम टोपोलॉजी का विस्तार है—संगठनात्मक समन्वय खुद एक बाधा बन गया है। श्रृंखला के अनुच्छेद 11 में इसकी विस्तृत चर्चा होगी: जब संगठन के नोड्स सिर्फ मनुष्य नहीं होते, तो शासन कैसे केंद्रीय प्रतिस्पर्धी लाभ बन जाता है।

# चार: सबसे गहरी चाकू: पुष्टि, और टोयोटा का "जिडोका" हमें क्या सिखाता है

चारों बाधाओं में, सबसे अधिक गलत समझा जाने वाला है पुष्टि। बहुत से लोग इसे इस तरह समझते हैं: “चूंकि AI तेजी से कोड लिखता है, तो हम कई बार टेस्ट कर लें।” यह आधा सही है। पुष्टि क्यों महंगी हो रही है, यह समझने के लिए, हमें टोयोटा की उस अवधारणा को सही ढंग से समझना होगा जिसे सबसे ज्यादा गलत तरीके से उद्धृत किया जाता है: जिडोका (Jidoka)।

सबसे पहले, एक व्यापक रूप से फैली गलत धारणा को ठीक करते हैं। जिडोका का मतलब “AI या मशीनों द्वारा मनुष्यों को बदलना” नहीं है, और न ही “मनुष्यों को मशीन बना देना, जैसे मशीन की तरह बिना रुके काम करते रहें”। ये दोनों दिशाएँ उल्टी हैं।

自働化这个词的字面本身就藏着答案。日语中“自動化”是普通的自动化，而丰田特意使用“自働化”，其中的“働”带有“人”字旁，强调的是“带人字旁的自动化”（automation with a human touch）。它的准确含义是：当机器或产线检测到异常时，自动停止，让人介入并解决根本原因，再恢复生产。 它包含两个并行机制：机器内置异常检测，可自行停机；产线上任何员工发现异常，只需拉动安灯绳（andon），整条产线立即停止。质量不是在末端检验，而是嵌入每一道工序，就地解决。

这里有一个反直觉的结论，它直接对应软件领域：自动化越深，质量关卡和人工介入的权重反而只增不减。 自働化将人从“重复操作”中解放出来，重新定位到“发现异常、停线、解决根因”的核心角色。丰田赋予一线工人拉停整条产线的权力，正是因为深知：无论自动化多强，都必须有人能在问题发生时喊停。这正是“赋予机器人智慧”这句口号的真正含义：让机器具备暂停并召唤人类的能力。人始终在场，负责解决根本原因。

सॉफ्टवेयर इस राह पर वापस चल रहा है—और बहुत तेज़ी से। GitClear के AI-सहायता वाले कोड की गुणवत्ता पर किए गए अध्ययन में दोहराए गए कोड ब्लॉक्स की वृद्धि और अल्पकालिक churn कोड में वृद्धि के संकेत देखे गए हैं: AI तेज़ी से लिखता है, लेकिन वह “सब कुछ सही लगने वाला” भी लिखता है। जब बड़ी मात्रा में कोड किसी ने व्यक्तिगत रूप से लाइन-बाय-लाइन नहीं लिखा होता, तो पारंपरिक “डेवलपर को अंदाज़ा होता है” वाला विश्वास का तंत्र असफल हो जाता है। इस समय आपको चाहिए सॉफ्टवेयर का एन-अंग रस्सी और लाइन रोकने का तंत्र:

टेस्टिंग (यूनिट, इंटीग्रेशन, एंड-टू-एंड) को “जहाँ तक संभव हो” से बढ़ाकर एक कठोर दरवाज़ा बना दिया जाए: जो टेस्ट पास न हो, वह मर्ज न हो;
Code review का ध्यान “लिखावट चेक करने” से बदलकर “इरादे और सीमाओं की जाँच” पर हो जाए: यह कोड वास्तव में क्या समस्या हल करना चाहता है, क्या सभी बॉर्डर कंडीशन्स कवर किए गए हैं;
ओब्ज़र्वेबिलिटी (मॉनिटरिंग, लॉग्स, ट्रेसिंग) एक मानक बन जाए, क्योंकि ऑनलाइन व्यवहार कोड से अधिक स्पष्ट रूप से बताता है कि क्या चल रहा है;
ग्रेय-ब्लू डिप्लॉयमेंट / फीचर फ्लैग ऐसे करते हैं कि AI द्वारा उत्पन्न कोड पहले छोटे समूह में परीक्षण हो, और जब सुनिश्चित हो जाए कि कुछ गलत नहीं है, तभी इसे बड़े पैमाने पर जाने दिया जाए।

वापस दूसरे अनुच्छेद में Stripe के 1,300 PRs पर नज़र डालें: लिखना एजेंट करे, लेकिन मर्ज करने की प्रक्रिया पूरी तरह मानवीय review पर छोड़ दी गई। यही सॉफ्टवेयर में स्वयंचालितता का जीवंत उदाहरण है: उत्पादन को स्वयंचालित करें, लेकिन स्वीकृति को मानव के हाथों में छोड़ें—और मानव को “इसे रोकने” का अधिकार दें। उत्पादन सस्ता हो गया, गुणवत्ता नियंत्रण महंगा हो गया: यह एक 40 साल पुराना नियम है जो अभी तक अपरिवर्तित रहा है।
自动化回路：丰田产线 ↔ 软件 CI/CD
丰田产线（自动化，带人字旁的自动化）
机器自动运转生产自动化
检测到异常机器自停 / 拉安灯
人介入，解根因不在末端检，就地解决
恢复生产人有权喊停
→
→
→
↓ 同一套逻辑，搬到软件
软件 CI/CD（AI 时代的质量门）
AI 生成代码写，自动化
测试 / Review 卡关不过不许合并
人查意图 + 修根因查边界、可解释
合并 / 灰度放量先小范围验
→
→
→
生产自动化，验收留给人的”停线权”，自动化越深质量门越要紧
Stripe Minions：每周 1,300+ PR 由 agent 写，全部人工 review 后才合并
自动化 ≠ 用 AI 替代人；自动化 ≠ 让人变成机器
= 异常停线 + 人介入解根因（automation with a human touch）

पाँचवाँ: “समस्या परिभाषित करने” का प्रीमियम: prompt से अधिक मूल्यवान क्षमता

अगर पुष्टि एक अवहेलित बाधा है, तो “समस्या परिभाषित करना” एक गहराई से अवहेलित क्षमता है।
prompt engineering कुछ समय तक ट्रेंड में रहा, और कई लोगों ने सोचा कि “prompt लिखना आना” ही मूल क्षमता है। लेकिन prompt केवल “समस्या को व्यक्त करने” की तकनीक है। वास्तविक दुर्लभता इससे आगे है: problem formulation — एक अस्पष्ट व्यावसायिक चुनौती को एक स्पष्ट, हल करने योग्य, और हल करने लायक समस्या में विभाजित करना। यह चरण, AI अल्पकाल में नहीं कर सकता, क्योंकि इसके लिए आपको पहले यह बताना होगा कि “समस्या क्या है।”

उत्पादन उद्योग के वरिष्ठ विशेषज्ञ इस चरण के महत्व को सबसे अच्छी तरह समझते हैं। अगर एक इंजीनियरिंग ड्राइंग या एक प्रक्रिया रूपरेखा गलत है, तो नीचे के प्रक्रियाओं और संयोजन कितने भी कुशल क्यों न हों, वे गलत चीजों का बड़े पैमाने पर उत्पादन करेंगे। सॉफ्टवेयर में भी ऐसा ही है: अगर आवश्यकता निर्धारण गलत है, तो AI आपको दस गुना तेज़ी से ऐसी चीजें बनाएगा जिनकी किसी को जरूरत नहीं है।

इसे आसानी से पहचानें: “कोड लिखने की गति” पर नहीं, बल्कि “समस्या को विभाजित करने की स्पष्टता” पर ध्यान दें।
संगठन में, इसका मतलब है कि “आवश्यकता परिभाषा” और “पुष्टि और स्वीकृति” को एक औपचारिक भूमिका बनाएं, और विकासकर्ताओं को इसे बेकार के लिए न करने दें। AI ने वास्तविकीकरण को सस्ता बना दिया है — अब इन दोनों भूमिकाओं का लाभ सबसे तेज़ी से बढ़ रहा है।

छठा: चार उद्योगों की वास्तविक बाधाएँ कैसी दिखती हैं

“बाधा स्थानांतरण” को चार उद्योगों पर लागू करें — हर उद्योग की बाधा कोड लिखने में नहीं है।

उत्पादन उद्योग। मुख्य रेखा शुरुआती CIO है। स्मार्ट उत्पादन योजना, गुणवत्ता अनुसरण, ऊर्जा उपभोग अनुकूलन जैसे कार्य तकनीकी रूप से आसान हैं, और मॉडल अक्सर पहले से उपलब्ध होते हैं। समस्या MES / ERP / गुणवत्ता जांच / रिपोर्टिंग प्रणालियों के एकीकरण और शॉपफ्लोर टर्मिनल पर वास्तविक परीक्षण में है। ऐसी परियोजनाओं का कोड अक्सर जल्दी लिखा जाता है, लेकिन MES/ERP प्रणालियों का एकीकरण और समायोजन को कोड लिखने से कई गुना अधिक समय लगता है; केवल तभी दोषों को स्थानीय रूप से रोका जा सकता है जब स्वीकृति भूमिका को शॉपफ्लोर टर्मिनल और एकीकरण चरणों में शामिल किया जाए, न कि उत्पादन तक पहुँचने तक इंतजार किया जाए। टेलीकॉम / ऑपरेटर। एक पैकेज बदलाव या एक व्यावसायिक-सरकारी लाइन की शुरुआत की प्रक्रिया कई डोमेन—चैनल, बिलिंग, CRM, नेटवर्क सेटअप, स्थापना और रखरखाव शेड्यूलिंग—के माध्यम से गुजरती है। AI ने प्रत्येक डोमेन के विकास को तेज कर दिया है, लेकिन डोमेन-पार एंड-टू-एंड एकीकरण और सुसंगठितता की जाँच ही समय का बड़ा हिस्सा है। ऑपरेटर के पास एक अद्वितीय बाधा भी है: अनुपालन और लेखांकन। बिलिंग में एक पैसे का अंतर भी एक दुर्घटना है, और जाँच का भार किसी भी उद्योग से अधिक है। व्यावसायिक-सरकारी लाइन सेटअप के उदाहरण के साथ, AI ने सभी डोमेन के विकास को तेज कर दिया है, लेकिन एंड-टू-एंड एकीकरण और बिलिंग लेखांकन मिलाकर अक्सर कार्यकाल का आधा से अधिक हिस्सा ले लेते हैं।
产量瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐

工期去哪了：写代码缩成一条，四道工序膨胀
AI 之前
写代码近乎免费之后

写代码
占工期近半
需求
集成
验证
对齐

写代码 ↓缩成一条
需求 ↑
集成 ↑
验证 ↑（涨最多）
对齐 ↑
比例为方向性示意（综合行业经验），非单一调研的精确数字

फाइनेंस। एक क्रेडिट रिस्क मैनेजमेंट या एंटी-मनी लॉन्ड्रिंग नियम का अपडेट, एप्प, कोर सिस्टम, रिस्क एंजिन, डेटा प्लेटफॉर्म और रेगुलेटरी रिपोर्टिंग तक फैला हुआ है। यहाँ वेरिफिकेशन का वजन बहुत अधिक होता है, क्योंकि एक गलती ही कॉम्प्लायंस इंसिडेंट बन सकती है। बैलन्स पॉइंट व्याख्या योग्य, ऑडिट योग्य, ट्रेसेबल है: AI द्वारा लिखे गए नियम जितने भी सटीक हों, अगर रेगुलेटर का सवाल “इसे ऐसा क्यों फैसला किया?” का जवाब नहीं दे पाते, तो वे लाइव नहीं हो सकते। एंटी-मनी लॉन्ड्रिंग नियमों का अपडेट इसका एक उदाहरण है: AI नियम लिखने को तेज़ करता है, लेकिन मॉडल की व्याख्या योग्यता की जाँच और रेगुलेटरी रिपोर्टिंग के साथ एलाइनमेंट मिलकर अक्सर पूरे साइकिल का आधा से ज्यादा समय खा जाते हैं।

ई-कॉमर्स। एक प्रमोशन या ग्रेट सेल फीचर, जो प्रोडक्ट, ट्रांजैक्शन, मार्केटिंग, वेयरहाउस और कस्टमर सर्विस के बीच फैला हुआ है। AI पेज और एपीआई लिखने में तेज़ी लाता है, लेकिन बैलन्स पॉइंट अब प्रेशर टेस्टिंग, स्टॉक कंसिस्टेंसी, रिस्क मैनेजमेंट फॉर फ्रॉड, रिकॉन्सिलिएशन पर शिफ्ट हो गया है। ग्रेट सेल रात को डाउन होने वाली कोड ऐसी नहीं होती जो धीमी लिखी गई हो, बल्कि वो जिनकी बॉर्डर केसेस की वेरिफिकेशन नहीं हुई। ग्रेट सेल तैयारी इसका एक संक्षिप्त रूप है: AI प्रमोशन पेज को बहुत जल्दी जेनरेट कर सकता है, लेकिन एंड-टू-एंड प्रेशर टेस्टिंग और स्टॉक कंसिस्टेंसी वेरिफिकेशन अक्सर तैयारी के आधे से ज्यादा टाइम ले लेते हैं।

चारों इंडस्ट्रीज की सामान्य बात स्पष्ट है: AI “लिखने” को तेज़ करता है, लेकिन “जोड़ने, वेरिफाई करने, एलाइन करने” में रुकता है। बचे हुए डेवलपमेंट कैपेसिटी को इन तीन चीजों में लगाना ही असली एफिशिएंसी बढ़ाने का रास्ता है।

七、判断错了会怎样：三种最常见的错配

पहला: “कोड तेज़ी से लिखना” को “डिलीवरी तेज़ हो जाना” समझना। यह सबसे आम भ्रम है। कोड केवल डिलीवरी श्रृंखला का एक चरण है; इसे चौड़ा करने से पूरी श्रृंखला तेज़ नहीं होती, बल्कि बॉटलनेक के पीछे अधिक अधूरे उत्पाद जमा हो जाते हैं। सीमा सिद्धांत इसे स्टॉक कहता है, सॉफ़्टवेयर में इसे अनमैन्डेटेड 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 / डिजिटलाइजेशन प्रोजेक्ट्स के लागूकरण में हिस्सा लिया है। यहाँ लिखा गया सब कुछ उन व्यवसायों के साथ जुड़े गए वास्तविक अनुभवों से निकाला गया है, जिन्होंने मुश्किलों से गुजरना था।
产量瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐

工期去哪了：写代码缩成一条，四道工序膨胀
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 एंटरप्राइज टीम पार्टनर सीमा अम्बल, पूर्व माइक्रोसॉफ्ट विंडोज अध्यक्ष स्टीवन सिनोफ्स्की (बोर्ड पार्टनर), a16z लेखिका एलेना बर्गर; प्रसारण 2026 जुलाई।)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (संकुचन सिद्धांत TOC का मूल स्रोत, प्राथमिक स्रोत; निर्माण कारखाने के संदर्भ में एक उपन्यास)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Goldratt के TOC को IT ऑपरेशन में सीधे लागू करता है — निर्माण से सॉफ्टवेयर तक का पुल, प्राथमिक स्रोत)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (जिडोका = मनुष्य के अर्थ में बनाया गया स्वचालन, असामान्यता पर लाइन रुकना + मानवीय हस्तक्षेप द्वारा मूल कारण का समाधान; एन्डन सिस्टम; प्राथमिक स्रोत)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot द्वारा फाइल-इन-एक्सेक्यूशन में लगभग 46% कोड पूरा किया जाता है, “फाइल-इन-एक्सेक्यूशन” के आधार पर, प्राथमिक स्रोत)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ द्वारा रिपोर्ट: सप्ताहिक 1,300+ PR, पूर्ण मानवीय समीक्षा (प्राथमिक + द्वितीयक)
NVIDIA / जेन्सन हुआंग. 100% इंजीनियर्स द्वारा Cursor जैसे AI प्रोग्रामिंग टूल्स के उपयोग की औपचारिक घोषणा (प्राथमिक बयान)
GitClear (2025). AI-Assisted Code Quality Research. (AI सहायता के तहत दोहराए गए कोड / अल्पकालिक churn में वृद्धि देखी गई, “पुष्टि महंगी हो रही है” के तर्क को समर्थन देती है, द्वितीयक)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (डिलीवरी प्रदर्शन को व्यक्तिगत कोडिंग गति नहीं, बल्कि संस्कृति, प्रवाह गति और प्रतिक्रिया निर्धारित करते हैं, प्राथमिक स्रोत)