AI का डेवलपर उत्पादकता पर प्रभाव - Stanford शोध
(youtube.com)परिचय ‒ AI डेवलपर उत्पादकता को लेकर भ्रम और वास्तविकता
- Mark Zuckerberg (Meta CEO) ने यह घोषणा की कि "2025 के अंत तक सभी mid-level engineers को AI से बदल दिया जाएगा", जिसके बाद विभिन्न कंपनियों के CTOs पर भी वैसा ही दबाव पड़ा।
- वक्ता ने स्पष्ट किया कि "AI डेवलपर्स को पूरी तरह replace नहीं कर सकता", और ज़ोर दिया कि AI अपनाने से उत्पादकता में निश्चित रूप से मदद मिलती है, लेकिन हमेशा नहीं; कई मामलों में उत्पादकता घट भी जाती है।
शोध डिज़ाइन और डेटा
- 3 साल तक, लगभग 600 कंपनियाँ, 1 लाख से अधिक software engineers, 1 अरब से अधिक lines of code, और करोड़ों commits पर मापन।
- अधिकांश डेटा private repositories (Private Repo) पर आधारित था → इसलिए डेवलपमेंट टीम और कंपनी स्तर पर वास्तविक उत्पादकता परिवर्तन को मापा जा सका।
मौजूदा शोध की सीमाएँ
- vendor-driven reports अक्सर अपनी AI tools के प्रचार के उद्देश्य से बनती हैं, इसलिए उनमें निष्पक्षता की कमी होती है।
- सिर्फ commit/PR की संख्या, औसत काम के समय में बदलाव आदि से वास्तविक उत्पादकता विकृत हो सकती है।
- उदाहरण: AI उपयोग के तुरंत बाद bugs या rework वाले commits भी बढ़ जाते हैं, जिससे ऊपर-ऊपर ऐसा लगता है कि उत्पादकता बढ़ गई है।
- "greenfield (नया project) experiments" में AI का असर बहुत बड़ा दिखता है, लेकिन मौजूदा code (brownfield) में यह अंतर कम हो जाता है।
- डेवलपर सर्वेक्षण (self-report) का वास्तविक उत्पादकता से बड़ा संबंध नहीं मिला (महसूस की गई बढ़त और वास्तविक परिणाम में 30% से अधिक points का अंतर)।
Stanford का उत्पादकता मापन मॉडल
- expert panel evaluation के समान एक AI-based automated model का उपयोग:
- हर commit में functional changes (added/removed/refactored/rework) को मापा गया
- सिर्फ "lines of code" नहीं, बल्कि "functionality, maintainability, quality" पर फ़ोकस
- फीचर जोड़ने की मात्रा, refactoring, हालिया commits के rework अनुपात आदि को विस्तार से देखा गया।
प्रमुख शोध निष्कर्ष
- कुल मिलाकर AI अपनाने पर औसत उत्पादकता 15~20% बढ़ी।
- लेकिन इसके साथ काफ़ी मात्रा में "rework" भी जुड़ा था, इसलिए महसूस होने वाला लाभ कई बार बढ़ा-चढ़ाकर दिख सकता है।
- टीम/कंपनी/टास्क के प्रकार के अनुसार बहुत बड़ा अंतर पाया गया।
उत्पादकता अंतर के कारण: टास्क कठिनाई·प्रोजेक्ट प्रकार·भाषा·codebase का आकार
| प्रोजेक्ट प्रकार | कम जटिलता | उच्च जटिलता |
|---|---|---|
| ग्रीनफील्ड (नया) | 30~40% ↑ | 10~15% ↑ |
| ब्राउनफील्ड (मौजूदा) | 15~20% ↑ | 0~10% ↑ |
- कम जटिलता वाले, नए (greenfield) projects में AI का प्रभाव बड़ा था।
- मौजूदा (brownfield) और जटिल systems में इसका असर स्पष्ट रूप से घट गया, और कुछ मामलों में उत्पादकता घटने के उदाहरण भी मिले।
- वास्तविक नमूना: 27 कंपनियाँ और 136 टीमें (लेक्चर में उल्लेख)।
भाषा की लोकप्रियता और AI का प्रभाव
- Python/Java/JavaScript (लोकप्रिय भाषाएँ) में AI से उत्पादकता वृद्धि अधिक थी,
- COBOL/Elixir/Haskell (कम लोकप्रिय भाषाएँ) में AI की मदद लगभग नहीं मिली, बल्कि जटिल कामों में समय की बर्बादी और उत्पादकता में गिरावट तक हुई।
- उदाहरण: कम लोकप्रिय भाषा + उच्च कठिनाई के मामले में "errors ज़्यादा, सही code नहीं" → ऐसे में AI न होना ही बेहतर।
codebase का आकार और AI का प्रभाव
- codebase जितना बड़ा होता गया, AI से उत्पादकता बढ़ने का प्रभाव उतनी ही तेज़ी से घटता गया।
- कारण:
- context window की सीमा: LLM कई files या लाखों lines के पूरे संदर्भ को एक साथ नहीं संभाल सकता।
- "signal/noise ratio" में गिरावट: संदर्भ जानकारी बढ़ने पर AI के लिए सही जानकारी पहचानना कठिन हो जाता है।
- domain और service-स्तर की जटिलता बढ़ने पर वास्तविक पुनर्निर्माण की कठिनाई बढ़ जाती है।
- वास्तव में बड़े नवीनतम LLMs (Gemini 1.5 Pro आदि) में भी "token" की संख्या बढ़ने पर सटीकता 90% से घटकर 50% से नीचे चली जाती है।
- कारण:
संक्षेप: AI कब प्रभावी है?
- AI अधिकांश मामलों में, खासकर सरल नया code लिखने में, डेवलपर उत्पादकता को स्पष्ट रूप से बढ़ाता है।
- लेकिन जटिल maintenance, पुराना (बड़ा) code, niche languages, और बहुत सारी dependencies वाले माहौल में इसकी सीमाएँ बड़ी हैं।
- सबसे अच्छी AI productivity strategy वही होगी जो कंपनी, टीम और टास्क की विशेषताओं के अनुसार सावधानी से डिज़ाइन की जाए (यह "one size fits all" नहीं है)।
- surveys, marketing metrics, और सिर्फ commits की संख्या जैसी चीज़ों पर भरोसा करना कठिन है; इसके बजाय code functionality, repetitive work ratio, और rework जैसे "वास्तविक" मापदंड ज़रूरी हैं।
अतिरिक्त टिप्पणियाँ और उदाहरण
- "ghost engineer": डेटा में लगभग 10% engineers ऐसे भी मिले जो लगभग कोई काम नहीं करते थे लेकिन वेतन लेते थे।
- टीम लीड्स और CTOs के लिए वास्तविक समस्याओं की तेज़ पहचान हेतु "metrics-based decision-making" tools की आवश्यकता पर ज़ोर दिया गया।
निष्कर्ष
- AI "अधिकांश परिस्थितियों" में उत्पादकता बढ़ाता है, लेकिन इसके अतिमूल्यांकन और कम-मूल्यांकन दोनों से सावधान रहना चाहिए।
- इसे लागू करने से पहले उन "विशिष्ट परिस्थितियों (सरल/नया/लोकप्रिय भाषा/छोटा codebase)" को समझना चाहिए जहाँ परिणाम अच्छे आते हैं; बिना सोचे-समझे, हर जगह समान रूप से लागू करना उल्टा नुकसान पहुँचा सकता है।
2 टिप्पणियां
भले ही इसे मुख्य software में लागू न किया जाए, test program या project की शुरुआती stage में भी AI बहुत समय बचा देता है.
अगर code लिखवाने वाली बात को अलग भी रख दें, तो AI आने के बाद assistant features में ज़मीन-आसमान का फर्क आ गया है. अब मुझे लगता है कि हम ऐसे दौर में आ गए हैं जहाँ AI विकल्प नहीं, बल्कि अनिवार्य है.
असल में MVP में यह बहुत मददगार होता है। खासकर comments, logging और history लिखने में तो मुझे लगता है कि इसे ज़रूर इस्तेमाल करना चाहिए।
लेकिन codebase बड़ा होने पर hallucination होने लगती है, मौजूदा code को भूल जाता है और अजीब नतीजे बनाता है। context engineering का इस्तेमाल करना या codebase को छोटा रखने के तरीके पर सोचना होगा।
शायद अगर और बड़े prompts इस्तेमाल कर सकें तो यह बेहतर हो सकता है।
फिलहाल Java, Python, JavaScript और Go में यह अच्छी तरह काम करता लगता है। मैं मुख्य रूप से Copilot इस्तेमाल करता हूँ, और Claude व ChatGPT भी इस्तेमाल करता हूँ.