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

Linear का मामला उपयोगी है। 21 सितंबर की इंजीनियरिंग रिपोर्ट में Mufeez Amjad कहते हैं कि 2026 की शुरुआत से उसके परीक्षण-सूट लगभग चार गुना हो गए, जबकि पुल-अनुरोधों पर continuous integration की प्रतीक्षा छह मिनट से अधिक से घटकर पाँच मिनट से कुछ ज़्यादा रह गई। हर परीक्षण का रनर समय करीब आधा हुआ। ये अलग सुधार हैं; आखिरी आँकड़े का मतलब यह नहीं कि कुल CI बिल आधा हो गया। Linear बढ़ते सत्यापन-दबाव का श्रेय एजेंटों की मदद से विकास को देता है, लेकिन उसकी रिपोर्ट नियंत्रित प्रयोग नहीं है जो AI के उत्पादकता पर असर को साबित करे। Linear की इंजीनियरिंग रिपोर्ट.

Continuous integration (CI) प्रस्तावित सॉफ़्टवेयर बदलावों पर स्वचालित जाँचें चलाता है। संभावित पैच और टीम द्वारा स्वीकार किए जाने योग्य बदलाव के बीच यह पड़ता है। AI कोडिंग से पैच बढ़ें, तो जाँच-क्षमता कारोबार का सवाल बन जाती है: संगठन कितना उपयोगी काम सुरक्षित रूप से सँभाल सकता है?

हमारी राय में प्रबंधकों को तीन नतीजे साथ दिखाने चाहिए: भरोसेमंद प्रतिक्रिया पाने का समय, कुल कंप्यूटिंग काम और जारी किए बदलावों की विश्वसनीयता। जल्दी जवाब तभी उपयोगी है जब टीम समझे कि उससे क्या साबित हुआ।

कम प्रतीक्षा के लिए अधिक काम लग सकता है

मान लें कि एक परीक्षण-सूट में एक मशीन पर बारह मिनट का काम है। उसे चार मशीनों में बराबर बाँटने पर तीन मिनट में पूरा हो सकता है। यह काल्पनिक उदाहरण सही बँटवारा मानता है और बाकी सब अनदेखा करता है। मशीनों को फिर भी कुल बारह मिनट काम करना पड़ता है।

अब हर मशीन को तैयारी के लिए एक मिनट दें। चार मशीनों वाला काम चार मिनट में पूरा होता है और रनर के सोलह मिनट खर्च करता है। एक मशीन वाला काम तेरह मिनट लेता और रनर के तेरह मिनट खर्च करता है। कुल मशीन-खपत बढ़ने पर भी प्रतीक्षा बहुत घटती है। असल शुल्क रनर के प्रकार, कीमत और बिलिंग नियमों पर भी निर्भर हैं।

डैशबोर्ड पर हरी पट्टी छोटी होने पर जश्न मनाते समय यह फ़र्क मायने रखता है। समानांतर क्षमता ख़रीदने का मतलब है जल्दी प्रतिक्रिया ख़रीदना, संभवतः अतिरिक्त लागत पर। असली पाबंदी दूर हो, तो यह बढ़िया समझौता हो सकता है। लेकिन पूरा बदलाव फिर किसी समीक्षक के उपलब्ध होने के लिए घंटों रुका हो, तो यह उचित ठहराना कठिन है।

विश्लेषण की इकाई एक CI रन से आगे जानी चाहिए। बार-बार संशोधन, दोबारा रन और समीक्षा के दूसरे दौर वाला पैच किसी तेज़ रन से कहीं अधिक काम ले सकता है। बदलाव स्वीकार करने के लिए लगी सभी कोशिशें गिनें, छोड़ी गई कोशिशें भी। वरना कुशल दिखने वाली पाइपलाइन विकास की महँगी प्रक्रिया छिपा सकती है।

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

शोध से मिली तस्वीर मिली-जुली है

DORA के मार्च 2026 के विश्लेषण में दो अलग प्रमाण-समूह हैं। 2025 के शोध में AI का अधिक उपयोग सॉफ़्टवेयर डिलीवरी की अधिक मात्रा और अधिक अस्थिरता—दोनों से जुड़ा था। अलग से, शोधकर्ताओं ने 2025 की तीसरी तिमाही में Google इंजीनियरों के 1,110 खुले जवाबों का विश्लेषण किया। इंजीनियरों ने मसौदा बनाने और अन्य कामों में सहायता के साथ सत्यापन का अतिरिक्त बोझ भी बताया। आंतरिक गुणात्मक अध्ययन, DORA के व्यापक संबंध के पीछे की आबादी नहीं है; इनमें से कोई भी यह साबित नहीं करता कि AI ने किसी खास टीम की रिलीज़ समस्याएँ पैदा कीं। DORA का विश्लेषण और कार्यप्रणाली.

अधिक सीमित दायरे में और मज़बूत प्रायोगिक प्रमाण भी हैं। METR के जुलाई 2025 के यादृच्छिक अध्ययन में 16 अनुभवी ओपन-सोर्स डेवलपरों को परिचित रिपॉज़िटरी में कुल 246 काम दिए गए। 2025 की शुरुआत के AI औज़ार इस्तेमाल करने की अनुमति होने पर काम पूरा करने में 19% अधिक समय लगा। फिर भी प्रतिभागियों को लगा कि AI ने उन्हें तेज़ काम करने में मदद की। नतीजा उन्हीं डेवलपरों, कामों और औज़ारों के बारे में है; इससे आज उपलब्ध हर कोडिंग एजेंट का मूल्य तय नहीं हो सकता। METR का मूल प्रयोग.

फ़रवरी 2026 में METR ने कहा कि उसके आगे के प्रयोग से मौजूदा उत्पादकता प्रभाव का अविश्वसनीय अनुमान मिला। डेवलपर बिना AI वाले काम से इनकार करने लगे या खुद चुनने लगे कि कौन-से काम जमा करें; साथ चल रहे एजेंटों से समय मापना भी जटिल हुआ। शोधकर्ताओं ने अधिक तेज़ी को संभावित माना, लेकिन कहा कि आँकड़े उसके आकार का बहुत कम प्रमाण देते हैं। इस स्पष्टीकरण के बिना पुरानी, धीमी गति वाली संख्या दोहराना पाठकों को गुमराह करेगा। METR का अनुवर्ती अध्ययन.

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

हर पाबंदी का अलग उपाय करें

अधिक CI क्षमता ख़रीदने से पहले किसी एक बदलाव को उसके पहले प्रस्तावित पैच से लेकर उत्पादन तक दर्ज करें। चलने वाले काम को प्रतीक्षा कर रहे काम से अलग करें। पता लगाएँ कि कौन-सी जाँच निर्णय को सचमुच रोकती है, किस समीक्षक का ध्यान ज़रूरी है और उसके बाद कौन-सी रिलीज़ शर्तें बाकी रहती हैं।

गलत निवेश सामने लाने के लिए साधारण समय-रिकॉर्ड अक्सर काफ़ी है। ज़्यादातर देरी समीक्षा शुरू होने से पहले हो, तो परीक्षणों में कुछ सेकंड घटाने से समस्या हल नहीं होगी। समीक्षक किसी ज़रूरी जाँच के लिए बार-बार रुके, तो उस जाँच को बेहतर करने का सीधा मकसद है। तैनाती के बाद मुख्यतः विफलताएँ आएँ, तो देखना होगा कि सत्यापन से क्या छूट रहा है।

निर्भरता का कैशिंग दिखाता है कि परिचित अनुकूलन को भी मापना क्यों चाहिए। GitHub के अनुसार, कैशिंग से साफ़ रनर पर दोबारा बनाने में महँगी फ़ाइलें फिर इस्तेमाल की जा सकती हैं। वह यह भी कहता है कि कैश उपलब्ध न हो, तब भी जॉब फ़ाइलें फिर बना या डाउनलोड कर सकें। इसलिए कैश के सफल और विफल—दोनों मामलों का आकलन करें। GitHub के निर्भरता-कैशिंग दस्तावेज़.

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

तेज़ और विश्वसनीय प्रतिक्रिया लोगों और एजेंटों—दोनों को ग़लती पहले सुधारने का मौका देती है। साझा ढाँचा बेहतर करने से AI के बिना लिखे बदलावों समेत कई तरह के विकास कार्य लाभान्वित हो सकते हैं। कोडिंग औज़ारों की पसंद बदलती रहे, तब भी यह उस ढाँचे में निवेश का कारण है।

One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.
AI-generated conceptual illustration by BIG CHANGE. Left: elapsed time waiting for a run. Right: machine work accumulated across its workers. Parallel checks can shorten the wait without reducing total work. Clock positions, sizes and worker counts are schematic, not measured times or a cost ratio.

तेज़ परीक्षणों को फिर भी ग़लती पकड़नी चाहिए

प्रदर्शन-सुधार से परीक्षण चलने की शर्तें बदलें, तो उसकी प्रोसेसर तेज़ करने से ज़्यादा बारीकी से जाँच चाहिए।

JavaScript और TypeScript परीक्षण औज़ार Vitest डिफ़ॉल्ट रूप से हर परीक्षण फ़ाइल को अलग रखता है ताकि एक फ़ाइल की स्थिति दूसरी को प्रभावित न करे। उसका दस्तावेज़ सही परीक्षणों में चुनी हुई अलगाव-शर्तें हटाने का तरीका बताता है, जबकि बदलने योग्य मॉड्यूल स्थिति, संशोधित वैश्विक मान और दूसरी निर्भरताएँ अलगाव बनाए रखने की वजह हैं। इसलिए तैयारी का समय घटाने वाली सेटिंग सही होने की सीमा भी बदल सकती है। Vitest की अलगाव-व्यवस्था.

Linear ने साझा स्थिति के लिए वैकल्पिक तरीका अपनाया, सफ़ाई की व्यवस्था जोड़ी और उन फ़ाइलों में अलगाव बनाए रखा जिन्हें सुरक्षित रूप से स्थानांतरित नहीं कर सकते थे। उसका प्रदर्शन-लाभ इस फ़ैसले पर निर्भर था कि कौन-से परीक्षण वह वातावरण सुरक्षित रूप से साझा कर सकते हैं। Linear का क्रियान्वयन.

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

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

परीक्षणों की संख्या बढ़ाने पर इनाम देने वाली टीम, बिना देखे कि उनसे क्या साबित होता है, समीक्षकों को अधिक सामग्री और कम भरोसा दे सकती है। एजेंट का काम पूरा होने के बाद उसे बेवजह की देरी मानने के बजाय प्रबंधक को काम सौंपते समय ऐसी जाँच के लिए समय रखना चाहिए।

ग्राहक तक पहुँचने वाला बदलाव मापें

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

अपनी AI कोडिंग प्रक्रिया की जाँच करने वाली टीम के लिए हम इन नतीजों के साथ थोड़ा नैदानिक रिकॉर्ड भी जोड़ेंगे:

  • प्रतिक्रिया: ज़रूरी जाँचों तक गुज़रा समय, जिसमें धीमे रन और क्षमता की प्रतीक्षा शामिल हो।
  • खपत: स्वीकृत बदलाव से जुड़ा कुल रनर-काम और दोहराई गई कोशिशें।
  • समीक्षा: ध्यान मिलने की प्रतीक्षा, माँगे गए बड़े संशोधन और हर संशोधन का कारण।
  • ग्राहक पर असर: जारी बदलाव ने इच्छित व्यवहार दिया या नहीं और सुधार का काम लगा या नहीं।

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

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