एक हार्वर्डची कार्यपत्रिका उत्पादकतेविषयीच्या एका सामान्य दाव्याची उपयुक्त तपासणी करते: AI च्या मदतीने अधिक कोड लिहिला म्हणजे अधिक सॉफ्टवेअर वितरित झाले पाहिजे. Jellyfish अभियांत्रिकी विश्लेषण मंच वापरणाऱ्या 718 कंपन्यांमध्ये, Fiona Chen आणि James Stratton यांच्या अंदाजानुसार कोडिंग एजंट स्वीकारल्यानंतर प्रत्येक सक्रिय कर्मचाऱ्यामागे कोडच्या ओळी 30%, कमिट 20% आणि पुल रिक्वेस्ट 23% वाढल्या. त्यांनी मोजलेल्या पूर्ण झालेल्या Jira इश्यू आणि एपिकमध्ये सांख्यिकीयदृष्ट्या लक्षणीय वाढ दिसली नाही. लेखाची सध्याची आवृत्ती 4 ऑगस्ट 2026 रोजीची आहे; कामाच्या घटनांचा डेटा मार्च 2026 पर्यंतचा आहे.

हा फरक अभियांत्रिकी नेत्यांसाठी महत्त्वाचा आहे, कारण पुल रिक्वेस्ट पुनरावलोकन, चाचणी आणि संभाव्य बदलांच्या रांगेत जाते. याच अभ्यासात एजंट स्वीकारल्यानंतर पुल रिक्वेस्ट सादर केल्यापासून ती मर्ज होईपर्यंतचा कालावधी अंदाजे 49% वाढला. बदलांच्या विनंत्या अधिक सामान्य झाल्या आणि प्रत्येक पुल रिक्वेस्टवरील टिप्पण्याही वाढल्या. हे निष्कर्ष पुनरावलोकनाचे काम वाढल्याचे सूचित करतात; मात्र एजंटने लिहिलेला प्रत्येक बदल निकृष्ट आहे असे ते दाखवत नाहीत किंवा दोषांचे मोजलेले प्रमाण सांगत नाहीत.

मोठा बदल

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

सहाय्यक आणि एजंटसाठी अंदाज वेगवेगळे होते

लेखक सहाय्यकआणि एजंटयांच्यात फरक करतात. विकासक काम करत असताना सहाय्यक कोडच्या सूचना देतात; एजंट उच्चस्तरीय काम स्वीकारून विकासकाने निकाल मंजूर करण्यापूर्वी अनेक टप्पे पूर्ण करू शकतात. GitHub Copilot आणि Cursor व्यावसायिक परवान्यांच्या सक्रियतेवरून सहाय्यकांचा स्वीकार मोजला. एजंटसाठी Claude Code वापराचा डेटा आणि कमिट किंवा पुल रिक्वेस्टमधील बॉट खाती व साधनांच्या स्वाक्षऱ्यांसारखे संकेत एकत्र केले. काही वैयक्तिक वापर किंवा समाकलित नसलेली साधने या मोजमापातून सुटू शकतात. एजंटचा अंदाज म्हणजे सहाय्यक स्वीकाराच्या आधीच्या कालखंडाच्या तुलनेत एजंट स्वीकाराशी असलेला अतिरिक्त संबंध; एजंट वापरणाऱ्या प्रत्येक व्यक्तीसाठीचा अंदाज नव्हे.

सहाय्यकांचे परिणाम कमी होते: कोडच्या ओळींमध्ये अंदाजे 12%, कमिटमध्ये 9% आणि पुल रिक्वेस्टमध्ये 5% वाढ. लेखाच्या मुख्य अंदाजांमध्ये फक्त कमिटचा परिणाम सांख्यिकीयदृष्ट्या लक्षणीय होता. एजंट स्वीकारामुळे तिन्ही कोडिंग-क्रियाकलाप मापदंडांत लक्षणीय वाढ दिसली. कमिट कोडमधील अद्ययावत बदल नोंदवतो; पुल रिक्वेस्ट बदल पुनरावलोकनासाठी सादर करते. यांपैकी कोणतेही वैशिष्ट्य वापरकर्त्यांपर्यंत पोहोचल्याचे सिद्ध करत नाही. पुनरावलोकन, चाचणी आणि तैनातीनंतर टीम काम पूर्ण म्हणून चिन्हांकित करतात, त्या नोंदवलेल्या कार्यप्रवाहावर आधारित लेख पूर्ण झालेले Jira इश्यू आणि मोठे एपिक हे पुढील टप्प्यातील उत्पादनाचे माप मानतो. वापरकर्त्यांना प्रत्यक्ष काय मिळाले याचे स्वतंत्र मोजमाप नसून Jira स्थिती वितरणाचा पर्यायी निर्देशक राहते.

एजंटसाठी निकाली निघालेल्या इश्यूंमध्ये प्रति कर्मचारी-महिना अंदाजे 0.12 वाढ होती; आधाररेषा 3.67 आणि मानक त्रुटी 0.17 होती. हा परिणाम सांख्यिकीयदृष्ट्या शून्यापासून वेगळा नाही. एपिक पूर्ण होण्यातही लक्षणीय बदल दिसला नाही. अभ्यासकालावधीत इश्यू पूर्णतेतील वाढ आधाररेषेच्या सरासरीच्या 12% पेक्षा अधिक असल्याचे विश्वास-अंतर नाकारते, असे लेखक सांगतात. एजंट कोणतेही उपयुक्त सॉफ्टवेअर तयार करत नाहीत असे म्हणण्यापेक्षा हा अधिक मर्यादित निष्कर्ष आहे: माफक लाभ शक्य आहेत आणि इश्यूची संख्या मूल्य किंवा गुणवत्तेतील प्रत्येक बदल पकडू शकत नाही. अंदाजित कामाच्या कालावधीच्या मापांचा वापर करून इश्यूचा आकार बदलला का हे लेखकांनी तपासले; नमुन्यात असा बदल झाल्याचा पुरावा त्यांना मिळाला नाही.

पुनरावलोकनकर्त्यांपर्यंत अधिक काम पोहोचले

पुनरावलोकनाची मोजमापे उत्पादनातील फरकासाठी संभाव्य यंत्रणा दाखवतात. एजंट स्वीकारल्यानंतर पुल रिक्वेस्ट सादर केल्यापासून मर्ज होईपर्यंत 3.45 दिवसांची भर पडल्याचा लेखाचा अंदाज आहे; आधाररेषा 7.03 दिवस होती, म्हणजे 49% वाढ. हा पुनरावलोकन प्रक्रियेतील दिनदर्शिकेचा कालावधी आहे; एखाद्याने सक्रियपणे पुनरावलोकन केलेल्या मिनिटांचे स्टॉपवॉच मोजमाप नाही. औपचारिक बदल-विनंती मिळालेल्या पुल रिक्वेस्टचा हिस्सा 13% आधाररेषेवरून सुमारे 12 टक्के-बिंदूंनी वाढला; प्रत्येक विनंतीवरील टिप्पण्या 1.66 आधाररेषेवरून 0.58 ने, म्हणजे 35% वाढल्या. महिन्यात किमान एक पुल रिक्वेस्ट तपासणाऱ्या कर्मचाऱ्यांचा हिस्सा 29% आधाररेषेवरून सुमारे चार टक्के-बिंदूंनी वाढला, म्हणजे सापेक्ष वाढ 14%. तुलनात्मक सहाय्यक-अंदाजांमध्ये पुनरावलोकनाचा कालावधी, बदल-विनंत्या किंवा टिप्पण्यांमध्ये लक्षणीय वाढ दिसली नाही.

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

नमुना कंपन्यांमध्ये AI पुनरावलोकन साधनेही पसरली होती: मार्च 2026 पर्यंत जवळपास 80% कंपन्यांनी त्यांपैकी एखादे साधन वापरले होते. तरीही लेख पुनरावलोकन टिप्पण्यांपैकी 23.3% AI ला जोडतो आणि 10.8% पुल रिक्वेस्टमध्ये किमान एक AI टिप्पणी असल्याचे नोंदवतो. त्यामुळे पुनरावलोकन साधन स्वीकारले म्हणजे या कंपन्यांतील पुनरावलोकन स्वयंचलित झाले असा अर्थ होत नाही.

या रचनेतून काय ठरवता येते

संशोधकांनी संमती दिलेल्या 718 Jellyfish ग्राहक कंपन्यांतील जानेवारी 2021 ते मार्च 2026 दरम्यानच्या सुमारे 300 दशलक्ष कामाच्या घटना तपासल्या; त्यात 725,938 कर्मचारी होते. सहाय्यक किंवा एजंट स्वीकारण्यापूर्वी व नंतरचे परिणाम, नंतर स्वीकारलेल्या किंवा अद्याप न स्वीकारलेल्या कंपन्यांशी तुलना करण्यासाठी त्यांनी टप्प्याटप्प्याच्या difference-in-differences रचनेचा वापर केला. कंपनी आणि दिनदर्शिकेच्या महिन्याचे नियंत्रण काही स्थिर फरक व सामायिक कालप्रवाह हाताळतात. स्वीकार झाला नसता तर कंपन्यांचे मार्ग किती तुलनीय राहिले असते यावर निष्कर्ष अवलंबून आहेत. मोठ्या कंपन्यांनी आधी स्वीकार केला; न मोजलेले बदल स्वीकार आणि अभियांत्रिकी काम या दोन्हींवर परिणाम करू शकले असते. हा निरीक्षणाधारित अभ्यास आहे; त्याचे अंदाज यादृच्छिक चाचणी किंवा सर्व सॉफ्टवेअर टीमसाठीचे भाकीत म्हणून वाचू नयेत.

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

BIG CHANGE चे याआधीचे वृत्तांकन AI कोडिंग आणि विश्वासार्ह वितरणावरील एका वेगळ्या अभियांत्रिकी उदाहरणाचे परीक्षण केले होते. हा अभ्यास अनेक कंपन्यांचा दृष्टिकोन आणि कोडिंग क्रियाकलाप, पुनरावलोकन व निकाली निघालेल्या कामाचे स्वतंत्र माप देतो. एजंटचे मूल्यमापन करताना हे टप्पे एकत्र नोंदवावेत हा व्यावहारिक धडा आहे: जलद पहिला मसुदा पुढील टप्प्यांत प्रतीक्षेत असलेल्या कामाचे प्रमाण बदलतो, आणि या लेखात अद्याप पूर्ण झालेल्या इश्यू किंवा प्रकल्पांमध्ये तितकीच वाढ दिसत नाही.

स्रोत आणि पुढील वाचन

  • Fiona Chen आणि James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production: मुख्य कार्यपत्रिका; सध्याची आवृत्ती 4 ऑगस्ट 2026 ची. पद्धती, आकृत्या आणि परिशिष्टे नोंदवलेल्या अंदाजांना व त्यांच्या मर्यादांना आधार देतात; कंपनीस्तरीय मूळ डेटा मालकीचा असून एकत्रित स्वरूपात आहे.
  • Ars Technica चा 9 ऑक्टोबरचा वृत्तांत: या लेखाकडे लक्ष वेधणारा समकालीन स्वतंत्र वृत्तांत. वरील संख्यात्मक व पद्धतीविषयक दावे मूळ लेखाशी पडताळले.
  • AI कोडिंग आणि CI वरील BIG CHANGE चा आधीचा लेख: वेगळ्या अभियांत्रिकी उदाहरणावरील संबंधित वृत्तांकन. वितरणाच्या प्रश्नाला संदर्भ देतो, पण या अभ्यासाचा पुढील भाग नाही.