नए GitHub Copilot शोध में ‘कोड क्वालिटी पर नीचे की ओर दबाव’ पाया गया

 (visualstudiomagazine.com)
1 पॉइंट द्वारा GN⁺ 2024-01-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitClear के Coding on Copilot श्वेतपत्र ने कोड बदलाव डेटा के आधार पर यह विश्लेषण किया कि AI-सहायता प्राप्त कोड उत्पादकता बढ़ाने के बदले क्वालिटी और maintainability पर बोझ डाल सकता है या नहीं
  • लिखे जाने के 2 हफ्तों के भीतर वापस लिया गया या संशोधित किया गया code churn 2021 के AI-पूर्व baseline की तुलना में 2024 में दोगुना होने का अनुमान है
  • Copilot के प्रसार के बाद added code और copy/pasted code का अनुपात बढ़ा, जबकि moved code में कमी refactoring और reuse के कमजोर होने का संकेत देती है
  • GitHub के 2022 के शोध में पाया गया था कि Copilot उपयोगकर्ताओं ने काम 55% तेजी से पूरा किया, लेकिन GitClear ने उत्पादकता से अधिक लंबी अवधि की maintainability लागत पर ध्यान केंद्रित किया
  • जनवरी 2020 से दिसंबर 2023 तक लिखी गई 153 million lines के बदले गए कोड का विश्लेषण दिखाता है कि तकनीकी नेताओं को AI अपनाने के प्रभाव का आकलन code quality metrics के आधार पर करना चाहिए

GitClear श्वेतपत्र के अनुसार AI-सहायता प्राप्त कोड की प्रकृति

  • Coding on Copilot श्वेतपत्र ने जांचा कि AI-सहायता प्राप्त कोड, मनुष्यों द्वारा लिखे जाने वाले कोड की तुलना में, quality और maintainability के संदर्भ में किस तरह अलग है
  • मुख्य प्रश्न यह है कि AI-सहायता प्राप्त कोड क्या सावधानी से निखारे गए वरिष्ठ डेवलपर के योगदान के करीब है, या अल्पकालिक कॉन्ट्रैक्टर के खंडित काम के ज्यादा समान है
  • GitClear एक कंपनी है जो cloud-आधारित code review tool बेचती है, और यह शोध AI उपयोग के बाद code changes की संरचना कैसे बदलती है, इस पर केंद्रित है

Maintainability में दिखे नकारात्मक संकेत

  • GitClear ने maintainability के संदर्भ में चिंताजनक रुझान पाए
  • code churn उन code lines का अनुपात है जिन्हें लिखे जाने के 2 हफ्तों के भीतर वापस लिया जाता है या अपडेट किया जाता है
    • 2021 के AI-पूर्व baseline की तुलना में 2024 में यह अनुपात दोगुना होने का अनुमान है
  • added code और copy/pasted code का अनुपात modified, deleted, और moved code की तुलना में बढ़ा
  • इन बदलावों के कारण AI-जनित कोड को ऐसे घुमंतू योगदानकर्ता जैसा माना गया, जो जिस repository में जाता है वहाँ DRY सिद्धांत का उल्लंघन करने की अधिक संभावना रखता है

Copilot के प्रसार से जुड़े तीन बदलाव

  • GitClear ने Copilot अपनाने के बाद churn, moved code, और copy/pasted code को महत्वपूर्ण बदलावों के रूप में पहचाना

  • बढ़ता churn

    • उनका मानना है कि “Copilot उपयोग” का repository में गलत कोड push होने से मजबूत संबंध है
    • यह उस प्रवृत्ति से जुड़ा है जिसमें AI-सहायता प्राप्त कोड तेजी से जोड़ा जाता है और फिर थोड़े समय में वापस लिया या संशोधित कर दिया जाता है

  • घटता moved code

    • moved code में कमी refactoring और reuse में कमी का संकेत देती है
    • copy/pasted code में वृद्धि के साथ देखने पर, इसका अर्थ यह निकाला गया कि मौजूदा AI assistant implementations code reuse को पर्याप्त रूप से प्रोत्साहित नहीं करते
    • refactoring के जरिए DRY code बनाने के बजाय, वे एक keypress में मौजूदा कोड को दोहराने का प्रलोभन देते हैं

  • बढ़ता copy/pasted code

    • copy/pasted code को दीर्घकालिक maintainability पर बड़ा बोझ डालने वाला तत्व माना गया
    • जब keywords नहीं बल्कि code lines दोहराई जाती हैं, तो इसे इस संकेत के रूप में देखा गया कि पहले के implementation का मूल्यांकन करने का समय नहीं था
    • यदि कोड को reuse करने के बजाय फिर से जोड़ा जाता है, तो बाद के maintainers को दोहराए गए functions को लागू करने वाले parallel code paths को एकीकृत करना पड़ता है

उत्पादकता शोध से तुलना

  • GitHub के 2022 के शोध में पाया गया कि Copilot का उपयोग करने वाले डेवलपर्स ने इसका उपयोग न करने वालों की तुलना में काम 55% तेजी से पूरा किया
  • उसी शोध ने उत्पादकता के अलावा developer satisfaction और मानसिक ऊर्जा बचत में भी सकारात्मक प्रभाव मापे
  • GitClear श्वेतपत्र ने इन उत्पादकता परिणामों से अलग, AI उपयोग के दौरान code change composition और maintainability में बदलावों पर केंद्रित विश्लेषण किया

संबंधित शोधों में दिखे मिश्रित निष्कर्ष

विश्लेषण का दायरा और बचे हुए प्रश्न

  • GitClear ने जनवरी 2020 से दिसंबर 2023 तक लिखी गई 153 million lines की बदली गई code lines को एकत्रित कर उनका विश्लेषण किया
  • इसके साथ यह निष्कर्ष भी रखा गया कि AI की लोकप्रियता तेज़ी से बढ़ने के कारण हम ऐसे युग में प्रवेश कर चुके हैं जहाँ code lines पहले से कहीं अधिक तेजी से जोड़ी जा रही हैं
  • 2024 का सवाल Copilot डेवलपर के अर्थ को कैसे बदलेगा, इससे कम और बाद में पैदा होने वाले cleanup work को कौन संभालेगा, इससे अधिक जुड़ा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-29
Hacker News की राय

  • 2 महीने इस्तेमाल करने के बाद मैंने subscription बंद कर दिया। लगातार निकलते कोड कचरे की गलतियाँ सुधारने की मानसिक लागत बहुत ज़्यादा थी, और मामूली न होने वाले कामों या SQL से जुड़े कामों में तो पूरा schema पहले दे देने पर भी यह लगभग बेकार था
    मुझे पता है कि मैं क्या लिखना चाहता हूँ, इसलिए खुद लिखना कहीं कम थकाऊ था, और bot की गलतियों से ज़्यादा मेरी अपनी गलतियाँ ठीक करना आसान था। मुझे उन junior लोगों की चिंता है जो इस कचरे के नीचे दब जाएंगे

    • अगर यह बात सही है, तो अच्छा है कि इसका मतलब अभी भी मेरी कुछ आर्थिक उपयोगिता है
      मैं Copilot की जगह ChatGPT इस्तेमाल करता हूँ, और यह देखकर हैरानी होती है कि यह कितना कुछ कर सकता है, लेकिन फिर भी इसे “अच्छा code” कहना मुश्किल है। मैं JavaScript पढ़ तो सकता हूँ, लेकिन पिछले 14 साल iOS में विशेषज्ञता रखने की वजह से browser side best practices अच्छी तरह नहीं जानता, इसलिए इसका इस्तेमाल करता हूँ; और जो code ज़्यादातर चल भी जाता है, उसमें भी खराब फैसले या अजीब बातें दिख जाती हैं
      मुझे लगता है कि अभी AI के बारे में “सब खत्म हो चुका है” या “यह कुछ भी नहीं है” जैसे दोनों चरमों से बचना सही रवैया है। दूसरे वाले लोगों के लिए शायद ऐसी उपमा चाहिए: “एक कुत्ता juggling कर रहा है, tax return भर रहा है और cake बेक कर रहा है, और आप इस बात पर चकित होने के बजाय शिकायत कर रहे हैं कि उसने गेंद गिरा दी, नंबर गलत लिख दिए और recipe खास नहीं थी”
    • ज़िंदगी की ज्यादातर चीज़ों की तरह यहाँ भी संयम ही कुंजी है
      Copilot सबसे उपयोगी तब है जब आप अनुमानित context पर आधारित code लिख रहे हों और यह typing कम करने वाला autocomplete tool बन जाए। एक window में enum class लिखते समय यह दूसरी window के usage को context के रूप में लेकर autocomplete कर सकता है, और unit test के एक सेट लिखते समय सिर्फ Tab एक बार दबाने पर अगला test case का skeleton बना देता है
      खासकर dynamic languages में Copilot, IntelliSense को काफ़ी अच्छी तरह पूरक करता है
    • असली खतरा वह क्षण है जब ऐसे tool सिर्फ आर्थिक कारणों से कहीं बेहतर चीज़ की जगह लेने लायक “काफ़ी अच्छे” हो जाएँ
      कुछ महीने पहले मैंने voice acting industry के text-to-speech models से दबने की लगभग तय दिशा पर typesetting, bookbinding और music engraving के उदाहरणों के साथ लिखा था: https://news.ycombinator.com/item?id=38491203
      लेकिन अगर development खुद ही इस तरह खाली हो जाए, तो अंतिम स्थिति क्या होगी यह समझना मुश्किल है। क्योंकि अतीत के इन replacements को आगे बढ़ाने वाले भी developers ही थे। किसी तरह का सामाजिक पतन और विघटन भी पूरी तरह असंभव नहीं लगता
    • मेरा अनुभव बिल्कुल उलटा है। Copilot ने खासकर साधारण SQL queries जैसे झंझट वाले और उबाऊ कामों को लगभग पूरी तरह बदल दिया है
      “इस JSON को parse करके उसके field database में सही जगह डाल दो” Copilot से SQL लिखवाने का शानदार use case है। ORM plugin या middleware भी इस्तेमाल किए जा सकते हैं, लेकिन MVP या mockup में वह पहले से की गई अनावश्यक optimization है
    • जब मैंने Codepilot जैसे tool इस्तेमाल किए, तो वे खास प्रभावशाली नहीं लगे। मैंने सोचा था शायद इसलिए कि मैंने उन्हें सही तरह इस्तेमाल करना सीखने में समय नहीं दिया, लेकिन हो सकता है वे बस उतने अच्छे ही न हों
      दूसरी ओर, ChatGPT API मैं अक्सर इस्तेमाल करता हूँ और यह काफ़ी सुविधाजनक है। जब मैंने लाखों rows को छूने वाला SQL update लिखा, तो मैंने उससे कहा कि इसे batches में बाँट दे और हर batch के बाद status log print करे; और जब Azure DevOps के nuget feed access में 401 आ रहा था, तब उसने सिर्फ कारण ही नहीं बल्कि उसे ठीक करने वाला yaml भी दे दिया
      ये दोनों काम थोड़ा खोजने पर मैं खुद भी कर सकता था, लेकिन वह खोजबीन का समय बच जाना वाकई बहुत अच्छा है

  • GPT-4 की वजह से मेरी काम की efficiency बहुत बढ़ गई है। मैं मुख्य रूप से रोज़मर्रा के काम की समस्याएँ हल करने वाले साधारण PHP CRUD app बनाता हूँ, और framework या MVC structure इस्तेमाल नहीं करता, इसलिए स्पष्ट निर्देशों पर आधारित GPT-4 द्वारा बनाया गया code समझना आसान होता है और आमतौर पर सीधे काम भी करता है
    आमतौर पर मैं उससे लगभग 25 lines के code snippet में बदलाव करके किसी खास reporting feature के हिसाब से ढालने को कहता हूँ; जैसे इस page पर X के आधार पर group करो और Y का sum निकालो, तो वह ठीक वैसा ही करता है। तेज QA और testing के बाद काम पूरा हो जाता है, और कम complexity तथा साफ निर्देशों वाले कामों में इसका असर खेल बदल देने जैसा है
    यह प्रक्रिया कुछ-कुछ वैसी है जैसे कोई senior programmer काम को basic components में बाँटकर junior को सौंपता है। यहाँ GPT-4 महीने के 20 डॉलर वाले junior programmer की भूमिका निभाता है, और क्योंकि यह मेरा समय बचाता है, मैं खुशी से इसके लिए अपनी जेब से भुगतान करता हूँ
    लेकिन जैसे बचपन में हम पूछते थे कि calculator है तो फिर maths क्यों सीखें, अब समझ आता है कि fundamentals क्यों सीखने चाहिए। अगर basics नहीं जानते, तो इसे प्रभावी ढंग से इस्तेमाल नहीं कर सकते। अगर GPT-4 तब मौजूद होता जब मैं PHP सीख रहा था, तो शायद आज जितनी बुनियादी समझ है उतनी नहीं होती। मुझे इस बात का फ़ायदा है कि मैंने tool आने से पहले सीखा
    मुझे code quality भी खास तौर पर गिरी हुई नहीं लगती, बल्कि कभी-कभी यह और भी ज़्यादा polished नतीजे देता है

    • कई मामलों में code quality बेहतर दिखती है, लेकिन उसमें मेरे बनाए जाने वाले code की तुलना में सूक्ष्म bugs ज़्यादा होते हैं
      मुझे काफी आलोचना अभी जल्दबाज़ी लगती है, और यह ज़्यादा उस डगमगाती प्रगति जैसा है जिसे अतिरिक्त infrastructure support चाहिए। ऐसे linter integration कहाँ हैं जो compile ही न होने वाले output को रोकें, और ऐसी सुविधाएँ कहाँ हैं जो आसान स्तर की गलतियाँ अपने-आप ढूँढ़कर ठीक करें
      generated AI development environment में testing कैसी दिखनी चाहिए और उसे कैसे बदलना चाहिए, यह भी अभी खुला सवाल है। हो सकता है TDD या BDD जैसे procedural approaches में फायदा अधिकतम और लागत न्यूनतम करने का कोई बेहतर तरीका हो
      पिछले 1~2 साल वह समय रहे हैं जब एक बड़ा तकनीकी बदलाव मौजूदा workflow पर बस फेंक दिया गया। किसी भी tool का नतीजा उसकी अपनी क्षमता और उसे इस्तेमाल करने वाले व्यक्ति के अनुभव—दोनों के मेल से बनता है
      industry को development में generative AI को integrate करने का बहुत अधिक अनुभव और समझ जुटानी होगी, तभी इसकी वास्तविक net value का अंदाज़ा लगेगा। मुझे लगता है कम से कम 2~3 साल और चाहिए होंगे—technology के adapt होने की वजह से नहीं, बल्कि इंसानों को adapt होने में लगने वाले समय की वजह से
    • अच्छा है कि ChatGPT हमारे career के काफ़ी बाद के दौर में आया। हम अपने formative phase में auto-generated code से प्रतिस्पर्धा किए बिना सीख सके
    • यह आपकी स्थिति है, लेकिन आगे आने वाला नया coding paradigm “code generate करो, test करो, fail हो, फिर regenerate करो, फिर test…” जैसा हो जाने का खतरा है, जहाँ components को तोड़ा ही नहीं जाता
      मैं पहले ही देख चुका हूँ कि मेरी बनाई basic CRUD framework के ऊपर 20 की उम्र वाले लोग full-stack spaghetti के ढेर पैदा कर रहे हैं। अगर आप 60 seconds में “MMO framework” generate कर सकते हैं, तो शुरू से TODO app बनाने की प्रेरणा कम हो जाती है
      यह कुछ वैसा ही है जैसे 12 साल पहले relational fundamentals सीखने से पहले मैंने Firebase इस्तेमाल किया था, और basics तक पहुँचने में कई साल लग गए थे
    • यह कैसे interact करता है, यह जानने की जिज्ञासा है। क्या आप code के blocks chat में paste करते हैं, या जो नया code लिखना है उसे समझाकर feedback के आधार पर फिर से लिखवाते हैं, या कोई और तरीका अपनाते हैं?

  • भविष्य को सटीक रूप से नहीं देखा जा सकता, लेकिन मेरा मानना है कि गुणवत्ता को पहचानने का तरीका बदल जाएगा
    ऐसा माहौल है कि हमारे आसपास के हर क्षेत्र—EV, healthcare, IT, finance आदि—में technology बड़ी समस्याओं की उद्धारक बन जाएगी। साथ ही, यह भी लगातार साफ हो रहा है कि technology का इस्तेमाल मुख्य रूप से market, government, nation-state आदि को बड़ा करने में होता है, और यह पहले से ही रिस रही abstractions के ऊपर एक और परत चढ़ाने के तरीके से काम करती है। यह समस्याएँ हल करने से ज़्यादा उनके लक्षणों को बस पिघलाने जैसा लगता है
    गुणवत्ता में धीमापन शामिल है, लक्षणों के इलाज की अपनी सीमाएँ हैं, और इंसान अगर बस और abstractions जोड़ते रहें तो वे चुनौतियों को संभाल नहीं पाएँगे, इसलिए वह धीमापन ज़रूरी होगा
    मेरा मानना है कि और तेज़ होना चाहिए, यह सोच गलत है। इंसान होने के नाते चुनौती की बुनियाद को समझे बिना, सतही लाभ के लिए उसे हल करने की कोशिश से गुणवत्ता नहीं आती
    LLM हमारे क्षेत्र के लिए आपदा हैं। क्योंकि वे उस औसत मानवीय गलती को बढ़ावा देते हैं जिसमें लोग असली काम किए बिना लक्ष्य तक पहुँचना चाहते हैं। असली काम है सही होने के बारे में धारणाएँ लागू करना और यह समझना कि आप वास्तव में क्या हल करना चाहते हैं
    अच्छी बात यह है कि हर कोई बस तेज़ी से आगे नहीं बढ़ना चाहता; कुछ लोग फिर से बुनियाद सीख रहे हैं, सावधानी से फैसले लागू कर रहे हैं, और ऐसे विचार व tools को पैना कर रहे हैं जो लंबे समय तक टिकने वाली गुणवत्ता बना सकें

    • यह जानने की जिज्ञासा है कि “आप वास्तव में क्या हल करना चाहते हैं, इसे समझने” में LLM कितनी बाधा डालते हैं
      मेरा अनुभव लगभग उलटा है। गंदे API या library को खंगालने जैसे काम कठिन हिस्सों को रोकने के बजाय, LLM तब बेहद पीड़ादायक स्पष्टता के साथ दिखा देते हैं कि meaningful काम में मेरी सोच कहाँ ठोस नहीं है
      LLM के साथ कुछ करना हो तो लिखना पड़ता है, और लिखने के लिए सोचना पड़ता है। जो मैं करना चाहता हूँ उसे सावधानी से वाक्य में ढालना, LLM से उसकी चुभन पाना, और उस प्रक्रिया में अपनी सोच की खाली जगहें ढूँढकर उन्हें साफ करना—बाद में फिर से देख सकने वाला वह chat history अक्सर सबसे अधिक उपयोगी होता है
      खासकर app के शुरुआती चरण में उसका आकार तय करते समय, उस वक्त जो काम मुझे करना चाहिए लगा था उसे track करने और बाद में फिर देख लेने में कि क्या वह अब भी सही है, यह बहुत उपयोगी है
    • महान jazz pianist Bill Evans ने अपने भाई के साथ एक interview में कहा था कि amateur musicians की आम गलती है ज़रूरत से ज़्यादा बजाना
      वे club में pros को बजाते सुनते हैं, घर लौटकर उसकी नकल करने की कोशिश करते हैं, लेकिन अंत में वह बिना बुनियाद का एक अव्यवस्थित ढेर बन जाता है। उन्होंने इस बात पर ज़ोर दिया कि सरल चीज़ें करने में संतोष होना चाहिए और धीरे-धीरे मज़बूत बुनियाद बनानी चाहिए
      यह insight AI-generated code के इस्तेमाल पर भी लगभग जस का तस लागू होता है
    • भविष्य को सटीक रूप से नहीं देखा जा सकता, लेकिन मेरा मानना है कि गुणवत्ता को पहचानने का तरीका बदल जाएगा
      IKEA furniture इसका अच्छा उदाहरण है। अगर आप खुद furniture बनाते हैं, तो IKEA की cardboard जैसी चीज़ों की तुलना में उसके आसपास होने का एहसास कहीं बेहतर होता है। लेकिन लोगों के दिमाग में लागत, गति और सुविधा सबसे महत्वपूर्ण लगती हैं
    • कोई कला-कृति बनाने का अर्थ तब बनता है जब उसमें अंतिम रूप तक पहुँचने का संघर्ष, मानसिक अनुभव, और creative expression के रूप में artist की कहानी भी शामिल हो
      AI models उस जन्मजात अनुभव को छीन लेते हैं और सिर्फ अंतिम परिणाम की मलाई देते हैं। यह वैसा ही है जैसे किसी वास्तविक रिश्ते में जाकर चरमसुख तक पहुँचने की जगह porn देखना
    • LLM एक tool है। tool को दोष देना बेतुका है। अगर screwdriver का इस्तेमाल hammer या murder weapon की तरह किया गया, तो उसके लिए screwdriver को दोष नहीं दिया जा सकता
      समझदारी से इस्तेमाल किया जाए तो Copilot जैसे tools मददगार होते हैं। वे boilerplate और उबाऊ हिस्से संभाल लेते हैं ताकि इंसान भारी सोच पर ध्यान दे सके
      और फिर, अभी यह शुरुआती दौर है। फैसला सुनाने के लिए बहुत जल्दी है, और यह भी नहीं लगता कि यह गायब होने वाला है

  • methodology ऐसी लगती है कि 2023 की commit activity की तुलना पिछले वर्षों से की गई, और यह जाने बिना कि उसमें से कितना Copilot से प्रभावित था, बदलावों को एक hypothesis की तरह पढ़ लिया गया। यह काफ़ी डगमगाता हुआ approach है
    और यह भी लिखा है कि “2024 prediction के लिए OpenAI के gpt-4-1106-preview Assistant से मौजूदा data पर second-order regression चलाया गया।” तो सवाल उठता है कि sklearn, R, Excel जैसे साधारण regression tools की जगह क्या GPT से सिर्फ चार data points पर regression करवाया गया? अगर ठीक से भी किया गया हो, तो पहले वाली चिंता और सिर्फ चार data points को देखते हुए इसकी विश्वसनीयता कमज़ोर लगती है

    • सिर्फ summary मत देखिए, paper पढ़ें तो methodology समझाई गई है। output में सिर्फ चार data points इसलिए हैं क्योंकि वह summary है; input data उससे काफ़ी ज़्यादा है
    • उतना भी नहीं। appendix में दिया गया prompt है: “अगर 2022 और 2023 को ही देखें, तो second-order regression 2024 के लिए क्या predict करेगा?”
      second-order regression सुनने में प्रभावशाली लगता है, लेकिन दो data points हों तो असल में वह बस “रेखा को आगे बढ़ाना” ही होता है। इसलिए 2024 prediction मूल रूप से लगभग अर्थहीन है
    • मैंने ऐसी ही चीज़ें किस्सों-कहानियों के स्तर पर देखी हैं, इसलिए study के result से कुछ हद तक सहमति है, लेकिन यह मानना कठिन है कि data निष्कर्षों को वास्तव में support करता है। यह COVID काल की hiring boom और उसके बाद की layoffs की वजह से भी हो सकता है

  • मैं मूल शोध का लेखक हूँ। यह देखकर अच्छा लगा कि बहुत से लोग दीर्घकालिक कोड क्वालिटी को लेकर सोच रहे हैं। 2023 में churned code और duplication, यानी copy-paste code, का बढ़ना और moved code का घटना हमारी अपेक्षा से भी बड़ा था
    मेरी इच्छा है कि डेवलपमेंट टीमें और AI Assistant बनाने वाले लोग ऐसे metrics और incentives अपनाएँ जो नए जोड़े गए code की तुलना में reused code को प्रोत्साहित करें। खासकर वे टीमें जोखिम में हैं जो ऐसे managers के अधीन हैं जो मानते हैं कि performance evaluation में LoC होना चाहिए। GitHub के शोध के अनुसार लगभग एक-तिहाई जगहों पर ऐसा है, और मौजूदा पीढ़ी के code assistant tools Tab दबाकर commit कर देने और भविष्य के technical debt के बीज बो देने को बहुत आसान बना देते हैं। जैसा Adam Tornhill ने Twitter पर कहा था, “AI-assisted programming की मुख्य चुनौती यह है कि अब ऐसे code का बड़े पैमाने पर निर्माण करना बहुत आसान हो गया है जिसे शुरू से लिखना ही नहीं चाहिए था”
    हालाँकि, मौजूदा शोध की एक सीमा यह है कि इसमें AI द्वारा लिखे गए code को सीधे मापा नहीं गया है। इसमें सिर्फ पिछले 4 वर्षों में code quality और AI Assistant के प्रसार के बीच correlation दिखाया गया है। अच्छा होगा अगर GitHub या अन्य AI Assistant कंपनियाँ follow-up research में सहयोग करें ताकि “पूरी तरह AI द्वारा सुझाया गया code”, “AI सुझाव जिसे इंसान ने संशोधित किया”, और “शुरू से लिखा गया code” के बीच quality differences को सीधे मापा जा सके
    अगले शोध में मैं यह भी सीधे मापना चाहता हूँ कि AI उपयोग के अनुसार bug frequency कैसे बदलती है। अगर और ऐसी बातें हों जिन्हें मापा जाना चाहिए, तो कृपया सुझाव दें। मैं लगभग हर 2 महीने में नया research paper प्रकाशित करने की कोशिश कर रहा हूँ

    • नए जोड़े गए code की बजाय reused code को प्रोत्साहित करना ऐसा लगता है जैसे एक मूर्खतापूर्ण metric को दूसरे से बदलना
      Code reuse एक codebase के भीतर बहुत शक्तिशाली हो सकता है, लेकिन codebase के पार जाते समय मैंने इसे भ्रम पैदा करते भी देखा है। यह उपयोगी भी हो सकता है, या अनुपयुक्त और भ्रमित करने वाला भी, और नतीजा अक्सर judgment पर निर्भर करता है
      मेरा मानना है कि डेवलपर्स का मूल्यांकन software outcomes के आधार पर करना बेहतर है। उदाहरण के लिए, resource usage के मुकाबले organizational impact, या ऐसी service errors जो dependent services या infrastructure से उत्पन्न न हुई हों
      आधुनिक programmer सिर्फ code के लिए जिम्मेदार व्यक्ति नहीं है, बल्कि वह quality engineer/tester, technical product manager, project manager, programmer, performance engineer, और infrastructure engineer का जानबूझकर मिला-जुला रूप है। मैं शोध को कमतर नहीं बताना चाहता; code quality की गहराई से परवाह करने वाला कोई है, यह देखकर अच्छा लगा, और मेरा मानना है कि evaluation methods पर अलग तरह से सोचना चाहिए
    • अगर AI द्वारा लिखे गए code को सीधे मापा ही नहीं गया, तो शायद अधिक सटीक शीर्षक यह होना चाहिए: “नए शोध के अनुसार पिछले 4 वर्षों में कोड क्वालिटी घटी है”
      यह भी जानना चाहूँगा कि क्या बदली हुई tech economy जैसे अन्य संभावित स्पष्टीकरणों को नियंत्रित किया गया था
    • Refactoring vs Refuctoring paper में वास्तविक AI benchmarking data है: https://codescene.com/hubfs/whitepapers/Refactoring-vs-Refuc...
      इस paper ने वास्तविक code refactoring tasks में सबसे लोकप्रिय LLMs के प्रदर्शन को benchmark किया, और कहा कि सिर्फ 37% मामलों में AI ने functionally correct refactoring दिया
      AI-assisted coding वास्तव में उपयोगी है, लेकिन हमें skilled humans को loop में बनाए रखना होगा और marketing hype से परे यथार्थवादी expectations तय करनी होंगी

  • मेरा workflow आमतौर पर ऐसा होता है: documentation को सरसरी तौर पर देखना, prototype बनाना, code को थोड़ा polish करना, tests जोड़ना, चीज़ें इधर-उधर ले जाना, तोड़ना, फिर से काम करना, documentation को ध्यान से पढ़ना, और अधिक refactor करने के बाद ही समस्या को इतना समझ पाना कि code का 80% हटा दूँ और उसे सही तरीके से फिर से बनाऊँ
    अगर Copilot मुझे prototype चरण में इतना कामचलाऊ code दे दे कि मैं बस आगे बढ़ जाऊँ, तो मैं पूरी चीज़ को सही ढंग से structure करने लायक गहराई से समझ ही नहीं पाता। यह workflow के 90% हिस्से को skip करा देता है, लेकिन इसकी कीमत चुकानी पड़ती है। बेशक, development के अंतिम चरणों में Copilot बहुत मददगार हो सकता है
    अगर शोध के नतीजे सही हैं, तो इसमें हैरानी नहीं है। खराब code अधूरी समझ से आता है, और Copilot मेरी दी हुई समझ से अधिक समझ नहीं रख सकता। वह औसत programmer से बेहतर code लिख सकता है, लेकिन परिणाम input से बेहतर नहीं हो सकता। जब लोग “prompt engineering” पर इतना ध्यान देते हैं, तो फिर यह देखकर हैरानी क्यों होती है कि VSCode के खराब “prompts” खराब परिणाम देते हैं

    • मुझे समझ नहीं आता कि Copilot का उपयोग करना बाद के अधिकांश चरणों को skip करने के बराबर क्यों माना जाए। आखिर उन चरणों को छोड़ने का निर्णय तो आप खुद लेते हैं, है न?
      मेरे अनुभव में Copilot शुरुआत करने में शानदार है। कभी code अच्छा होता है, कभी औसत, और कभी पूरी तरह टूटा हुआ
      फिर भी यह मूल्यवान है क्योंकि यह सोच को शुरू कर देता है। इसे इस्तेमाल करने से पहले मैं कहीं अधिक समय बर्बाद करता था। हो सकता है मेरे दिमाग की wiring ही कुछ अलग हो

  • मैं जूनियर हूँ और VSCode में Codeium इंस्टॉल किया हुआ है, लेकिन ज़्यादातर मामलों में यह बहुत ध्यान भटकाने वाला लगता है। इतने सारे लोग ऐसे सहायक टूल्स क्यों इस्तेमाल करते हैं, यह मुझे ठीक से समझ नहीं आता
    Phind जैसी चीज़ उपयोगी लगती है। जब कुछ समझ में नहीं आता, तब लगभग 60% मामलों में यह समस्या को समझने में मदद करती है। जैसे थका होने या मूर्खता में न दिखे छोटे-मोटे बग ढूँढ लेना
    दूसरी ओर, Codeium शायद framework boilerplate बनाने में उपयोगी हो सकता है, लेकिन scraper, simple data pipeline, और pure JS+HTML/CSS वाले छोटे अनुभवों में इसके suggestions देखते रहना बहुत चिढ़ाने वाला है। खासकर क्योंकि यह अक्सर काम भी नहीं करता, जैसे कोई एक argument छूट गया, या कोई और छोटा कारण, और अंत में debugging में समय लगाना पड़ता है
    JavaScript में methods और anonymous functions को अंतहीन daisy chain की तरह जोड़ने की एक आम style भी है, और मुझे वह सच में मुश्किल लगती है। मैं lines तोड़कर लिखना और functions व variables को नाम देना पसंद करता हूँ। code suggestions भी अक्सर उसी style का पालन करते हैं, शायद training data ऐसा ही है। Codeium कहता है कि वह इसे सीखता है, और कभी-कभी वाकई ऐसा लगता भी है
    मुझे सबसे ज़्यादा चिंता इस बात की है कि अगर मैं, एक junior होने के नाते, ऐसे सहायक टूल्स पर code छोड़ दूँ, तो फिर मैं सीखूँगा कैसे। Phind को context और सवाल देना सीखने में मदद करता है, या कम से कम इंटरनेट पर खुद खोजने की दिशा देता है, लेकिन सिर्फ Tab दबाकर कोई कैसे सीख सकता है, यह मुझे समझ नहीं आता
    कुछ दिन पहले मुझे एहसास हुआ कि बहुत से लोग, developers भी, LLM को बेहतर बनने के टूल की तरह नहीं बल्कि मेहनत के विकल्प की तरह इस्तेमाल कर रहे हैं। यह सिर्फ इस डर की बात नहीं कि company replace कर देगी; मुझे लगता है यह self-reflection के स्तर पर भी डरने वाली बात है
    coding मेरी ज़िंदगी का जुनून नहीं है, लेकिन मुझे यह पसंद है। क्योंकि यह चीज़ों को घटित करने देता है और complexity को संभालने देता है। अगर आप समझते ही नहीं कि क्या हो रहा है, तो आप कुछ बना भी नहीं सकते, और यह भी नहीं समझ पाएँगे कि complexity कब आपको निगलने वाली है

    • हो सकता है coding आपकी ज़िंदगी का जुनून न हो, लेकिन coding से आप क्या पाना चाहते हैं और tools का मूल्यांकन कैसे करते हैं, इसे इतने अच्छे ढंग से कहते हुए मैंने हाल में किसी को नहीं देखा
      ऐसे ही करते रहिए, और अगर नहीं बदले तो आप अच्छी जगह पहुँचेंगे। आप निश्चित रूप से सही रास्ते पर हैं
    • अब तक AI का सबसे अच्छा उपयोग मैंने तब किया जब मैंने उससे controller देखकर OpenAPI spec बनाने को कहा। वह लगभग सही था, और बस कुछ models को असलियत के अनुसार ठीक करना पड़ा
      महत्वपूर्ण बात यह थी कि मैंने अपने करियर में API specs हाथ से बहुत लिखे हैं, इसलिए 1) मैं तुरंत समस्या देख सका और 2) बिना अतिरिक्त मदद के उसे ठीक कर सका। prompt को refine करने से ज़्यादा तेज़ models को हाथ से ठीक करना था
      जिस क्षेत्र को आप अच्छी तरह जानते हैं, उसमें यह देखना हैरान करता है कि जो काम पूरी सुबह ले लेता, वह 30 सेकंड में हो जाता है। लेकिन मैं AI से वह काम नहीं करवाता जो मैं खुद करना नहीं जानता। उसकी जगह, मैं जो काम कर रहा हूँ, उसके trade-offs, संभावित security issues वगैरह पर AI से बहुत बातचीत करता हूँ
      यह उस junior engineer जैसा है जिसके पास मेरी इस्तेमाल की भाषा में PhD हो। वह बहुत कुछ नहीं समझता, लेकिन जो समझता है, उसे गहराई से समझता हुआ लगता है
    • उस JavaScript style की बात करें तो, आप सही रास्ते पर हैं
      कुछ developers, खासकर JS developers, chaining पसंद करते हैं जबकि एक ही line में रखने के अलावा उसका कोई फायदा नहीं होता। और वह कोई फायदा नहीं है। जैसे कर रहे हैं वैसे ही करते रहिए, और इस बेवकूफ idiom को अपने दिमाग में घुसने मत दीजिए
    • Codeium के बारे में तो ज़्यादा नहीं जानता, लेकिन शायद किसी अधिक mature codebase में, जहाँ आपकी configuration style अच्छी तरह झलकती हो, Copilot आज़माना बेहतर हो सकता है
      इस तकनीक के सबसे चौंकाने वाले पल वे होते हैं जब यह मेरी style और preferences के मुताबिक ढल जाती है। जैसे चीज़ों के नाम वैसे रखना जैसा मैं चाहता हूँ, और जो method मैंने अभी लिखा है उसे दोबारा implementation करने के बजाय सही तरह इस्तेमाल करना
      खाली project या छोटे project में मैंने इसे ज़्यादा नहीं आज़माया, लेकिन अगर आसपास के context के आधार पर यह मेरे पहले से इस्तेमाल किए जा रहे तरीके की ओर मज़बूती से झुकी न हो, तो यह काफ़ी कम आदर्श लगेगी
    • tools और tool design बहुत महत्वपूर्ण हैं। मैंने VSCode में Codeium और IntelliJ में GitHub Copilot इस्तेमाल किया है, और GitHub Copilot + IntelliJ का अनुभव और गुणवत्ता Codeium + VSCode से कहीं बेहतर था
      AI सहायक टूल्स का सबसे बड़ा उपयोग मेरे लिए tests लिखना और “इसके जैसा लेकिन थोड़ा अलग” तरह के दोहराए जाने वाले बदलाव जल्दी करना रहा है। IntelliJ + GitHub में, अगर कोई नया parameter कई methods और files में दिखना चाहिए, तो पहले दो-तीन variations मैं खुद टाइप कर दूँ तो बाकी अक्सर enter + tab से हो जाता है। context बाकी भर देता है
      VSCode का Codeium ऐसा लगता है कि AI खुद भी कमज़ोर है, और plugin भी इस तरह लिखा गया है कि suggestion और accept keys अक्सर रास्ते में आती हैं। दोहराए जाने वाले कामों में यह फिर भी मदद करता है, लेकिन लक्ष्य हासिल करने का तरीका सुझाने में कमज़ोर है

  • मैंने ChatGPT के साथ Django/Python आधारित Yourls clone बनाने की कोशिश की। मैंने साफ़ कहा था कि custom short URL की अनुमति हो और traffic tracking भी हो, लेकिन उसने logic या data model में उसे ठीक से शामिल नहीं किया। बाद में ठीक कराने के लिए फिर से बहुत specific निर्देश देने पड़े
    AI tools ऐसे हैं जैसे कोई junior developer आपका काम कर रहा हो। बस, बहुत ज़्यादा तेज़
    अगर आपको खुद नहीं पता कि आप क्या कर रहे हैं, तो यह सिर्फ गलतियाँ करने की रफ़्तार बढ़ा देता है

    • सही बात। अगर आपको पता है कि आप क्या कर रहे हैं, तो यह चीज़ें बनाने की रफ़्तार भी बढ़ा देता है
    • “AI tools ऐसे हैं जैसे junior developer काम कर रहा हो, बस बहुत तेज़” — यह बात सच में शानदार है
      हाल ही में मुझे SELECT statement के column alias में table name prefix जोड़ना था, और उसके लिए कोई built-in सुविधा नहीं थी, तो मैंने ChatGPT को schema definition और query देकर लगभग 40 columns की selection list लंबी लिखने को कहा
      मुझे अलग-अलग RDBMS में यह काम automate करने का कोई अच्छा तरीका नहीं मिला, और regex या दूसरे text manipulation से भी यह संभव था, लेकिन समस्या समझाकर ज़रूरी output लेना सुखद रूप से सरल था
      इसके अलावा मैं LLM को autocomplete की तरह इस्तेमाल करता हूँ। यह अच्छे function names दिलवाने में भी मदद करता है, क्योंकि इतनी-सी जानकारी से भी LLM अक्सर एक ठीक-ठाक शुरुआती बिंदु दे देता है। खासकर उन APIs या languages में जिन्हें मैंने ज़्यादा इस्तेमाल नहीं किया, जहाँ मेरी समस्या शायद पहले ही हज़ारों बार हल की जा चुकी हो। अब तो मैं StackOverflow भी लगभग इस्तेमाल नहीं करता
      इसी वजह से मैंने Copilot खरीदा और ChatGPT भी बहुत इस्तेमाल करता हूँ। LLM, IntelliSense जैसे अच्छे autocomplete, OpenAPI spec या EF/JPA code generation, ER model आधारित DB migration/table creation, containers, और JetBrains जैसे स्मार्ट IDEs के साथ मिलकर, मेरी सबसे पसंदीदा चीज़ों में से एक है
    • मैं सोचता हूँ कि अगर junior developers को लगातार “काम करने वाला” और “काफ़ी अच्छा” code मिलता रहेगा, तो वे senior developer कैसे बनेंगे
      companies ज़्यादा code और वह भी तेज़ी से चाहेंगी, और इस भँवर से शायद ऐसे लोग कम निकलेंगे जो सच में जानते हों कि वे क्या कर रहे हैं

  • पूरा पेपर यहाँ है: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...

  • “AI” सहायक टूल बाज़ार में आने से पहले ही DRY code के खिलाफ़ प्रतिक्रिया मौजूद थी, और दुर्भाग्य से 2019~2022 के दौरान Twitter इस्तेमाल करते समय यह बढ़ती हुई दिख रही थी
    कुछ युवा developers का code के प्रति नज़रिया उस चीज़ से बहुत अलग है जो मैंने सीखी थी। वे Gang of Four और design patterns को बहुत तिरस्कार से देखते हैं, और शायद यह नहीं जानते कि उनके पसंदीदा frameworks उन्हीं patterns से भरे हुए हैं। वे DRY, खासकर SOLID जैसे principles का मज़ाक उड़ाते हैं
    Twitter जैसी जगहों पर जितनी ज़्यादा तंज़भरी और विरोधी पक्ष पर वार करने वाली बात होती है, उतनी ही ज़्यादा engagement मिलती है। यह काफ़ी चिंताजनक रुझान है

    • प्रतिक्रिया सही DRY, यानी single source of truth, के खिलाफ़ नहीं है, बल्कि नकली DRY के खिलाफ़ है जो सिर्फ़ syntactically मिलते-जुलते code को मिटाने की सनक रखता है
      enterprise codebases में जो कुछ होता है, उसके लिए मेरे मन में भी बहुत तिरस्कार है। SOLID guru कुछ भी कहें, classes के ज़रिए indirect layers पर layers चढ़ाना ठीक नहीं है। best practices, DRY, SOLID बस बहाने की तरह इस्तेमाल होते हैं
    • मैं युवा developer नहीं हूँ, लेकिन मैं भी SOLID और DRY का मज़ाक उड़ाता हूँ। साथ ही, मैं code quality को भी बहुत महत्वपूर्ण मानता हूँ
    • SOLID ज़्यादा बढ़ा-चढ़ाकर बेचा गया, overhyped marketing term ज़्यादा लगता है, जो somehow academia तक पहुँच गया, जबकि इसका असली computer science या software engineering की बुनियाद से काफ़ी कम संबंध है
      मैं यह बर्दाश्त नहीं कर पाता कि Java-शैली की object-oriented thinking से निकली मनमानी principles की सूची को software modeling की सच्चाई की तरह माना जाए। SOLID को कैसे समझना चाहिए इस पर होने वाली लाखवीं बहस से भी मैं थक चुका हूँ
      CAP theorem को लेकर लोग इस तरह नहीं लड़ते, क्योंकि वह सिर्फ़ किसी cool acronym में फिट बैठने वाला मनमाना idea bundle नहीं है
      DRY का भी दुरुपयोग हो सकता है, और लोग जब उसे बिल्कुल परफेक्ट चीज़ की तरह पेश करते हैं तो उसी रवैये के खिलाफ़ प्रतिक्रिया होती है
    • लगता है यह व्यक्ति भी ऐसा ही सोचता है: https://twitter.com/ID_AA_Carmack/status/753745532619665408
    • मैंने भी ऐसा ही रुझान देखा है। समय के साथ मुझे लगा कि कई आलोचक उन principles को सही से समझते ही नहीं जिनकी वे आलोचना कर रहे हैं
      उदाहरण के लिए, DRY का महत्वपूर्ण principle यह नहीं था कि code को दोहराओ मत, बल्कि यह था कि ideas को दोहराओ मत। आदर्श रूप से, system के किसी भी concept के लिए एक single source of truth होना चाहिए, और उस concept को समझने या बदलने के लिए भी सिर्फ़ एक ही जगह होनी चाहिए
      इसलिए meaningful abstraction की जगह काफ़ी सारा code copy-paste करना अक्सर बुरा होता है। साथ ही यह चेतावनी भी है कि जैसे ही आप किसी idea को दोहराते हैं, अलग-अलग representations को sync में रखने का लगातार debt पैदा हो जाता है। यह schema define करने वाली DB migrations और अलग ORM classes, backend API और frontend client, retained mode UI में form values और internal state, और data model invariants जो types और unit tests दोनों में व्यक्त होते हैं, इन सब पर लागू होता है
      जो लोग इस बात का विरोध करते हैं कि अलग ideas जिनका implementation संयोग से मिलता-जुलता है, उन्हें ज़बरदस्ती एक कर दिया जाए क्योंकि बाद में यह maintenance risk बन सकता है, वे ग़लत नहीं थे। बस वे एक ऐसे strawman पर हमला कर रहे हैं जो DRY का मूल मतलब कभी था ही नहीं
      अब सवाल यह है कि नए developers इन principles को सही तरह से कहाँ और कब सीखते हैं। कुछ लोगों की academic background होती है, लेकिन सभी की नहीं, और यह भी ज़रूरी नहीं कि academic CS courses practical development skills बहुत सिखाएँ
      जब मैंने शुरुआत की थी, तब seniors juniors को काफ़ी practical और ठोस training देते थे, लेकिन आज की frequent job-hopping culture और juniors को long-term investment की तरह hire करने में हिचकिचाहट के माहौल में ऐसा बहुत कम होता दिखता है। formal courses किसी व्यक्ति के लिए महँगे हो सकते हैं, लेकिन company के हिसाब से लगभग कोई लागत नहीं, फिर भी वास्तव में company जिन नए developers को भेजती है वे शायद बहुत कम होते हैं
      पढ़ने लायक किताबें भी हैं, लेकिन पता नहीं 2024 के 20-somethings खुशी-खुशी उस पुराने format से जूझना चाहेंगे या नहीं जिसमें कटी हुई लकड़ी के टुकड़ों पर स्याही छापी जाती है। आजकल बढ़ते हुए developers लगता है कि blogs और YouTube से ऐसे ideas बहुत सीखते हैं, और वहाँ बेहतरीन सामग्री भी है, लेकिन हमेशा की तरह समस्या यह है कि अधूरी समझ या संदिग्ध पैकेजिंग वाले कचरे के बीच से उसे ढूँढ़ना पड़ता है
      इसलिए जब एक ऐसा जादुई टूल आ जाता है जो दिल की एक धड़कन के भीतर लगभग कामचलाऊ code की 12 lines बना देता है, तो यह हैरानी की बात नहीं कि युवा developers उस code की गहरी समस्याओं से लगभग अनजान रहते हुए भी उसे शानदार समझें। इसमें किसी एक को दोष देना मुश्किल है, लेकिन यह साफ़ तौर पर एक समस्या है, और अच्छा होगा अगर हमें पता हो कि इसके बारे में क्या किया जाए