सारांश
- अध्ययन का अवलोकन
- इस अध्ययन ने Microsoft, Accenture, और एक गुमनाम Fortune 100 इलेक्ट्रॉनिक्स मैन्युफैक्चरिंग कंपनी में किए गए तीन randomized controlled experiments के माध्यम से सॉफ़्टवेयर डेवलपर्स की उत्पादकता पर generative AI के प्रभाव का मूल्यांकन किया।
- प्रयोग प्रत्येक कंपनी के रोज़मर्रा के काम के हिस्से के रूप में किए गए, और यादृच्छिक रूप से चुने गए डेवलपर्स को GitHub Copilot नामक AI-आधारित coding assistant प्रदान किया गया।
- कुल 4,867 सॉफ़्टवेयर डेवलपर्स पर किए गए इस अध्ययन में पाया गया कि AI टूल का उपयोग करने वाले डेवलपर्स द्वारा पूरे किए गए कार्यों की संख्या 26.08% बढ़ी (standard error: 10.3%)।
- खास तौर पर, कम अनुभवी डेवलपर्स में adoption rate और productivity improvement अधिक देखा गया।
GN⁺ का संक्षेप
- यह अध्ययन दिखाता है कि generative AI सॉफ़्टवेयर डेवलपर्स की उत्पादकता को काफ़ी बढ़ा सकता है।
- यह विशेष रूप से कम अनुभवी डेवलपर्स के लिए उपयोगी है, जो संकेत देता है कि AI टूल learning curve को कम करने में मदद कर सकते हैं।
- GitHub Copilot जैसे AI टूल सॉफ़्टवेयर डेवलपमेंट की efficiency बढ़ाने में महत्वपूर्ण भूमिका निभा सकते हैं।
- समान क्षमताओं वाले अन्य प्रोजेक्ट्स में TabNine और Kite शामिल हैं।
1 टिप्पणियां
Hacker News की राय
कभी-कभी सोचता हूं कि IT workforce की quality इसलिए गिर रही है क्या, क्योंकि कंपनियां headcount घटाने के लिए एक ही व्यक्ति पर लगातार और ज़्यादा roles ठूंस रही हैं
पहले development, operations, security अलग-अलग dedicated roles थे, लेकिन DevOps बनने पर कुछ कंपनियों ने इसे team integration नहीं, बल्कि यह समझा कि अब 2/3 लोगों से काम चल जाएगा; और DevSecOps बनने पर उन्हें लगा कि मूल roles के सिर्फ 1/3 लोग भी काफी हैं, और developer operations व application security भी कर सकता है
मैं shift-left या integrated operations model की आलोचना नहीं कर रहा; कहने का मतलब है कि जब executives सोचते हैं कि headcount घटाकर cost कम करने से उन्हें bonus ज़्यादा मिलेगा, तो ऐसे models का logical परिणाम यही होता है
अब नया developer एक बेवजह जटिल n-microservices environment में आता है, existing codebase, 5 CI/CD pipelines, DBA role तक सीखता है, और साथ-साथ steady release cycle भी निभानी होती है
ऐसे में catch up करने के लिए ChatGPT इस्तेमाल करना वाकई कोई हैरानी की बात है क्या? और जब तक IT कंपनियां अच्छी business strategy की जगह “line ऊपर ले जाने” के लिए headcount घटाना बंद नहीं करतीं, यह चलता रहेगा
मुझे लगता है MBA लोग over-constraint वाली चीज़ मिस कर देते हैं। “developer” जैसे general role को “development, operations, security” में बांट दें, तो हर role को कैसे करना है, इसकी ढेर सारी details बन जाती हैं। फिर उन्हें वापस DevSecOps में जोड़ भी दें, तो वे details बनी रहती हैं; नतीजा यह कि एक व्यक्ति 3 गुना efficient नहीं होता, बल्कि उस पर 3 गुना काम आ जाता है
इसे सही तरीके से उलटना हो तो constraints ढीले करने होंगे, और उस एक व्यक्ति को यह तय करने देना होगा कि काम कैसे करना है
इससे निकला निष्कर्ष यह है कि organizations छोटी नहीं हो सकतीं, सिर्फ बड़ी हो सकती हैं। Employees बढ़ते हैं तो jobs और specialized होती जाती हैं; उन्हें हटाने पर वह function बस किया ही नहीं जाता। उस level की specialization पर बचे हुए employees के लिए job description थोड़ा बदलकर नई जिम्मेदारियां उठाना मुश्किल होता है
अंत में पुरानी organization छोड़कर नई और छोटी organization से फिर शुरुआत करनी पड़ती है; private equity/venture capital/startup ecosystem के मौजूद होने की वजह भी यही है। Gall's law भी इसी संदर्भ में है: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
वहीं आजकल बन रहे नए startups देखें तो सचमुच talented लोगों की संख्या लगातार बढ़ती दिखती है। Funding के ज़्यादा tight माहौल में company शुरू करने के लिए असली skill वाले लोग ज़्यादा जरूरी होते हैं, और ऐसे लोग फिर बेहतरीन लोगों को ही hire करते हैं, ऐसा मुझे लगता है
आज की tech industry मुझे 2004–2008 के दौर जैसी कहीं ज़्यादा लगती है, जब startups में interested लगभग हर कोई इसलिए कूदता था क्योंकि उन्हें technical problems hack करना पसंद था
Cursor इस्तेमाल करने के अनुभव से कहूं तो, यह average engineer जो कर सकता है उसमें शानदार है, लेकिन उससे advanced कामों में बहुत खराब है; और दूसरे लोगों का code बहुत तेज़ी से समझने की क्षमता भी चाहिए
शायद frontend या web app development पर focus न करने वाले advanced technical engineers को junior web developers पहले जितने ज़्यादा hire करने की जरूरत नहीं रहेगी। यह वैसा ही है जैसे webpages के लिए basic HTML/CSS जल्दी बनाने वाले frameworks और tools आने पर webmaster गायब हो गए थे
मान लें “DevSecOps” लोग अपने काम से 3 गुना ज़्यादा काम कर रहे हैं, तो यह भी देखना चाहिए कि वे और क्या कर रहे हैं। Travel booking, expense settlement और reporting, work hours को business categories में बांटकर report करना, leave management, meeting management, खुद बनाए graphics से presentation materials बनाना, और external vendors से खरीदारी की तैयारी का 80% तक—सब कुछ हो सकता है
ये चीज़ें job description में नहीं होतीं, असली काम में बाधा डालती हैं, और core job करने की क्षमता को असंतुलित रूप से खा जाती हैं। पहले ऐसी हर चीज़ के लिए dedicated specialist होता था, जो बहुत कम cost पर 10 गुना efficiency से इसे कर सकता था
Secretaries, internal graphics departments, finance staff जैसे specialists financial statements में दिखते थे। उन roles को खत्म करने से काम गायब नहीं होता; self-service office software द्वारा “productivity” सुधारने के नाम पर वह सबके बीच टुकड़ों में बांट दिया जाता है
नतीजा यह कि हर कोई disproportionate तरीके से slow हो जाता है, लेकिन सिर्फ numbers देखने वाले लोग हटाए गए roles की salaries से हुई savings ही देखते हैं। Slowdown धुंधला और general productivity decline की feeling, सबको लगने वाली किसी रहस्यमयी cost disease जैसा ही दिखता है
मेरे हिसाब से इसमें कोई रहस्य नहीं: productivity gain नहीं है, उल्टा loss है। बस clear और visible cost को distributed और calculate करने में मुश्किल cost में बदल दिया जाता है, इसलिए यह भ्रम पालना आसान हो जाता है कि पैसा बच रहा है
छूटी हुई मुख्य क्षमता है: company जिस business में है, उसे समझने की क्षमता। ठीक-ठाक development ability भी अगर business goals की अच्छी समझ के साथ जुड़ जाए, तो pure developers के एक हिस्से को AI द्वारा replace किए जाने के बीच भी relevant बनी रह सकती है
Banking company में 13 साल में मैंने complexity को बहुत बढ़ते देखा है, और साथ ही बेतुकी bureaucracy भी बढ़ी है। अब भी जरूरी काम कर सकता हूं, लेकिन access नहीं है। मिल भी नहीं सकता
Simple task अब किसी अज्ञात Pune team के साथ 10-step negotiation बन गया है, और जब तक वे यह पहचानें कि सच में उनके पास करने के लिए काम है, तब तक 10 बार follow-up और escalation करनी पड़ती है
Process इतना absurd हो गया है कि कुछ शुरू करें तो पता नहीं 2 दिन लगेंगे या 3 महीने। हर app, नए network काम, unverified Unix update, या उन ढेरों चीज़ों में से किसी एक की वजह से—जो होना तय है—लगातार maintain न की जाए तो काफी जल्दी टूट जाती है
अंत में paperwork handlers और अपने मूल काम में भी average लोग process में गहराई से जम गए और जीत गए; business units को low-quality IT मिलती है, projects delay होते हैं और budget भी exceed होता है। इससे IT की “बेकार है, लेकिन झेलनी पड़ने वाली बुराई” वाली image और मजबूत होती है
अब मैंने परवाह करना छोड़ दिया है; काम बस जीवन चलाने का जरिया हो तो काफी है। मेरा focus और achievement उस “life” वाली तरफ है
क्या मापा जा रहा है, यह अहम है। इस अध्ययन ने सिर्फ Copilot usage को देखा
मैं एक अनुभवी engineer हूँ, और Copilot मेरे लिए बेकार ही नहीं, बाधा भी है। मेरा ज़्यादातर समय problem domain को समझने, जिस environment में मैं हूँ उसकी constraints और possibilities को समझने, और लिखे जाने वाले code के बारे में सोचने में जाता है
जब मैं सच में code टाइप करना शुरू करता हूँ, तब मुझे पहले से पता होता है कि क्या लिखना है, इसलिए “मदद” करने वाला Copilot autocomplete बस ध्यान भटकाता है। यह मेरे workflow को कहीं ज़्यादा खराब कर देता है
इसके उलट, actual coding से पहले के stages में AI बेहद उपयोगी है। कभी-कभी पहले से की गई सोच के आधार पर सिर्फ एक अच्छे prompt से draft मिल जाता है, और उसके बाद आने वाली छोटी unexpected समस्याओं के तेज़ जवाब पाने के लिए LLM के साथ pair करना बहुत मददगार होता है
इसलिए इस report के उलट, मुझे लगता है कि अगर skilled developer AI का अच्छे से इस्तेमाल करे, तो उसे inexperienced developer से ज़्यादा बड़ा फायदा भी मिल सकता है
लेकिन Claude Sonnet 3.5 को Cursor या Continue.dev के साथ इस्तेमाल करने पर स्थिति नाटकीय रूप से बेहतर हो जाती है। context को explicitly control किया जा सकता है, जैसे 6–7 files select करके inject कर सकते हैं, और Claude की बेहतर capability जुड़ जाए तो game पूरी तरह बदल जाता है
task के हिसाब से आसानी से 2–5 गुना तेज़ी आ जाती है। जो काम मूल रूप से आधा दिन ले सकता था, उसे एक घंटे के अंदर tests सहित 100-line production-ready code में बदला जा सकता है
यह मैं 26 साल के experience और 2012 से principal/staff/lead roles में रहने के आधार पर कह रहा हूँ। हालांकि senior से कम experience में मैं वही improvement expect नहीं करता। क्योंकि आपको असल में जो चाहिए उसे काफी detail में समझाना पड़ता है, और आमतौर पर working initial solution लेकर उसे करीब छह बार refine करके ideal और अच्छी तरह decomposed form में लाना पड़ता है
उदाहरण के लिए AWS के लिए IaC लिखते समय बहुत कुछ look up करना पड़ता है। AI से पूछने पर जवाब और examples बहुत जल्दी मिल जाते हैं। अगर मैं किसी नई service का IaC सीख रहा हूँ तो AWS docs देखूँगा, लेकिन जब सिर्फ quick answer या refresher चाहिए, तो AI कहीं तेज़ है
जितना आप functional patterns पर निर्भर होते हैं, monads design करते हैं, input/output सिर्फ boundary पर करते हैं और fluent programming इस्तेमाल करते हैं, impact उतना ही बड़ा होता है
reference के लिए, यह Java में मेरा experience है। मैं 3.5 साल से Java इस्तेमाल कर रहा हूँ और Java 8+ features पर काफी निर्भर हूँ। library code में generics का ज्यादा इस्तेमाल करने से LLM के पास consistently सही choice करने की गुंजाइश बढ़ जाती है
तेज़ और roughly बने design में यह फायदा उतना नहीं दिखता। Haskell, OCaml, F#, Scala जैसे सच में functional programming users की बातें और सुनना चाहूँगा
unit tests, खासकर table-driven tests के boilerplate लिखने में यह काम आया, लेकिन paid subscription बनाए रखने लायक नहीं था
अपरिचित language में काम करते समय, या ऐसे repetitive tasks में जहाँ generated code ठीक है या नहीं यह आसानी से judge किया जा सके, यह बहुत valuable था
इसके उलट जब मुझे जो करना है वह बहुत clear हो और standard implementation जैसा हो लेकिन थोड़ा नया हो, तब यह weak पड़ जाता है। “reduce” या ज्यादा ambiguous procedures में ऐसा अक्सर होता है
platform engineer होने के नाते मैं Bash, Python, browser, pure JS, TS, Node, GitHub Actions, Jenkins Java workflows, Docker आदि कई spaces के बीच switch करता हूँ, और domain switch करते समय दिमाग को आराम देने और warm up करने में यह मदद करता है
सोच रहा/रही हूँ कि क्या इस अध्ययन में वह technical debt शामिल था जिसे कम अनुभवी developers द्वारा AI से contribute करने के बाद अधिक अनुभवी developers को संभालना पड़ा। क्योंकि अध्ययन में शामिल कंपनियों में से एक में मैंने व्यक्तिगत रूप से ऐसी चीज़ें बहुत देखी हैं
यह भी खुद देखा है कि जिन developers की तकनीक में कम दिलचस्पी है लेकिन delivery में बहुत दिलचस्पी है, वे AI में ज़्यादा रुचि दिखाते हैं। PMs ऐसे लोगों को पसंद करते हैं, लेकिन
हमने लगभग 5 lines का छोटा change और tests माँगे थे। लेकिन अब हमारे सिर पर सिर्फ नया debt ही नहीं, बल्कि ऐसा code भी आ गया जिसे कोई नहीं समझा सकता कि वह पूरी तरह क्यों बदल गया, उसमें से कुछ code सिर्फ बदलने के लिए बदला गया था, और ऐसा code भी जो इसे maintain करने वालों को बिल्कुल अपरिचित लगता है
जो लोग senior engineers नहीं हैं और ऐसे tools इस्तेमाल करते हैं, उनमें मैं यह बार-बार देख रहा/रही हूँ। अंत में ऐसे PR को reject करके दोबारा करने को कहना पड़ा, और शुरुआत में जो time gain लगा था वह खत्म हो गया
इसका मतलब यह नहीं कि ये tools बेकार हैं, लेकिन लोग output क्या है यह समझे बिना उनका इस्तेमाल कर रहे हैं, और codebase पर long-term impact भी नहीं समझ रहे
जिस दिन मेरी आत्मा का एक हिस्सा मर गया, वह तब था जब मैंने एक developer से पूछा कि क्या मैं DB schema पर feedback दे सकता/सकती हूँ, उसने हाँ कहा, और कुछ मिनट बाद “हाँ, मुझे X में ज़्यादा दिलचस्पी नहीं है” कहकर बात काट दी
दिलचस्पी नहीं है? मैं domain expert के तौर पर बता रहा/रही हूँ कि क्या सुधारा जा सकता है, कैसे और क्यों करना चाहिए, और तुम्हें दिलचस्पी नहीं है
cloud एक गलती थी। इसने लोगों में यह सोच डाल दी कि जब कभी भी scale up/out किया जा सकता है, तो efficiency और optimization के पीछे जाने की ज़रूरत नहीं। मैं microbenchmarks की बात भी नहीं कर रहा/रही, बल्कि “इस data structure की जगह वह data structure इस्तेमाल करना बेहतर नहीं होगा?” जैसी बहुत basic बात कर रहा/रही हूँ
हम इसे internally भी इस्तेमाल करते हैं, और मुझे लगता है कि technical debt एक बहुत बड़ा खतरा है जिसका सही अंदाज़ा नहीं लगाया गया है
अपरिचित APIs और patterns को code में carpet-bomb करने की तरह लागू करने में यह बहुत उपयोगी है, लेकिन सावधान न रहें तो यह भारी code duplication और संभालने में मुश्किल boilerplate पैदा करता है
इसकी वजह दो बड़े biases हैं। पहला, model का training data StackOverflow-style example data है, इसलिए वह context और constraints को ध्यान में नहीं रखता। दूसरा, मौजूदा codebase देखकर refactoring सुझाने के बजाय वह copy और repeat करने की ओर झुकता है
पहला अंततः अपना काम करके, यानी LLM ने जो उगला है उसे review और edit करके कम किया जा सकता है
दूसरा तभी कम हो सकता है जब diffs और commit history training data में आएँ, लेकिन यह dataset संभालना और tag करना कहीं ज़्यादा कठिन है। कुछ changes refactoring की तरह अच्छे होते हैं, लेकिन कुछ ऐसे bugs हो सकते हैं जिन्हें बाद के commits में fix किया जाता है, और commit messages असल में झूठ ही होते हैं, इसलिए साफ़ distinction भी नहीं होता। कोई “bug introduced” नहीं लिखता
इसके अलावा merge, rebase, squash history के meaning को बदल देते हैं, हटा देते हैं या noise जोड़ देते हैं, जिससे सब कुछ और धुंधला हो जाता है
मुझे technology पसंद है और मैं मज़े के लिए software भी लिखता/लिखती हूँ, लेकिन AI के साथ काम करना objectively ज़्यादा मज़ेदार है। productivity बहुत ज़्यादा बढ़ जाती है, और सबसे बढ़कर procrastination खत्म हो जाती है
जब मैं अटक जाता/जाती हूँ या काम शुरू करने का मन नहीं होता, तो Aider से बात शुरू करता/करती हूँ और देखते-देखते उस दिन का कोई ऐसा task पूरा हो जाता है जो AI के बिना नहीं किया होता
इसकी वजह से जो public/private projects पहले months से years लगाते थे, अब हर 2 हफ्ते में निकाल देता/देती हूँ। एक तेज़ और अनुभवी developer team के बगल में बैठे होने की cost दिन में अधिकतम कुछ dollars है
निष्कर्ष पर पहुँचने से पहले पेपर को थोड़ा और गहराई से देखने की ज़रूरत है। लगता है कि अध्ययन खुद भी परिणामों का सारांश बेहतर तरीके से दे सकता था
abstract और conclusion में परिणाम के तौर पर सिर्फ़ एक अनुपात दिया गया है: उत्पादकता में 26.08% वृद्धि, लेकिन दशमलव के अंक कुछ ज़्यादा ही लगते हैं। थोड़ा और अंदर जाने पर junior के लिए 27~39% और senior के लिए 8~13% के आँकड़े दिखते हैं
और गहराई से देखें तो अंतर सिर्फ़ अनुभव के आधार पर नहीं, कंपनी के हिसाब से भी काफ़ी बड़ा है। Microsoft में pull request के अलावा commit, build, build success rate जैसे दूसरे outcome metrics सांख्यिकीय रूप से significant नहीं लगते। PR में वृद्धि Microsoft में significant लगती है, लेकिन Accenture में नहीं लगती, और वह भी शायद सिर्फ़ junior के लिए हो सकती है
abstract और conclusion को संक्षेप करना होता है, लेकिन variables के हिसाब से परिणाम इतने बदल रहे हैं कि एक single overall number को summary के रूप में देना कितना उचित है, समझ नहीं आता। ख़ासकर इसलिए क्योंकि statistical significance काफ़ी असंगत दिखती है
Accenture ऐसी कंपनी है जो Microsoft जैसे बड़े संगठनों के साथ सहयोग और co-marketing करती है। लगभग 300 developers का pool पूरे sample को लगभग हिला नहीं पाता, और वह AI workflow के आसपास marketing/consulting विभाग बना रही है, इसलिए उसे objective मानना भी मुश्किल है
तीसरी anonymous कंपनी में असल में randomized controlled trial नहीं था, इसलिए उसके परिणामों को RCTs के साथ कैसे जोड़ा जाए, कहना मुश्किल है। साथ ही, बड़ी tech कंपनियों में और भी ऐसी कंपनियाँ रही होंगी जिन्होंने similar experiments किए होंगे और efficacy जानना चाहा होगा, इसलिए यह मान सकते हैं कि शामिल परिणामों के अलावा भी data मौजूद है
बड़े sample set में से इन्हीं कंपनियों को क्यों चुना गया? शायद इसलिए कि Microsoft और Accenture के पास adoption का incentive है, और तीसरी कंपनी को p-hacking के चलते चुना गया होगा
ख़ासकर abstract का वाक्य “हर individual experiment noisy है, लेकिन तीनों experiments को मिलाने पर” बहुत बुरा संकेत है। यह фактически स्वीकार करना है कि हर कंपनी को अलग-अलग देखें तो statistically significant result नहीं है, लेकिन इन तीन groups को मिला दें तो significant हो जाता है। यह science नहीं है
junior developers शायद ऐसे काम करते हैं जिन्हें LLM के लिए सही करना आसान होता है, या पहली draft LGTM जैसी दिखती है इसलिए उसे accept करने की गलती करते हैं, जिससे throughput ज़्यादा दिख सकता है
generated code model इस्तेमाल करने के लिए भी skill चाहिए, और वह skill वही है जो दूसरों को काम delegate करने और कई authors के solutions को एक cohesive system में integrate करने के लिए चाहिए होती है
यह सिर्फ़ मेरी intuition है, लेकिन मुझे लगता है कि LLM-assisted coding developer के रूप में बढ़ने के लिए हानिकारक है। यह productivity को सिर्फ़ एक निश्चित स्तर तक ही बढ़ा सकती है, और वह स्तर senior के लिए boring repetition हो सकता है, लेकिन junior के लिए formative process होता है
मेरे अनुभव में LLM का उपयोग सिर्फ़ simple boilerplate code के लिए नहीं होता, बल्कि तब बुलाया जाता है जब junior developer किसी काफ़ी common task से सामना करता है जिसे वह अभी पर्याप्त रूप से समझता नहीं। experiment करने, सीखने और समझने की प्रक्रिया काफी हद तक LLM से replace हो जाती है, और असली skill तब तक prompt tweak करना बन जाती है जब तक चीज़ काम करती हुई न दिखे
कल रात मैंने पहली बार Linux RAID setup किया। यह बहुत मुश्किल काम नहीं है, लेकिन mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs आदि कई tools चाहिए होते हैं और बीच में guide के exact steps से अलग दिशा में चीज़ें जा सकती हैं, इसलिए सिर्फ़ tutorial या documentation देखना विशेष रूप से मददगार नहीं होता
मैंने हर tool और step के बारे में दर्जनों सवाल पूछे, जबकि पहले होता तो बस copy-paste करके दुआ करता
दो दिन पहले मैंने खराब SSD से सारा data recover करना भी ChatGPT के जरिए सीखते हुए किया। भले ही 20% गलत हो सकता है, लेकिन खुले internet के average से कहीं बेहतर “guide” के साथ बिल्कुल नई skill पर काम करना सचमुच अच्छा लगा
जिसे सीखना पसंद है, उसके लिए यह internet के कचरे को अंतहीन खंगालने की तुलना में सात लीग वाले जूते जैसा लगता है। बेशक internet की बाकी हर चीज़ की तरह AI की बातों पर भी शक करना चाहिए, लेकिन यह झंझट को बेहद कम कर देता है
मेरी भी यही intuition है, और मैं इसे आगे बढ़ाकर evidence-based strong opinion कहना चाहूँगा। मुझे लगता है कुछ सालों बाद industry इसकी कीमत चुकाएगी
“अच्छी समझ वाले junior software developers” की supply pipeline काफ़ी सूख जाएगी और उसकी जगह “AI-dependent junior software developers” की बाढ़ आ जाएगी। इन दोनों categories के बीच गहरी खाई है
स्वाभाविक रूप से इसका cascading effect अच्छी समझ वाले mid-level developers और अच्छी समझ वाले senior developers की संख्या पर भी पड़ेगा
वहीं जो लोग अपने लिखे code को पूरी तरह समझना चाहते हैं, वे LLM ने जो निकाला है उसमें अनजान हिस्सों की जाँच करने की संभावना रखते हैं
कम से कम मैं तो इसे ऐसे ही इस्तेमाल करता हूँ। और इस hypothesis के counterexample के तौर पर, कई बार LLM ऐसी functions या library components इस्तेमाल करता है जिन्हें मैं नहीं जानता था, इसलिए नई language या toolkit सीखते समय यह मेरा काफी समय बचाता है। मेरे लिए यह learning को धीमा करने के बजाय accelerate करता है
लेकिन जो लोग वैसे भी सफल होने वाले हैं, उनके लिए यह StackOverflow question पूछकर तुरंत, बिना blame वाला answer पाने जैसा है, इसलिए सचमुच बड़ा gift है
यह हमेशा सही नहीं होगा, लेकिन StackOverflow भी ऐसा ही था। आखिरकार, हमेशा की तरह यह व्यक्ति पर निर्भर करता है
50 साल पहले कुछ बनाने के लिए machine language लगभग अनिवार्य थी; आज के developers में से कितने उसे लिखना जानते हैं
शायद LLM एक और abstraction crutch से बदलकर एक मजबूत abstraction pillar बन रहा है
इस अध्ययन में सबसे दिलचस्प बात यह है कि करियर स्तर के हिसाब से बांटने पर, जिन डेवलपर्स का tenure median से ज्यादा है, उनमें “productivity” जैसे खराब proxy metric में statistically significant बढ़ोतरी नहीं दिखती। 95% confidence interval सभी metrics में negative तरफ काफी नीचे तक जाता है, बस थोड़ा positive तरफ झुका हुआ है
यह मेरे अनुभव से भी मेल खाता है। Copilot कुछ उबाऊ काम घटाने और दिमाग को गहरे सवालों पर लगाने में अच्छा है, लेकिन जैसा junior developers कहते हैं, वैसा दुनिया बदल देने वाला नहीं है
यह अक्सर सूक्ष्म रूप से गलत भी होता है, ऐसे तरीकों से जिन्हें कम अनुभवी developer miss कर सकता है। मुझे generate किए गए ज्यादातर हिस्सों को रोककर adjust करना पड़ता है, और कम skilled developer को शायद पता न हो कि वे adjustments कैसे करने हैं
कुछ साल इस्तेमाल करने के बाद अब मुझे काफी अंदाजा हो गया है कि Copilot कब इस्तेमाल करना है और कब नहीं, इसलिए net effect शायद positive है, लेकिन हमेशा ऐसा नहीं था
यह भी सोचता हूं कि senior developer की “productivity” घटती दिखने की कुछ वजह कंपनी के juniors की productivity बढ़ना तो नहीं है। अगर juniors ज्यादा PR बनाते हैं और उनमें ज्यादा गलतियां होती हैं, जिससे review time बढ़ता है, तो senior की productivity gain उसी अनुपात में घट सकती है
26% productivity increase मेरे अनुभव से भी मोटे तौर पर मेल खाता है। मेरे हिसाब से एक और dimension देखने लायक है: क्या आप नई technology पर काम कर रहे हैं या पहले से परिचित technology पर। AI उस language या framework में कहीं ज्यादा मददगार है जिसे मैं सीखने की कोशिश कर रहा हूं
Bash में conditional लिखने के लिए exactly कौन-सा quotes spell चाहिए, जैसी auxiliary languages की अजीबियतें और traps मुझे ठीक से याद नहीं रहते। इसलिए पहले automation के लिए Bash scripts बहुत कम लिखता था, और सिर्फ उन tasks के लिए मेहनत करता था जो काफी बार करने पड़ते थे। jq से JSON process करना या AWK से parsing करना भी ऐसा ही था
अब LLM की वजह से मैं बहुत ज्यादा Bash scripts बनाता हूं, और यह इतना आसान हो गया है कि process documentation में भी उन्हें ज्यादा इस्तेमाल करता हूं। पहले जो static step-by-step README होता था, अब वह user input लेने वाली interactive Bash script के साथ आता है
आम तौर पर मैंने senior programmers को बहुत देखा है कि वे क्यों AI tools काम नहीं करते, इस पर चर्चा करते हैं। Juniors बिना bias के बस इस्तेमाल कर लेते हैं
जहां उपयोगी था वे चार जगहें थीं। पहली, Qt या CSS जैसे frameworks/languages पर सवाल, जिन्हें मैं अक्सर इस्तेमाल नहीं करता लेकिन जिनके example content बहुत हैं
दूसरी, बहुत specific सवाल जिन्हें पहले मैं Google Search या StackOverflow पर ढूंढता। जैसे “Python से Windows का CPU और RAM usage सबसे efficient तरीके से कैसे get करें” जैसे सवाल में यह copy-paste करने लायक code तुरंत बनाने के बजाय libraries या examples की ओर इशारा करता है
तीसरी, boilerplate code जिसे मैं लिखना जानता हूं, लेकिन इससे थोड़ा time बचता है और typing errors घटते हैं। PyCharm के लिए CoPilot plugin इस्तेमाल करते हुए अगर file में comments में intent लिखूं तो यह अगली कुछ lines complete कर देता है। फिर भी result तब सबसे अच्छा होता है जब यह बहुत छोटा और specific हो। लंबा होने पर CoPilot के साथ बहुत ज्यादा iterate करना पड़ता है, तो value नहीं रहती
चौथी, documentation को quickly search करने का तरीका
कुछ लोग कहते हैं कि यह unit tests लिखने के लिए अच्छा है, लेकिन मेरे लिए ऐसा नहीं था। कम से कम उस तरह के unit tests के लिए नहीं जो मैं चाहता हूं
अगर quantify करूं तो productivity 5–10% बढ़ती है। यह Notepad की जगह PyCharm जैसे full IDE का इस्तेमाल करने, या CLI में git commands सीधे टाइप करने के बजाय अच्छा git client इस्तेमाल करने से मिलने वाले लाभ से बहुत कम है। यानी यह कई productivity tools में से एक है, “revolutionary” नहीं कहूंगा
एक बड़े Ruby on Rails project में मैंने करीब 10 दिन Cursor इस्तेमाल किया, और यह stack मैं 13 साल से ज्यादा समय से इस्तेमाल कर रहा हूं
GitHub Copilot पहले से जो productivity gain दे रहा था, उससे ज्यादा कुछ नहीं मिला। Copilot का gain मैं लगभग 25% मानता हूं
लेकिन empty folder से Node.js जैसा नया project पहली बार बनाना अजीब तरह से powerful है। सिर्फ prompt से OpenAPI schema से requests handle करने और swagger के जरिए OpenAPI schema serve करने वाला API लगभग 5 मिनट में बना सकते हैं
हालांकि नए project को scratch से शुरू करना मेरे लिए rare है, इसलिए शायद मैं Copilot और basic VSCode पर वापस जाऊंगा
यह लोगों को ज्यादा PR बनाने देता है। वाह, कमाल है। किसे फर्क पड़ता है
क्या QA pass करने वाले items की संख्या बढ़ती है? AI assistance से बनी चीजों में QA के बाद मिलने वाले bugs कम होते हैं? क्या उन्हें बाद में extend या modify करना आसान है, या design rigid और inflexible है?
Developers को quality unknown वाले code monkeys में बदलने वाला tool मैं नहीं ढूंढ रहा। मुझे ऐसा tool चाहिए जो developer को अपने काम के bugs या design flaws खोजने में मदद करे, या अच्छी तरह designed tests लिखने में मदद करे
सिर्फ PR count करना कोई उपयोगी बात नहीं बताता। उल्टा, per unit time code ज्यादा होने पर average quality घटती है, इस मेरी instinct को यह trigger करता है
Copilot: “ठीक है, कर देता हूं! ये रहे नए commits!”
Senior developer: “क्यों? change atomic है। अगर management monthly change count जैसे बेवकूफ metrics फिर से निकालेगा, तो मैं politely उन्हें दफा होने को कह दूंगा”
यह शायद GPT-3.5-based Copilot रहा होगा
Microsoft: सितंबर 2022~3 मई 2023
Accenture: जुलाई 2023~दिसंबर 2023
Anonymous company: अक्टूबर 2023~?
Copilot Chat का GPT-4 update 30 नवंबर 2023 को था: https://github.blog/changelog/label/copilot/
मेरे लिए AI ने documentation को फिर से ज़िंदा कर दिया। नए frameworks में documentation बहुत कम होती है। आख़िरी बार मुझे अच्छी documentation DOS की किताबों में मिली थी। आजकल के developers को शायद अंदाज़ा भी नहीं होगा कि अच्छी documentation कैसी होती है
फिर भी AI हर बार अलग सुझाव दे सकता है, इसलिए फैसला अब भी अनुभवी developer को ही करना होता है। आखिरकार AI documentation और typing की जगह लेता है
अगर project public है, तो documentation LLM के training data का हिस्सा बन चुकी है, इसलिए documentation का thorough और accurate होना कहीं ज़्यादा महत्वपूर्ण हो गया है। क्योंकि बहुत सारे developers उसी system से जवाब लेंगे
अगर project private है, तो documentation को fine-tuning dataset या RAG system में डालकर वही असर हासिल किया जा सकता है
यह भी समझा सकता है कि कुछ भी document क्यों नहीं किया जाता
इसलिए असल में इसका असर developers को code को बेहतर document करने के लिए मजबूर करने जैसा भी होता है
ज़रूरी नहीं कि वह modern live documentation ही हो; कुछ भी चलेगा। मैं देखना चाहता/चाहती हूँ कि अतीत में ऐसा क्या बेहतरीन था जिसे हमने खो दिया, और उसके कुछ हिस्से अपनी documentation में शामिल करके देखना चाहता/चाहती हूँ