आपके सिस्टम में पहले से ही अंधेरे हिस्से हैं। AI केवल उन्हें और बदतर बनाता है।

2022 में, जब जनरेटिव कोडिंग टूल हमारे दैनिक इंजीनियरिंग कार्य का हिस्सा नहीं थे, मैंने लिखा टूल चयन पर मेरे दर्शन के बारे में. यह मेरी अपेक्षा से बेहतर बना रहा है। उस समय, मैंने यह तर्क दिया था कि आप उन समस्याओं से शुरू करें जिन्हें आप वास्तव में हल कर रहे हैं, अपनी कमजोरियों को जानें, और टूल्स के उपयोग को प्राथमिकता दें बजाय इसके कि बस वह टूल चुनें जो सबसे अच्छा लगता है और आशा करें कि यह काम करेगा। खुद को जानें, और अपने लक्ष्यों को, ताकि आप अपने टूल्स के लिए उचित अपेक्षाएँ निर्धारित कर सकें।

उस समय, मैं SaaS विस्तार के बारे में सोच रहा था, न कि AI‑जनित कोड के। लेकिन आज मेरा दर्शन और भी अधिक तात्कालिक है, और इसे बनाए रखना और भी महत्वपूर्ण है।

हममें से कई ने पढ़ा है 2025 DORA रिपोर्ट, जिसमें पाया गया कि पिछले वर्ष की तुलना में, AI अपनाना अब डिलीवरी थ्रूपुट के साथ सकारात्मक रूप से सहसंबंधित है। इसके नीचे का निष्कर्ष यह था कि डिलीवरी अस्थिरता बढ़ती जा रही थी, और उन्होंने परीक्षण किया कि क्या गति वृद्धि इसे कवर करती है। नहीं करती। यह हमारे अनुभव से मेल खाता है। हमारी टीम ने एजेंटिक सॉफ़्टवेयर विकास अपनाया और दो तिमाहियों में थ्रूपुट में 48% वृद्धि देखी, जिसके बाद स्थिरता मुद्दों में 16% वृद्धि हुई। दस लोग एक छोटा नमूना है, लेकिन यह ऐसा नमूना भी है जिससे मैं पूरी तस्वीर देख सकता हूँ, और पैटर्न बना रहा।

AI अपनाना अब वास्तव में प्रश्न नहीं रहा। आप या तो अभी शुरू कर रहे हैं या आप इसके मध्य में हैं। अब जो अलग है वह यह है कि इंजीनियरिंग नेताओं से अपेक्षा की जाती है कि वे AI अपनाएँ और यह भी साबित करें कि यह लाभदायक है। CEO, बोर्ड, और वित्त सभी यह जानना चाहते हैं कि वे अपनी AI निवेश को कैसे अनुकूलित कर सकते हैं। वे पूछ रहे हैं कि क्या आपके द्वारा चुने गए टूल वास्तविक समस्याओं को प्रभावी ढंग से हल कर रहे हैं।

अंतर हमेशा मौजूद रहा। AI ने इसे और विस्तृत कर दिया।

एक CTO के रूप में, मैं अपना काफी समय अन्य इंजीनियरिंग नेताओं से बात करने में बिताता हूँ, जिसमें ग्राहक, संभावित ग्राहक, और मेरे सहयोगी शामिल हैं, ताकि हम AI के साथ अपने अनुभवों के बारे में उपलब्धियों और शिकायतों की तुलना कर सकें। पर्याप्त बातचीत के बाद, मैंने AI अपनाने और परिणामों में पैटर्न देखना शुरू कर दिया है।

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

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

फिर भी, हम अभी भी वही उद्देश्यों के लिए जिम्मेदार हैं। आप अभी भी गति, गुणवत्ता, खर्च, और आपकी टीम की वास्तविक स्थिति के मालिक हैं। अब आप पिछले वर्ष के डैशबोर्ड को विश्वास के साथ नहीं ले सकते।

यहाँ एक उचित आपत्ति है। DORA’s 2026 ROI रिपोर्ट एक J‑क्रव Curve का वर्णन करता है: अपनाने के तुरंत बाद उत्पादकता में गिरावट, जो सीखने की वक्र, AI‑जनित कोड की सत्यापन लागत, और उन डाउनस्ट्रीम प्रक्रियाओं के कारण होती है जो अभी तक नहीं पहुँची हैं। वे इसे परिवर्तन की “ट्यूशन लागत” कहते हैं, और नेताओं को चेतावनी देते हैं कि इसे विफलता समझें नहीं। यह उचित है। लेकिन ट्यूशन और वास्तविक समस्या टिकटों से बने डैशबोर्ड पर समान दिखती हैं। यदि आप नहीं बता सकते कि आप किसमें हैं, तो आप धैर्य नहीं रख रहे हैं। आप अनुमान लगा रहे हैं।

हमें मूल बातों पर वापस जाना चाहिए। खुद को जानें। अपनी टीम को जानें। आप कौन सी समस्याएँ हल कर रहे हैं, यह जानें।

AI के साथ आप “खुद को कैसे जानेंगे”?

मेरी बातचीत से, मैंने पाँच मुख्य क्षेत्रों की पहचान की है जहाँ पारम्परिक सिस्टम, जो मानव‑जनित, मानव‑रिपोर्टेड कार्य के लिए बनाए गए हैं, अंधे हैं। उन्हें नजरअंदाज करने से आप AI अपनाते समय अपनी कमजोरियों को बढ़ाने का जोखिम उठाते हैं।

अंधा बिंदु 1: गति थिएटर

अधिक कमिट और अधिक PR प्रगति जैसा महसूस हो सकता है, और अक्सर ऐसा ही होता है। AI दोनों गिनतियों को स्वचालित रूप से बढ़ाता है। एक Stanford केस स्टडी ने दिखाया कि AI अपनाने से PR गिनती में 14% वृद्धि हुई। लेकिन जो आप खो रहे हैं वह यह है कि उस गतिविधि में से कितना हिस्सा फीचर कार्य है जो शिप होता है बनाम रखरखाव, पुनः कार्य, या ऐसे रीफ़ैक्टर से उत्पन्न चर्न जो टिक नहीं पाया।

इसे संबोधित करने के लिए, फीचर कार्य और रखरखाव के बीच विभाजन को देखें, और डिप्लॉयमेंट आवृत्ति और लीड टाइम को अपने स्वयं के ऐतिहासिक बेंचमार्क के विरुद्ध देखें, न कि उद्योग औसत के। बिना उस विभाजन के, आप ऐसी प्रगति रिपोर्ट कर रहे हैं जिसे आप वास्तव में प्रमाणित नहीं कर सकते।

अंधा बिंदु 2: समीक्षा ऋण

समीक्षा क्षमता स्वचालित रूप से आउटपुट के साथ स्केल नहीं करती। सत्यापन कर कोई ऐसा चरण नहीं है जिसे आप पार कर लेते हैं; यह एजेंटिक विकास की स्थायी लागत का हिस्सा है। A इंजीनियरिंग नेताओं के एक हालिया सर्वेक्षण ने पाया कि 80% टीमें कम से कम 10% अपना समय समीक्षा पर खर्च करती हैं, और लगभग एक में से दस 40% से अधिक समय खर्च करती हैं। इस भार के तहत, टीमें बढ़ते बैकलॉग और रूबरु-स्टैम्पिंग के बीच झूलती हैं, और दोनों ही वास्तविक समाधान नहीं हैं।

शिपिंग पर प्रतिबंध अब यह नहीं है कि कोड कितनी तेज़ी से लिखा जाता है। यह यह है कि एक मानव कितनी तेज़ी से वास्तव में यह भरोसा कर सकता है कि परिवर्तन सही है, त्रुटियों को कितनी तेज़ी और सटीकता से पता लगाया और ठीक किया जा सकता है। देखें कि समीक्षा लोड वास्तव में आपकी टीम में कैसे वितरित है; अन्यथा आप अपने वरिष्ठ इंजीनियरों को अधिक काम दे सकते हैं, अपनी रिलीज़ में देरी कर सकते हैं, या बड़े उत्पादन मुद्दों का कारण बन सकते हैं।

Blind Spot 3: Hidden Work

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

वास्तव में कितना काम किया जा रहा है, यह समझने के लिए आपको देखना होगा कि कोडबेस और पुल‑रिक्वेस्ट इतिहास में वास्तव में कितना परिवर्तन हो रहा है। इसके बिना, आपका क्षमता योजना उन चीज़ों पर आधारित होगी जो लोग लॉग करने को याद रखते हैं, न कि जो उन्होंने वास्तव में किया। 

Blind Spot 4: Quality Drift

उसी सर्वेक्षण ने पाया कि लगभग आधे इंजीनियरिंग नेता सप्ताह‑दर‑सप्ताह सुरक्षा मुद्दों का पता लगाने में संघर्ष करते हैं। जटिलता, डुप्लिकेशन, और ऐसी निर्भरताएँ जो पूरी तरह फिट नहीं होतीं, कई छोटे‑छोटे, व्यक्तिगत रूप से उचित बदलावों में जमा हो जाती हैं। उनमें से कोई भी अकेले देख कर चिंताजनक नहीं लगता। उसी स्टैनफ़ोर्ड केस स्टडी में, कोड गुणवत्ता 9% गिर गई और उसका वैरिएंस तीन गुना से अधिक हो गया। जबकि औसत थोड़ा बदल गया, फैलाव (वह भाग जिसे आप नोटिस करते हैं) बहुत बदल गया। AI की मात्रा पर, वे अधिकांश समीक्षा प्रक्रियाओं से तेज़ी से जुड़ते हैं। ड्रिफ्ट अक्सर एक ऑन‑कॉल अलर्ट के रूप में सामने आता है जो किसी ऐसी निर्भरता से जुड़ा होता है जिसे कोई याद नहीं रखता कि उसने समीक्षा की थी। जब यह होता है, तो संभावना है कि ग्राहक ने पहले ही इसे नोटिस कर लिया हो।

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

Blind Spot 5: Unproven Spend

एक बार AI अपनाना बहस का विषय नहीं रह जाता, तो AI खर्च और ROI वह प्रश्न बन जाता है जिस पर सभी ध्यान केंद्रित करते हैं। वित्त यह जानना चाहता है कि क्या पूंजीकरण योग्य है और क्या परिचालनात्मक। नेतृत्व यह जानना चाहता है कि निवेश का परिणाम क्या रहा। अधिकांश टीमें अभी भी टूलिंग, सीट, और हेडकाउंट के निर्णय अंतर्ज्ञान पर ले रही हैं, न कि पैसे और डिलीवर किए गए काम के बीच लिंक के प्रमाण पर।

देखें कि इंजीनियरिंग प्रयास वास्तव में कोडबेस में कहाँ बहता है, तिमाही‑दर‑तिमाही — न कि जहाँ रोडमैप कहता है कि वह बहना चाहिए। इस लिंक के बिना, आप अगले साल के बजट को किस्सों के साथ बचा रहे हैं, और किस्से CFO के साथ कठोर बातचीत में टिकते नहीं हैं।

Start With What You Can’t See

वित्त का प्रश्न कि पूंजीकृत खर्च और 2 बजे रात का ऑन‑कॉल पेज असंबंधित लगते हैं, लेकिन नहीं हैं। दोनों को गतिविधि से “अनुमानित” किया जा सकता है। लेकिन दोनों वास्तव में कोड से साक्ष्य के साथ उत्तर योग्य हैं।

DORA का इस सबका उत्तर स्वयं इंजीनियरिंग सिस्टम है: प्लेटफ़ॉर्म गुणवत्ता, कार्यप्रवाह स्पष्टता, टीम संरेखण। यह सही है, और यह पहला कदम भी नहीं है। आप उस सिस्टम को ठीक नहीं कर सकते जिसे आप नहीं देख पाते। उन पाँच क्षेत्रों में से प्रत्येक को आप पहले देखना चाहिए, फिर ही आप उसमें निवेश के लिए तर्क दे सकते हैं।

पहला उपयोगी कदम नया टूल या नई प्रक्रिया नहीं है। यह है खुद को ईमानदारी से जानना, और यह निर्धारित करना कि इन पाँच क्षेत्रों में से कौन‑से ब्लाइंड स्पॉट हैं जहाँ आपके पास वास्तविक साक्ष्य नहीं है। अधिकांश नेता तुरंत (और उन पर ध्यान दे रहे हैं) इन क्षेत्रों में से किसी एक में समस्याओं की पहचान कर सकते हैं। हालांकि, वही क्षेत्र जहाँ आपके पास सबसे कम जानकारी है, वे ही सबसे अधिक संभावना रखते हैं कि AI अपनाने के दौरान सामने आएँ और आपको चकित कर दें।