एआय कोडिंग एजंट एक पॅच पूर्ण करतो; तोवर आधीच्या पॅचच्या तपासण्या सुरू असू शकतात. अभियांत्रिकी व्यवस्थापकासमोर अवघड फरक उभा राहतो: पथकाने अधिक कोड तयार केला, पण ग्राहकाला अजून काहीच मिळाले नाही.

Linear चे उदाहरण उपयुक्त आहे. 21 सप्टेंबरच्या अभियांत्रिकी-वृत्तांतात Mufeez Amjad सांगतात की 2026 च्या सुरुवातीपासून त्यांच्या चाचणी-संचांची संख्या जवळपास चौपट झाली; त्याचवेळी pull request साठीची सतत एकत्रीकरणातील प्रतीक्षा सहा मिनिटांहून अधिकवरून पाच मिनिटांहून थोडी जास्त झाली. प्रत्येक चाचणीमागील रनर-वेळ साधारण निम्मी झाली. या वेगवेगळ्या सुधारणा आहेत; शेवटच्या आकड्याचा अर्थ एकूण CI बिल निम्मे झाले असा नाही. एजंटच्या मदतीने होणाऱ्या विकासामुळे पडताळणीवरचा वाढता ताण येतो, असे Linear चे म्हणणे आहे; पण त्यांचा वृत्तांत एआयमुळे उत्पादकतेवर झालेला परिणाम सिद्ध करणारा नियंत्रित प्रयोग नाही. Linear चा अभियांत्रिकी-वृत्तांत.

सतत एकत्रीकरण (CI) प्रस्तावित सॉफ्टवेअर-बदलांवर स्वयंचलित तपासण्या चालवते. तर्कसंगत वाटणारा पॅच आणि पथक स्वीकारण्यास तयार असलेला बदल यांच्यामधला हा टप्पा आहे. एआय कोडिंगमुळे पॅचेसचा पुरवठा वाढल्यावर, किती उपयुक्त काम संस्था सुरक्षितपणे स्वीकारू शकते हा व्यावसायिक प्रश्न बनतो.

आमच्या मते, व्यवस्थापकांनी तीन निकाल एकत्र दिसू द्यावेत: विश्वासार्ह प्रतिसाद मिळेपर्यंतचा वेळ, एकूण संगणकीय काम आणि प्रसिद्ध बदलांची विश्वासार्हता. जलद उत्तराचा उपयोग ते काय सिद्ध करते हे पथकाला समजले तरच आहे.

प्रतीक्षा कमी झाली तरी काम वाढलेले असू शकते

एका यंत्रावर बारा मिनिटे लागणाऱ्या चाचणी-संचाची कल्पना करा. ते काम चार यंत्रांवर समान वाटल्यास तीन मिनिटांत पूर्ण होऊ शकते. हा काल्पनिक हिशेब काम उत्तमरीत्या वाटले जाते असे मानतो आणि बाकी सर्व बाबी दुर्लक्षित करतो. तरी एकूण बारा मिनिटांचे यंत्र-काम होतेच.

आता प्रत्येक यंत्राला तयारीसाठी एक मिनिट द्या. चार यंत्रांची आवृत्ती चार मिनिटांत पूर्ण होऊन एकूण सोळा रनर-मिनिटे वापरेल. एकाच यंत्राची आवृत्ती तेरा मिनिटांत पूर्ण होऊन तेरा रनर-मिनिटे वापरेल. प्रतीक्षा झपाट्याने कमी झाली; पण एकूण यंत्र-वापर वाढला. प्रत्यक्ष शुल्क रनरचा प्रकार, किंमत आणि बिलिंग-नियमांवरही अवलंबून असते.

डॅशबोर्डवरील हिरवी पट्टी कमी झाली म्हणून आनंद व्यक्त करताना हा फरक महत्त्वाचा आहे. समांतर क्षमता खरेदी करणे म्हणजे लवकर अभिप्राय मिळवण्यावर, कदाचित अधिक खर्च करून, पैसे देणे. खऱ्या अडथळ्याचे निराकरण होत असेल तर हा उत्तम सौदा ठरू शकतो. पण पूर्ण झालेला बदल तपासक उपलब्ध होण्यासाठी अनेक तास थांबत असेल, तर त्याचे समर्थन करणे कठीण आहे.

विश्लेषणाची एकक-मर्यादा एका CI धावण्यापलीकडे असावी. वारंवार दुरुस्त्या, पुन्हा धावणाऱ्या चाचण्या आणि दुसरे पुनरावलोकन लागणारा पॅच, सर्वात वेगवान स्वतंत्र धावण्यापेक्षा बरेच अधिक काम घेऊ शकतो. रद्द केलेले प्रयत्न धरून बदल स्वीकारण्यासाठी लागलेल्या एकूण प्रयत्नांची नोंद ठेवा. अन्यथा कार्यक्षम दिसणारी प्रक्रिया विकासाचा खर्च लपवू शकते.

प्रतीक्षेतील प्रत्येक मिनिटाला समान मजुरीचा खर्च असतोच असे नाही. तपासण्या चालू असताना विकासकाने दुसरे उपयुक्त काम सुरू केले, तर तो संपूर्ण वेळ वाया गेला असेलच असे नाही. मात्र वारंवार होणारे व्यत्यय आणि अपूर्ण कामाकडे पुन्हा वळणे त्रासदायक ठरू शकते. याचा परिणाम मोजण्यासाठी गेलेली मिनिटे पगाराने गुणण्याऐवजी पथकाचे काम कसे चालते ते पाहावे.

संशोधनातून संमिश्र चित्र दिसते

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

अधिक मर्यादित व्याप्तीचा अधिक मजबूत प्रयोगात्मक पुरावाही आहे. METR च्या जुलै 2025 मधील यादृच्छिक अभ्यासात परिचित repository मध्ये काम करणाऱ्या 16 अनुभवी open-source विकासकांना 246 कामे दिली. 2025 च्या सुरुवातीची एआय साधने वापरण्याची मुभा असताना काम पूर्ण होण्यास 19% अधिक वेळ लागला. तरी एआयमुळे वेग वाढल्याची सहभागींची समज होती. हा निष्कर्ष त्या विकासकांबद्दल, त्या कामांबद्दल आणि त्या साधनांबद्दल आहे; आज उपलब्ध प्रत्येक कोडिंग एजंटचे मूल्य ठरवत नाही. METR चा मूळ प्रयोग.

फेब्रुवारी 2026 मध्ये METR ने सांगितले की पुढील प्रयोगातून सध्याच्या उत्पादकता-परिणामांचा विश्वासार्ह अंदाज मिळाला नाही. एआयशिवाय काम करणे किंवा कामासाठी कोणती कामे द्यायची हे विकासक अधिकाधिक नाकारत किंवा स्वतः निवडत होते; समांतर एजंट्समुळे वेळ मोजणेही गुंतागुंतीचे झाले. वेगवाढ जास्त असण्याची शक्यता संशोधकांनी मान्य केली, पण तिच्या प्रमाणाबाबतचा पुरावा कमकुवत असल्याचे सांगितले. हा खुलासा न देता जुन्या मंदावण्याच्या आकड्याची पुनरावृत्ती केल्यास वाचकांची दिशाभूल होईल. METR चा पुढील अभ्यास.

व्यवस्थापकासाठी या अभ्यासांतून व्यावहारिक भूमिका घेता येते: उपयुक्त साधने ठेवा, त्यांचा परिणाम तपासा आणि उत्साह किंवा साशंकता यांपैकी कोणत्याही भूमिकेला सर्वत्र लागू कर्मचारी-नियम बनवू नका. एखाद्या कामात पथकाला मोठा फायदा होईल; दुसऱ्यात वेळ जाऊ शकतो. वितरण-प्रक्रियेत हा फरक दिसला पाहिजे.

प्रत्येक अडथळ्यासाठी स्वतंत्र उपाय ठेवा

अधिक CI क्षमता विकत घेण्याआधी, पहिल्या प्रस्तावित पॅचपासून उत्पादनात वापर होईपर्यंत एका बदलाचा मागोवा घ्या. चालणारे काम आणि प्रतीक्षा करणारे काम वेगळे करा. निर्णय उशिरा होण्यास खरे कारणीभूत तपासणी, लक्ष द्यावे लागणारा समीक्षक आणि त्यानंतरही राहणाऱ्या प्रसिद्धीच्या अटी ओळखा.

साधी वेळ-नोंद चुकीची गुंतवणूक उघड करण्यास पुरेशी ठरते. पुनरावलोकन सुरू होण्याआधीच बहुतांश विलंब होत असेल, तर चाचण्या काही सेकंद लवकर करून तो सुटणार नाही. समीक्षक वारंवार लांब आवश्यक चाचणीची वाट पाहत असेल, तर ती सुधारण्याला थेट हेतू आहे. प्रसिद्धीनंतरच बहुतांश बिघाड होत असतील, तर पडताळणीतून काय सुटते हे पथकाने तपासावे.

अवलंबित्वांचे cache करणे हे मोजमापाची गरज दाखवणाऱ्या नेहमीच्या अनुकूलनाचे उदाहरण आहे. स्वच्छ रनरवर पुन्हा तयार करायला महाग असलेल्या फाइल्स पुन्हा वापरण्याचा मार्ग cache देतो, असे GitHub स्पष्ट करते. cache उपलब्ध नसेल तेव्हाही कामे त्या फाइल्स पुन्हा तयार किंवा डाउनलोड करू शकली पाहिजेत, असेही ते सांगते. त्यामुळे cache यशस्वी आणि अयशस्वी दोन्ही स्थितीत तपासावा. GitHub चे dependency-caching मार्गदर्शन.

व्यवस्थापकासाठी, प्रतिसाद किती अंदाजे मिळतो हा उपयुक्त प्रश्न आहे. सरासरी उत्कृष्ट असली तरी क्वचित होणारी लांब प्रतीक्षा प्रसिद्धी विस्कळीत करू शकते. वितरणाच्या हळू टोकाचीही नोंद ठेवा आणि चाचणी खरोखर अयशस्वी झाली, डाउनलोड बिघडले किंवा रनर संपला यात फरक करा. प्रत्येकासाठी वेगळा उपाय हवा.

वेळेवर मिळणारा विश्वासार्ह प्रतिसाद माणसे आणि एजंट्सना चुका लवकर दुरुस्त करण्याची संधी देतो. ही सामायिक पायाभूत सुविधा सुधारल्याने एआयशिवाय लिहिलेल्या बदलांसह अनेक प्रकारच्या विकास-कामांना फायदा होऊ शकतो. कोडिंग साधनांची निवड बदलत असली तरी यासाठी निधी देण्याचे कारण व्यवस्थापकांकडे आहे.

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 चे वितरण-मापक प्रसिद्धीच्या पुढील टप्प्याची उपयुक्त तपासणी देतात. commit केलेला कोड उत्पादनात पोहोचेपर्यंतचा वेळ, तैनातीची वारंवारता, अयशस्वी तैनातीनंतरची पुनर्प्राप्ती, तातडीच्या हस्तक्षेपाची गरज पडलेल्या तैनातींचे प्रमाण आणि नियोजित नसलेल्या घटना-संबंधी पुन्हा कामाचे प्रमाण यांचा त्यात समावेश आहे. यांतून फक्त चाचणी उत्तीर्ण होण्यापलीकडचे वितरण-निकाल दिसतात. DORA च्या मापकांच्या व्याख्या.

एआय कोडिंग-प्रक्रिया तपासणाऱ्या पथकासाठी आम्ही हे परिणाम थोडक्या निदान-नोंदीसोबत पाहू:

  • प्रतिसाद: आवश्यक तपासण्या होईपर्यंतचा वेळ, लांब धावण्यांचा आणि क्षमतेच्या प्रतीक्षेचा समावेश करून.
  • वापर: स्वीकारलेल्या बदलासाठी एकूण रनर-काम आणि पुनःपुन्हा केलेले प्रयत्न.
  • पुनरावलोकन: लक्ष मिळण्याची प्रतीक्षा, मागितलेल्या मोठ्या सुधारणा आणि प्रत्येक सुधारणेचे कारण.
  • ग्राहकांवरील परिणाम: प्रसिद्ध बदलाने अपेक्षित वर्तन दिले का आणि नंतर दुरुस्तीचे काम लागले का.

विशिष्ट कामकाजाचा तपास करण्यासाठी नोंद वापरा. दस्तऐवजातील छोटी दुरुस्ती आणि database migration यांना उत्पादकतेची एकसारखी एकके मानू नका. शक्य असेल तेव्हा समान कामाची काळानुसार तुलना करा आणि रनर-पुरवठादार किंवा प्रसिद्धी-प्रक्रियेतील बदलांसारख्या इतर घडामोडीही नोंदवा. एआय वापर सुरू झाल्याच्या काळात सुधारणा दिसली म्हणजे तिचे कारण एआयच असे सिद्ध होत नाही.

मग व्यवस्थापक ठोस निवड करू शकतात: पुरेशा खात्रीने उपयुक्त बदल ग्राहकांपर्यंत पोहोचण्यास अडवणाऱ्या मर्यादेत गुंतवणूक करा. कधी अधिक संगणकीय क्षमता लागेल; कधी अधिक स्पष्ट गरजा, चांगल्या चाचण्या किंवा आधीच येत असलेले प्रस्ताव समजून घेण्यासाठी अनुभवी समीक्षकांचा पुरेसा वेळ लागेल.