- 2025 की शुरुआत के AI tools का open source डेवलपर्स की वास्तविक उत्पादकता पर प्रभाव देखने के लिए एक randomized controlled trial किया गया
- अध्ययन के नतीजों के अनुसार, AI tools का उपयोग करने पर काम पूरा करने में औसतन 19% अधिक समय लगा
- डेवलपर्स को उम्मीद थी कि AI उन्हें 24% अधिक तेज़ बनाएगा, लेकिन वास्तविक अनुभव के विपरीत गति में कमी देखी गई
- benchmark और रोज़मर्रा के अनुभव में दिखाई देने वाली AI क्षमता और उसके वास्तविक प्रभाव के बीच का अंतर बहुत स्पष्ट है
- यह अध्ययन AI productivity impact की सटीक समझ और विविध evaluation methods के महत्व पर ज़ोर देता है
अवलोकन
- यह अध्ययन 2025 की शुरुआत (Early-2025) के AI tools का अनुभवी open source डेवलपर्स की उत्पादकता पर प्रभाव जानने के लिए randomized controlled trial (RCT) करता है
- अपेक्षा के विपरीत, AI tools का उपयोग करते समय डेवलपर्स को 19% अधिक समय लगना पाया गया
- इस परिणाम को software development पर AI research automation के वास्तविक प्रभाव को मापने के एक उदाहरण के रूप में देखा जा सकता है
- अध्ययन ने कहा कि इसी methodology के आधार पर AI R&D acceleration के वास्तविक प्रभाव का निरंतर अनुमान लगाया जाएगा
अध्ययन की प्रेरणा
- मौजूदा coding/agent benchmarks में वास्तविक कामकाजी परिस्थितियों को पर्याप्त रूप से दिखाने की सीमाएँ हैं
- self-contained tests, context के बिना एक-बार वाले tasks, और automatic grading structure की वजह से AI क्षमता का अधिक आकलन हो सकता है
- दूसरी ओर, यदि मानव का adaptive intervention न हो, तो वास्तविक AI model performance का कम आकलन भी संभव है
- इन सीमाओं की भरपाई के लिए वास्तविक open source डेवलपर productivity पर प्रभाव का परीक्षण कर AI के यथार्थ प्रभाव को मापा गया
प्रयोग की विधि
- 16 अनुभवी open source डेवलपर्स को शामिल किया गया, और उनके द्वारा कई वर्षों से संभाले जा रहे बड़े repositories (औसतन 22,000+ stars, 10,00,000+ lines of code) से 246 वास्तविक issues चुने गए
- प्रत्येक issue के लिए प्रतिभागियों को यादृच्छिक रूप से AI उपयोग की अनुमति या निषेध वाले समूह में रखा गया
- AI की अनुमति होने पर डेवलपर्स Cursor Pro और Claude 3.5/3.7 Sonnet जैसे नवीनतम models का स्वतंत्र रूप से उपयोग कर सकते थे; निषेध की स्थिति में उन्होंने generative AI की मदद के बिना काम किया
- प्रतिभागियों ने हर issue (औसतन 2 घंटे) को हल करने की प्रक्रिया रिकॉर्ड की और अपना समय स्वयं रिपोर्ट किया
- प्रतिभागियों को प्रति घंटा 150 डॉलर का भुगतान किया गया
मुख्य परिणाम
- AI tools का उपयोग करने पर issue हल करने में औसतन 19% अधिक समय लगा
- डेवलपर्स को उम्मीद थी कि AI वास्तव में उनकी उत्पादकता 24% बढ़ाएगा, और प्रयोग के बाद भी उन्होंने उत्तर दिया कि उन्हें अब भी 20% की speed-up महसूस हुई
- इस तरह धारणा और वास्तविक प्रदर्शन के बीच बड़ा अंतर दिखाई दिया
- कुछ गलतफहमियों से बचने के लिए, यह अध्ययन निम्न बातों पर कोई प्रमाण प्रस्तुत नहीं करता:
- यह सामान्यीकरण कि सभी डेवलपर्स या पूरे software development में AI काम को धीमा कर देता है
- अन्य domains या settings में AI के प्रभाव को परिभाषित करना
- यह निश्चित रूप से कहना कि निकट भविष्य में भी यही परिणाम बने रहेंगे
- यह दावा कि मौजूदा LLM और prompting techniques का optimization संभव नहीं है
प्रभाव कारकों का विश्लेषण
- देरी को समझाने वाले 20 कारकों का विश्लेषण किया गया, जिनमें से 5 को वास्तविक प्रभावकारी माना गया
- यह पाया गया कि experimental condition, model, issue difficulty, PR quality जैसे प्रमुख variables का नतीजों पर कोई महत्वपूर्ण प्रभाव नहीं था
- देरी की यह प्रवृत्ति अलग-अलग data subsets और estimation methods में भी लगातार देखी गई
- विस्तृत विश्लेषण paper के मूल पाठ में देखा जा सकता है
परिणामों की व्याख्या और चर्चा
प्रमाणों का टकराव और उसके कारण
- AI benchmark scores/case reports/वास्तविक experiments के बीच नतीजों का अंतर स्पष्ट है
- benchmarks, automatic grading वाले सीमित प्रकार के प्रश्नों पर केंद्रित होकर AI क्षमता को मापते हैं
- SWE-Bench: test-based open source PR, RE-Bench: algorithmically evaluable problems
- वास्तविक RCT में 20 मिनट से 4 घंटे लेने वाले जटिल और यथार्थ tasks में इंसान उल्टा अधिक धीमा हो गया
- वहीं उद्योग और community में AI लंबे समय वाले काम में काफी उपयोगी है जैसी कई गुणात्मक reports मौजूद हैं
व्याख्या का framework
- हर approach "वास्तविक क्षमता" को अलग तरीके से मापती है
- case-by-case approach:
- RCT के underestimation की समस्या: संभव है कि यह केवल हमारी experiment setting की विशेषता हो
- benchmark/case के overestimation की संभावना: वास्तविक solving process से अंतर, और self-reported evidence की सीमित विश्वसनीयता
- यह भी संभव है कि तीनों approaches वास्तविकता के केवल कुछ subproblems पर ही अच्छी तरह लागू होती हों
- अलग-अलग sources और वास्तविक क्षमता के बीच की दूरी को measurement error·bias (लाल), measurement scope के अंतर (नीला) के रूप में समझा जा सकता है
प्रयोग से मिलने वाले अतिरिक्त संकेत
- RCT के नतीजे ऐसे वातावरण पर लागू नहीं हो सकते जहाँ AI output को सैकड़ों या हज़ारों बार sample किया जाता है
- Cursor जैसे AI tools को दर्जनों से सैकड़ों घंटे इस्तेमाल करने के बाद ही efficiency gain दिखने की संभावना है
- उच्च-गुणवत्ता वाले code और अधिक implicit requirements (documentation, testing, formatting आदि) वाले माहौल में AI की क्षमता सीमित हो सकती है
- benchmarks की problem scope संकीर्ण होने के कारण वे वास्तविक काम की कठिनाई को ठीक से नहीं दर्शाते
- गुणात्मक अनुभव-आधारित reports की विश्वसनीयता overestimation और self-deception effect के कारण कम हो सकती है
- कोई एकल evaluation method पूर्ण नहीं है, इसलिए उन्हें पूरक रूप से इस्तेमाल करने की आवश्यकता पर ज़ोर दिया गया
आगे की दिशा
- इस methodology को लगातार बेहतर बनाकर यह मात्रात्मक रूप से ट्रैक किया जाएगा कि AI tools वास्तव में डेवलपर productivity को कितना बदलते हैं
- अगर AI tools मैदान में काम कर रहे डेवलपर्स की efficiency को बहुत बढ़ा दें, तो AI R&D में तेज़ acceleration / monitoring failure / power concentration के जोखिम भी साथ आ सकते हैं
- वास्तविक वातावरण के अनुकूल evaluation framework का विकास, AI की आगे की प्रगति और पूरे उद्योग के लिए बहुत महत्वपूर्ण है
2 टिप्पणियां
$150 प्रति घंटा? वहीं से variables control ही गड़बड़ है lol
Hacker News राय
Simon Willison की टिप्पणी:
पूरा पेपर उन विवरणों से भरा है जो सारांश में छूट गए हैं पेपर लिंक
मेरी निजी राय में, LLM-आधारित AI टूल्स से वास्तविक उत्पादकता लाभ पाने के लिए लोगों की अपेक्षा से कहीं अधिक तीखी learning curve होती है
इस अध्ययन में 16 लोग शामिल थे, जिनका अलग-अलग AI टूल्स के उपयोग का अनुभव था, और 56% ने Cursor पहली बार इस्तेमाल किया था; अध्ययन मुख्यतः Cursor पर केंद्रित था
प्रत्येक प्रतिभागी ने कुल लगभग 15 issues पर काम किया, और हर issue के लिए AI उपयोग की अनुमति/मनाही को random तरीके से तय किया गया
यानी एक ही डेवलपर ने AI-allowed और AI-disallowed tasks का मिश्रण किया
केवल 1/4 प्रतिभागियों का प्रदर्शन बेहतर हुआ और 3/4 का प्रदर्शन गिरा
AI उपयोग में शीर्ष समूह वे लोग थे जिन्होंने Cursor 50 घंटे से अधिक इस्तेमाल किया था
शोधकर्ताओं ने भी माना कि जिन डेवलपर्स को Cursor का पर्याप्त अनुभव था, उनकी performance बेहतर हुई
मेरा अंदाज़ा है कि यह पेपर दिखाता है कि AI के साथ collaborative development में learning curve ऊँची होने के कारण, इसे मौजूदा workflow में सीधे मिला देने पर व्यवहार में performance घट सकती है
LLM के बारे में “तुमने इसे सही तरह से इस्तेमाल नहीं किया” वाली आम प्रतिक्रिया आती है, लेकिन यह मुझे उपयोगकर्ता पर ज़िम्मेदारी डालने वाला बहाना लगता है
ज़्यादातर तकनीकी उत्पादों में, अगर उपयोगकर्ता को value नहीं मिलती तो हम मानते हैं कि product design में ही समस्या है; समझ नहीं आता कि AI पर यह तर्क क्यों लागू नहीं होता
Simon का धन्यवाद, और पेपर को इतनी बारीकी से पढ़ने के लिए भी शुक्रिया - मैं OS प्रोजेक्ट्स का प्रशंसक हूँ और कुछ महत्वपूर्ण बिंदु रखना चाहता हूँ
1) पहले के कुछ अध्ययनों में कम tool experience के बावजूद performance improvement दिखा है, इसलिए केवल “steep learning curve” सिद्धांत से इस परिणाम की पूरी व्याख्या नहीं होती
2) अध्ययन से पहले 90% से अधिक प्रतिभागियों के पास LLM prompting का अनुभव था, और prompting को ही मुख्य skill माना जाता था. सामान्य धारणा यह थी कि जो VSCode में सहज है, वह Cursor भी आसानी से इस्तेमाल कर लेगा
3) अगर सभी AI के अभ्यस्त थे, तो AI के बिना वे उल्टा और खराब perform कर सकते थे (कम-से-कम मुझे यह बात समझ में आती है); ऐसे में AI वास्तव में बेहतर दिखने का illusion कम हो जाता है
4) experience संबंधी जानकारी prediction experts के साथ पहले से साझा की गई थी, फिर भी predictors ने productivity gain की अपेक्षा बहुत ज़्यादा रखी
5) सैकड़ों घंटों के उपयोग से विकसित होने वाली long-tail skills वास्तव में मौजूद हो सकती हैं; यह अध्ययन उस स्तर तक कुछ ठोस कहने की स्थिति में नहीं है
पेपर का परिणाम चौंकाने वाला है, इसलिए इसे पढ़ने वाले लोग किसी एक कारण को चुनकर आसानी से कह सकते हैं “यही वजह है!”
वास्तव में यह कई कारणों का संयुक्त परिणाम हो सकता है (कम-से-कम 5, और शायद 9 तक को खारिज नहीं किया जा सकता; पेज 11 की तालिका देखें)
एक बहुत महत्वपूर्ण संकेत यह है: डेवलपर्स की self-reported satisfaction और वास्तविकता के बीच बहुत बड़ा अंतर था, और यह इस्तेमाल किए गए tool के प्रकार से स्वतंत्र था
productivity मापने के लिए field में इकट्ठा किया गया वास्तविक डेटा बहुत ज़रूरी है (पेपर के C.2.7 में “below-average AI tool use” सेक्शन देखें)
इसे इस तरह भी पढ़ा जा सकता है कि 75% प्रतिभागियों के पास LLM अनुभव होने के बावजूद AI इस्तेमाल करने पर उनका काम और धीमा हो गया; एक व्याख्या यह है कि LLM की learning curve बहुत खड़ी है, दूसरी यह कि प्रोग्रामिंग सहायता में मौजूदा LLMs की वास्तविक उपयोगिता को बढ़ा-चढ़ाकर आँका गया है, और लोग लगातार performance का गलत अनुमान लगा रहे हैं
LLM को अच्छी तरह इस्तेमाल करना सीख लेने के बाद भी, व्यक्ति को अपने ही लिखे code की समझ कम हो सकती है
डेवलपर समय के साथ codebase में गहराई से पारंगत होता जाता है, लेकिन LLM उल्टा समय के साथ कम प्रभावी हो सकता है
LLM से जल्दी code generate किया जा सकता है, लेकिन अगर आप सावधान नहीं हैं तो code की समझ और skill जमा नहीं होती
शुरुआत में development फुर्तीला और तेज़ लगता है, लेकिन पीछे से समझ कमज़ोर रहती है, और LLM भी शुरुआती stage में उपयोगी लगने के बाद धीरे-धीरे सुधार नहीं करता; एक बिंदु पर पहुँचकर code ऐसा बिखरा हुआ mess बन जाता है जिसे न LLM संभाल पाता है न उपयोगकर्ता
मेरा मानना है कि लालच से बचते हुए LLM से साफ-सुथरा code निकलवाने के लिए लगातार अनुशासन चाहिए, और व्यक्ति को खुद भी code ज़रूर पढ़ना-समझना चाहिए; स्वयं समझने की कोशिश ज़रूरी है
यह साफ दिखता है कि AI tools से कुछ लोगों की productivity बढ़ी और कुछ की नहीं
मेरा अनुमान है कि जो लोग लंबे text या code को जल्दी पढ़ सकते हैं, उन्हें बड़ा फायदा मिलता है
बेकार suggestions को जल्दी पहचानना और अच्छे जवाब तक पहुँचने के लिए दोहराव करते रहना बहुत महत्वपूर्ण skill है
तेज़ scanning क्षमता का संबंध अनुभवी लोगों से होता है, लेकिन आश्चर्यजनक रूप से कुछ नए लोग भी इसमें तेज़ होते हैं
search skill मजबूत होने वाले लोग LLM उपयोग में भी बेहतर हो सकते हैं; यह Google search skill जैसी ही बात लगती है
इससे 80/20 rule फिर याद आता है - कुल काम का 80% वह 20% समय में कर देता है, और बाकी 20% के लिए 80% समय खर्च हो जाता है
हमेशा लगता रहता है कि “बस लगभग हो गया”, इसलिए sunk cost fallacy में फँसना आसान हो जाता है
हाल में मैंने एक तरीका अपनाया है जिसमें AI को “समाधानकर्ता” नहीं बल्कि “friction remover” की तरह इस्तेमाल करता हूँ
प्रोग्रामिंग मैं खुद करता हूँ, और केवल छोटी-छोटी भूली हुई syntax जैसी चीज़ें AI से पूछकर गति बढ़ाता हूँ
सीधे पूरे code suggestions मैं लगभग देखता ही नहीं; मैं हमेशा खुद सोचते हुए code लिखता हूँ, ताकि समझ और skill कमज़ोर न पड़े
पहले यह reverse-Pareto जैसा था: 80% काम के लिए 80% effort, और बचे 20% के लिए फिर 80% effort
AI का इस्तेमाल केवल “छोटी रुकावटें” हटाने के लिए करना, इस बात से मैं सहमत हूँ
कल ही Java stream API के साथ List process करते समय ConcurrentOperationsException ने परेशान किया
मैं खुद method लिख रहा था लेकिन बात नहीं बनी, तो मैंने AI से “thread-safe list conversion method” पूछा और उसने बताया कि संबंधित API में built-in method पहले से है
ऐसे तरह-तरह के छोटे मसलों में AI बेहतरीन है - जब समस्या जटिल हो लेकिन स्पष्ट रूप से परिभाषित हो
यह Stack Overflow के अधिक शक्तिशाली रूप की तरह खास तौर पर उपयोगी है, जब मुझे मोटे तौर पर पता होता है कि क्या करना है लेकिन अपने environment के हिसाब से कैसे करना है यह नहीं पता होता; debugging और rubber ducking में भी यह मदद करता है
“आख़िरी 20% के लिए 80% समय खर्च होता है” यह AI से पहले भी मेरा अनुभव था; अगर वह शुरुआती समय ही कम कर दे तो भी अच्छा है. इस बारे में किसी अनुभवी व्यक्ति से AI पर सुनी गई सबसे अच्छी बात यह थी: “मेरी skill का 90% बेकार हो गया, और बाकी 10% हज़ार गुना ज़्यादा महत्वपूर्ण हो गया.” इसमें अतिशयोक्ति है, लेकिन मूल बात मुझे पसंद है
“हमेशा लगता है कि लगभग हो गया” वाली गलतफ़हमी ही उल्टा समय बर्बाद करवा सकती है; AI ऐसी चीज़ है जो खुद को उपयोगी दिखाने में माहिर है, इसलिए यह तय करने के लिए कि वास्तव में productivity बढ़ रही है या नहीं, बहुत ऊँचे स्तर की critical thinking चाहिए
मौजूदा codebase में features जोड़ते समय यह खास तौर पर उपयोगी है, जैसे “मौजूदा search parameters के अलावा foo जोड़ना है” या “x से संबंधित code हटाना है” जैसी tasks में
HN users के लिए, मैं इस पेपर का लेखक हूँ - मैं लंबे समय से HN user हूँ, और आज comments में आने वाले सवालों/feedback का जितना हो सके जवाब दे रहा हूँ. समय न हो तो पूरा पेपर पढ़ने के बजाय परिचयात्मक blog post या x.com पर announcement thread देख सकते हैं
पेपर की methodology और लेखक का संवाद करने का तरीका बहुत professional और प्रभावशाली है, बहुत अच्छा research है
मुझे लगता है कि यह सबसे अच्छे अध्ययनों में से एक है, क्योंकि यह clickbait के बिना ईमानदारी से परिणाम रखता है और पढ़ने में भी बहुत सुव्यवस्थित है
क्या आपने इस बात पर विचार किया कि AI से हल कराए गए tickets वास्तव में AI के लिए उपयुक्त प्रकार के थे या नहीं? “इस ticket को AI से करके देखो” वाला तरीका वास्तविक तो है, लेकिन शायद अक्षम भी हो सकता है. AI के लिए उपयुक्त ढंग से इस्तेमाल करने पर यह बहुत मदद करता है, लेकिन कई बार उल्टा असर भी देता है. अगर प्रतिभागियों के पास पर्याप्त AI अनुभव था तो वे यह भेद कर पाए होंगे, लेकिन पेपर पढ़ते हुए यह बात स्पष्ट नहीं होती
क्या anonymized raw dataset को संभव हो तो public किया जा सकता है, या कम-से-कम प्रति-developer absolute task duration का डेटा पेपर में जोड़ा जा सकता है? मैं जानना चाहता हूँ कि Cursor experience वाले प्रतिभागी वास्तव में दूसरों से तेज़ थे या वे मूलतः धीमे थे और AI से उन्हें अपेक्षाकृत अधिक uplift मिला. Hawthorne effect को भी ध्यान में रखने वाला इतना अच्छा experimental evaluation देखना सुखद है
(पेपर नहीं पढ़ा, सिर्फ पोस्ट देखा) क्या subjective fatigue को इस बात के संकेतक के रूप में मापा गया कि लोग AI को वास्तविकता से तेज़ क्यों मान लेते हैं? डेवलपर से manager बनने के बाद, जब दिमाग थका होता है, तब AI सुविधाजनक लगता है
इस अध्ययन का परिणाम, खासकर यह हिस्सा कि “डेवलपर्स ने उम्मीद की थी कि AI उनकी गति 24% बढ़ाएगा, लेकिन वास्तव में वे धीमे हो गए, फिर भी अनुभव के बाद उन्हें लगा कि वे 20% तेज़ थे”, बेहद रोचक है. वास्तविकता और धारणा के बीच इतना नाटकीय अंतर क्यों है? क्या ऐसा हो सकता है कि दिमाग ‘मानसिक प्रयास’ को समय के अनुभव के साथ गड़बड़ा देता हो?
मेरे पास कोई सबूत नहीं है, लेकिन एक डरावना विचार है: क्या coding के दौरान AI के साथ interaction दिमाग को social media dopamine loop जैसी किसी चीज़ से उत्तेजित करता है (भले उसी स्तर पर नहीं)? AI बार-बार जवाब पेश करता है, जिससे दिमाग को ऐसा लग सकता है कि उसे positive feedback मिल रहा है, और इसी कारण डेवलपर्स AI को उसकी वास्तविक उपयोगिता से ज़्यादा सकारात्मक मानते हों? अगर यह किसी प्रकार की addiction भी पैदा करे, तो क्या लोग उसकी वास्तविक productivity impact को बढ़ा-चढ़ाकर आँकने लगते हैं?
यह भी संभव है कि यह phenomenon उस बड़े campaign का नतीजा हो जिसने बाज़ार में बहुत से लोगों को AI tools को वास्तविकता से बेहतर मानने पर मजबूर किया है. economists और ML experts जैसे समूह स्वयं AI कंपनियों के हितों से जुड़े हो सकते हैं, और executives उन दावों को सीधे स्वीकार करके बड़े परिणामों का वादा करते हैं. इससे baseline expectation पूरे ecosystem में ऊपर चली जाती है, और इसका असर अनुभवी डेवलपर्स पर भी पड़ता है. इसे अनुभवजन्य रूप से साबित करना कठिन है, लेकिन यह AI productivity को लेकर फैली सामूहिक गलतफ़हमी की एक वजह हो सकती है
मैं सोचता हूँ कि HN comments के कई AI enthusiasts भी शायद इसी phenomenon में फँसे हों. जब तक कोई व्यक्ति खुद अपनी performance माप नहीं रहा, तब तक यह संदिग्ध है कि AI वास्तव में उसकी productivity बढ़ा भी रहा है या नहीं
कभी-कभी बिल्कुल उल्टा अनुभव भी होता है. आज मैंने Claude code से एक demo app का example code बनवाने की कोशिश की; देखते समय वह शानदार और SF जैसा लगा, मज़ेदार भी था, लेकिन 15 मिनट में ही दिमाग सुन्न और बोरियत महसूस होने लगी
“डेवलपर्स ने उम्मीद की थी कि AI 24% तेज़ करेगा, और वास्तव में धीमे होने के बावजूद उन्हें लगा कि वे 20% तेज़ थे” — इसे देखकर मुझे लगता है कि यहाँ दो समस्याएँ हैं
एक तो यह कि एक ही व्यक्ति के लिए, एक ही context में, AI के साथ और AI के बिना लगे समय की सही तुलना करना मुश्किल है
दूसरी यह कि PR open/merge होने तक के सतही metrics से AI efficiency मापना आसान है, जबकि वास्तव में AI अपनाने पर refactoring, testing, issue resolution जैसी बाद की गतिविधियों में अधिक समय लग सकता है
“PR जल्दी खुल गया” देखकर यह मान लेना आसान है कि AI तेज़ है, लेकिन आगे बढ़ने वाले काम की मात्रा बढ़ने को नज़रअंदाज़ करना भी आसान है
किसी विशेष तकनीक या practice का productivity पर प्रभाव मापना सचमुच बहुत कठिन है. केवल self-report या anecdote पर भरोसा करके निष्कर्ष निकालना खतरनाक है, क्योंकि कोई भी आसानी से self-delusion में फँस सकता है. अध्ययन खुद भी अपनी सीमाएँ मानता है, इसलिए productivity की चर्चा में बड़े error bars को ध्यान में रखना चाहिए. AI मेरी ज़िंदगी में देखी गई सबसे अजीब technologies में से एक है; बिखरे हुए उदाहरणों या संदिग्ध benchmarks से causality निकालना लगभग कुंडली पढ़ने जैसा है
पेपर में AI-allowed और AI-disallowed स्थितियों के बीच PR quality में गिरावट नहीं देखी गई. अधिकांश प्रतिभागी repository standards से परिचित थे और ‘बस कुछ भी submit करके PR उठा दो’ शैली के नहीं थे. अध्ययन में PR की median review time लगभग 1 minute थी. लेखक की बात सही है कि समय के उपयोग का पैटर्न पूरी तरह बदल जाता है. पेपर के पेज 10 पर AI उपयोग/अनुपयोग के अनुसार time distribution दी गई है: AI के साथ coding time घटता है, लेकिन AI से interaction का समय बढ़ता है
“एक ही व्यक्ति, एक ही context में AI के साथ और बिना AI के अलग-अलग लगे समय को ठीक-ठीक जानना असंभव है” — इस आपत्ति के जवाब में, experimental design में random assignment के ज़रिए AI और non-AI group effect को अलग किया गया. व्यक्ति, परिस्थिति, environment जैसी भिन्नताएँ randomization से संतुलित हो जाती हैं. अगर sample और effect size पर्याप्त बड़े हों, तो statistically meaningful अंतर निकाला जा सकता है
Figure 21 देखने पर लगता है कि शुरुआती implementation (PR तक पहुँचने का समय) भी बढ़ा, और PR review के बाद समय कुछ और बढ़ा, लेकिन कुल मिलाकर उसका प्रभाव बहुत बड़ा नहीं दिखता. Figure 18 से दिखता है कि actual coding time घटा, लेकिन prompt लिखने, output का इंतज़ार करने और उसे review करने में समय बढ़ने से वह लाभ संतुलित हो गया. 5 मिनट से कम के सरल tasks में शायद LLM का उपयोग न करना ही बेहतर होता
मैं हर workflow के अनुसार PR content की तुलना देखना चाहूँगा. Copilot अक्सर मेरे खुद करने की तुलना में अधिक code सुझाता है, लेकिन उसमें अनावश्यक checks, repetition, और abstraction के बिना code volume बढ़ने की प्रवृत्ति होती है. मेरी निजी hypothesis है कि जब LLM बहुत सारा code उगलता हुआ दिखता है, तो इससे समस्या हल होने में लगने वाले समय का व्यक्ति का आभास विकृत हो जाता है
बड़े codebase पर LLM के साथ काम करते समय असली कठिनाई यह है कि किए जाने वाले काम का सटीक वर्णन कैसे किया जाए. code interactions से भरे issue को समझाकर बताने में कभी-कभी हाथ से खुद हल करने से भी ज़्यादा समय लग जाता है; इसके उलट, नए project में boilerplate code बनाते समय LLM सबसे अच्छा फिट बैठता है
केवल प्रतिभागी डेवलपर्स की भर्ती पर ही 300 x 246 = लगभग 73K खर्च किए गए, फिर भी पेपर किसी journal में प्रकाशित नहीं है और न ही peer-reviewed है. पेपर ऊपर से सुव्यवस्थित दिखता है और AI-generated भी नहीं लगता, लेकिन मैं जानना चाहता हूँ कि ऐसी funding संभव कैसे हुई
सबसे बड़ा वित्तीय समर्थन The Audacious Project से आया था, जिसे official announcement में देखा जा सकता है. साथ ही, website footnote में लिखा है कि अप्रैल 2025 तक AI कंपनियों से evaluation के लिए कोई भुगतान नहीं लिया गया था
कंपनियाँ इस तरह के ‘whitepaper’ अक्सर निकालती हैं — technical report, policy proposal, और promotional material का मिश्रण
मेरे हिसाब से केवल journal और peer review है या नहीं, इसी पर अटकना अर्थहीन है. विज्ञान में असल चीज़ यह नहीं कि किसने publish किया, बल्कि reproducibility और repeated results हैं. जैसा psychology की replication crisis में देखा गया, journal publication अपने-आप reliability की गारंटी नहीं देता
ज़्यादातर देशों में research के लिए public funding होती है; अमेरिका में पहले यह अधिक थी, लेकिन हाल के वर्षों में इसमें भारी कटौती हुई है
foundation overview page को देखकर लगता है कि उन्हें AI कंपनियों, सरकारों और अन्य स्रोतों से funding मिलती है
hobby OSS projects में AI उल्टा बाधा बनता है. code generation/scaffolding मेरी चिंता नहीं है; code review और community management कहीं ज़्यादा महत्वपूर्ण हैं. AI tools क्या कर सकते हैं इसकी सीमाएँ काफ़ी स्पष्ट हैं. फिर भी किसी ने मेरे खुले PR पर AI code review tool लगा दिया, जो 30-line PR पर भी emoji और व्यवस्थित bullet points के साथ 2-page summary उगल देता है. इससे सिर्फ़ बेकार noise पैदा होता है, और अब उन comments को delete या hide करने में ही असली maintenance time और खर्च होता है
learning curve पार कर लेने पर शायद गति बढ़ती है (या जैसा किसी ने कहा, “जब तक आप AI के बिना काम करना ही भूल न जाएँ”), लेकिन असल में जो मापना चाहिए वह है… रात 3 बजे PagerDuty alert बजने पर उस code को debug करने में कितना समय लगता है. और उस code की long-term quality कैसी रहती है? मैं लंबे समय से business logic को shared folders में ऊपर ला रहा हूँ, call chain को ऊपर समेटकर APIs को साफ रख रहा हूँ, logic/API/display separation, encapsulation, dependency injection से coupling कम करना जैसी structural improvements करता आया हूँ. क्या AI-generated code लंबे समय में बेहतर quality/portability/extensibility देगा? या फिर अंततः निम्न-गुणवत्ता वाला code जमा होकर एक उलझा हुआ junkyard बन जाएगा, और आख़िरकार bug fixes पर ही आधा समय खर्च करना पड़ेगा?