AI open source डेवलपर्स को धीमा बनाता है। Peter Naur इसके पीछे की वजह समझा सकते हैं

 (johnwhiles.com)
25 पॉइंट द्वारा GN⁺ 2025-07-15 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • हालिया शोध के अनुसार जब open source डेवलपर्स अपने अच्छी तरह परिचित codebase में AI tools का उपयोग करते हैं, तो काम का समय उल्टा 19% बढ़ जाता है
  • डेवलपर्स मानते हैं कि AI उन्हें तेज़ बनाता है, लेकिन वास्तव में वे धीमे हो जाते हैं — यानी धारणा और वास्तविकता के बीच अंतर मौजूद है
  • मुख्य कारण डेवलपर्स के पास मौजूद परिष्कृत mental model (समझ की संरचना) और AI के बीच ज्ञान हस्तांतरण की सीमाएँ हैं
  • Peter Naur के सिद्धांत के अनुसार, प्रोग्रामिंग में सबसे महत्वपूर्ण चीज़ डेवलपर के दिमाग़ में मौजूद "मानसिक मॉडल" है
    • वे डेनमार्क के कंप्यूटर विज्ञान के अग्रणी और 2005 के Turing Award विजेता थे। उन्होंने प्रोग्रामिंग भाषा के syntax को समझाने में उपयोग होने वाले Backus-Naur form (BNF) notation में योगदान दिया
  • दीर्घकालिक दृष्टि से किसी प्रोजेक्ट को गहराई से समझने के लिए खुद कोड लिखते हुए mental model बनाना महत्वपूर्ण है

AI open source डेवलपर्स को धीमा क्यों बनाता है

  • Metr के शोध के अनुसार AI tools का उपयोग करने पर समस्या हल करने की गति उल्टा 19% धीमी हो गई
  • डेवलपर्स ने काम शुरू करने से पहले उम्मीद की थी कि AI उन्हें 24% तेज़ करेगा, और काम के बाद भी उन्होंने माना कि वे वास्तविकता से 20% तेज़ थे
  • यह अध्ययन ऐसे अनुभवी डेवलपर्स पर किया गया जो उन open source projects को स्वयं maintain करते हैं जिन्हें वे गहराई से समझते हैं
  • यह परिणाम हर डेवलपर पर सामान्य रूप से लागू नहीं होता, लेकिन इस समूह में AI tools ने productivity पर उल्टा असर दिखाया
  • enterprise environment या ऐसे सामान्य डेवलपर्स जिन्हें नए codebase के साथ जल्दी adapt करना होता है, उनके लिए AI tools productivity बढ़ाने में अधिक सकारात्मक भूमिका निभा सकते हैं

AI अनुभवी open source डेवलपर्स को धीमा क्यों बनाता है

  • Peter Naur के “Programming as Theory Building” पेपर के अनुसार प्रोग्रामिंग का असली output code नहीं, बल्कि ‘प्रोजेक्ट के बारे में डेवलपर का mental model’ है
  • यही mental model सिस्टम की समझ, समस्या की diagnosis, और प्रभावी सुधार का केंद्र है
  • LLM-आधारित AI डेवलपर के mental model तक सीधे पहुँच नहीं सकता, और कुछ जानकारी दी भी जाए तो ज्ञान हस्तांतरण की प्रक्रिया में मूलभूत हानि होती है
    • उदाहरण के तौर पर, जैसे किसी को बच्चे को सुलाने का काम सौंपते समय स्पष्ट निर्देश देने पर भी वह अक्सर आपके इरादे के अनुसार काम नहीं करता
  • mental model का हस्तांतरण बेहद जटिल है, और AI का केवल text के आधार पर इसे आत्मसात करना लगभग असंभव है
  • इसलिए जिस प्रोजेक्ट को आप गहराई से समझते हैं, उसमें AI को काम सौंपने से productivity घट सकती है
  • डेवलपर के पास मौजूद समृद्ध context और सहज समझ को AI आसानी से replace नहीं कर सकता

क्या कार्यस्थल पर AI tools पर प्रतिबंध लगा देना चाहिए?

  • ज़रूरी नहीं। यह मुख्यतः उन लोगों पर लागू होता है जो ऐसे प्रोजेक्ट पर काम कर रहे हैं जिसे वे खुद अच्छी तरह जानते और समझते हैं
  • कई enterprise डेवलपर्स अक्सर ऐसे senior के छोड़े हुए code को maintain करते हैं जो कंपनी छोड़ चुके हैं, या वे पूरे सिस्टम architecture को गहराई से समझे बिना काम कर रहे होते हैं
  • ऐसे माहौल में AI codebase को तेज़ी से समझने और changes अपने-आप generate करने में मदद करके अल्पकालिक productivity बढ़ा सकता है
  • अगर केवल अल्पकालिक business value और तुरंत मिलने वाली efficiency देखी जाए, तो AI tools productivity में सकारात्मक भूमिका निभा सकते हैं

mental model बनाना और AI

  • अगर आपके पास प्रोजेक्ट का mental model नहीं है, तो LLM productivity बढ़ाने में मदद कर सकता है
  • लेकिन अगर software development का मूल स्वभाव ही ‘mental model बनाना’ है, तो AI पर अत्यधिक निर्भरता इस क्षमता को कमज़ोर कर सकती है
  • लंबे समय में यदि आप किसी प्रोजेक्ट को गहराई से समझना और सक्रिय रूप से बदलना चाहते हैं, तो खुद कोड लिखने का अनुभव ज़रूरी है
  • इसके उलट, यदि काम सिर्फ़ ‘किसी तरह चलता रहे’ वाले स्तर का है, तो AI का उपयोग अधिक efficient हो सकता है

अतिरिक्त चर्चा और निष्कर्ष

  • मौजूदा स्तर के AI tools के लिए पर्याप्त mental model रखने वाले डेवलपर्स की productivity बढ़ाना कठिन है
  • AI किस तरह mental model को बेहतर समर्थन दे सकता है, या अनुभवी डेवलपर्स की productivity को नाटकीय रूप से बढ़ा सकता है, इस पर अभी और शोध व विकास की ज़रूरत है
  • भविष्य में मॉडल इतने विकसित हो सकते हैं कि human डेवलपर्स को शायद mental model की उतनी आवश्यकता न रहे, लेकिन वर्तमान स्तर पर प्रत्यक्ष समझ और सीखना अनिवार्य है
  • अंततः, AI उस माहौल में बाधा बन सकता है जहाँ मैं क्या कर रहा हूँ इसकी गहरी समझ महत्वपूर्ण है, और उस माहौल में productivity tool बन सकता है जहाँ तेज़ परिणाम अधिक महत्वपूर्ण हैं

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

5 टिप्पणियां

 
paruaa 2025-07-16

> डेवलपर्स को लगता है कि AI ने उन्हें ज़्यादा तेज़ बना दिया है
AI की मदद से research तेज़ हो जाती है, इसलिए quality को बेहतर बनाया जा सकता है, तो क्या एक ही काम का नतीजा भी थोड़ा बेहतर quality के साथ नहीं आ सकता? शायद डेवलपर्स यह सोचते हैं कि काम के बाद जिस quality के नतीजे तक पहुँचना है, वहाँ अकेले पहुँचने की तुलना में AI की मदद से पहुँचना ज़्यादा तेज़ है।
मुझे यह भी लगता है कि अगर शुरू से इसका इस्तेमाल न किया जाता, तो शायद लोग अपनी सीमित जानकारी के भीतर ही implement करते, इसलिए ऐसा महसूस होता होगा.
 
tested 2025-07-15

> इसके उलट, अगर काम बस ‘किसी तरह चलने लायक बना देने’ वाला हो, तो AI का इस्तेमाल प्रभावी हो सकता है।

यह सिर्फ डेवलपर्स तक सीमित नहीं है, लेकिन लोगों की प्रवृत्तियां अलग-अलग होती हैं, इसलिए मुझे लगता है कि जो लोग संयोग से डेवलपर बन गए हैं और कोड लिखना या देखना पसंद नहीं करते या उससे डरते हैं, और जो व्यवस्थित संरचना या मेंटेनेंस के नजरिए से समझने के बजाय बस चीजें चलती रहें यही मानसिकता रखते हैं, उनमें AI पर निर्भरता या अंधविश्वास ज्यादा मजबूत दिखता है। नहीं भी हो सकता है।
 
GN⁺ 2025-07-15
Hacker News की राय
  • HN के सभी लोगों, मैं इस पेपर का लेखक हूँ।
    मुझे लगा कि इस ब्लॉग पोस्ट ने एक ऐसे ठोस कारण को दिलचस्प ढंग से उठाया है, जिसकी वजह से AI डेवलपमेंट की गति को धीमा कर सकता है।
    पेपर (सेक्शन C.1.5) में डेवलपर के उद्धरण भी हैं, उन्हें भी देखें।
    बहुत से लोग पेपर पढ़कर कोई एक ऐसा कारण ढूँढ लेते हैं जो उन्हें सही लगता है, और फिर यह निष्कर्ष निकालना आसान हो जाता है कि “धीमा होने की वजह सिर्फ यही एक समस्या है।”
    लेकिन वास्तव में इसमें कई तत्व हैं (कम-से-कम 5 संभावित हैं, और अधिकतम 9 तक को भी नकारा नहीं जा सकता; p.11 की factors table देखें)।
    किसी एक कारण को जिम्मेदार मानने के बजाय बहुआयामी कारण-विश्लेषण अधिक उचित है।
    जो लोग खुद इस पर प्रयोग करने की योजना बना रहे हों, उनसे अनुरोध है कि पेपर में दिए गए email पर अपने परिणाम ज़रूर साझा करें।
    और लेख का शीर्षक “AI slows down open source developers. Peter Naur can teach us why” रखा गया है, लेकिन मुझे अधिक सटीक रूप में यह कहना उचित लगता है: “2025 की शुरुआत में AI अनुभवी open source डेवलपर्स को धीमा करता है। Peter Naur एक खास कारण पर अधिक संदर्भ देता है।”
    यह अभिव्यक्ति शायद कम उत्तेजक लगे, लेकिन मुझे सटीकता अधिक महत्वपूर्ण लगती है।
    एक बार फिर शानदार लेख के लिए धन्यवाद, और मैं टिप्पणियाँ पढ़ना जारी रखे हुए हूँ
    पिछली संबंधित चर्चा
    पेपर का पूरा पाठ
    • मेरी एक व्यक्तिगत जिज्ञासा है: अध्ययन में AI इस्तेमाल करने से पहले और बाद में वास्तविक समय में कितना अंतर आया, इसे भरोसेमंद तरीके से कैसे मापा गया? क्या डेवलपर्स से पहले यह अनुमान लगवाया गया कि AI इस्तेमाल करने के बाद कितना समय बचेगा, और फिर वास्तविक उपयोग समय मापकर अंतर देखा गया? और जब किसी issue की कठिनाई या उसके समाधान में लगने वाले समय का अनुमान लगाना मुश्किल हो, तो रिसर्च टीम ने उसे किस तरह नियंत्रित किया? मैं मानता हूँ कि इस तरह का मापन सचमुच बहुत जटिल है
    • मैं नतीजों से सहमत हूँ और जवाब के लिए आभारी हूँ। शीर्षक बदलने की कोई योजना नहीं है क्योंकि मुझे थोड़ा radical style पसंद है, लेकिन लेख में यह साफ़ तौर पर सुधार दूँगा कि यह गलत phrasing है। मैंने अपने लेख में भी यह स्पष्ट किया था कि शोध के मुख्य योगदान करने वाले factors — “repository से डेवलपर की बहुत अधिक परिचितता”, “बड़ी और जटिल repository”, “implicit repository context” — शोध के निष्कर्षों से मेल खाते हैं। मैं खुद पर भी ऐसा प्रयोग चलाना चाहता हूँ, लेकिन काम की ज़रूरतों के साथ controlled environment बनाना बहुत मुश्किल लगता है। कम समय में पूरे हो सकने वाले स्पष्ट tasks की सूची भी कम है
    • अगर किसी ऐसे project में, जिसे आप अच्छी तरह जानते हैं, अपने optimized workflow में बदलाव किया जाए, तो शुरुआत में धीमा पड़ना अपेक्षित है। असली बात यह देखना है कि 6 महीने या 1 साल बाद ऐसे डेवलपर्स कहाँ होते हैं। यह अध्ययन दीर्घकालिक रुझान नहीं दिखाता, इसलिए उम्मीद है कि भविष्य के शोध में यह पता चलेगा कि वही डेवलपर tool के अभ्यस्त होने के बाद कैसे perform करते हैं। मैंने भी अनुभव किया है कि AI की मदद से ऐसे कई काम scripts में बदले जा सकते हैं जिन्हें पहले automate करना मुश्किल था। हमेशा यह सवाल रहना चाहिए: “क्या यह समय के हिसाब से वाकई लाभकारी है?”
      xkcd time management comic
    • यह भी कहा गया कि “2025 की शुरुआत में AI अनुभवी open source डेवलपर्स को धीमा करता है” भी कुछ ज़्यादा सामान्यीकृत कथन है। कुछ खास tasks में AI समय बचा सकता है, इसलिए असर task पर निर्भर करता है
    • धीमा होना ज़रूरी नहीं कि बुरा ही हो; मेरा मानना है कि slow programming (literate programming/Knuth style) सैद्धांतिक समझ बनाने में उल्टा अधिक मददगार हो सकती है। fast-food style programming के बजाय, पर्याप्त सोच और abstraction के साथ धीमा development महत्वपूर्ण है — यह तर्क भी दिया जा सकता है
  • मैं इस बात से सहमत हूँ कि “डेवलपर यह पहचान नहीं पाता कि कोई tool वास्तव में उसे तेज़ बना रहा है या धीमा।” एक उदाहरण नाव का दिया गया, जो हवा और धारा के कारण लक्ष्य से भटक जाती है; मतलब यह कि हम अक्सर सिर्फ अपने आसपास की तत्काल movement के आधार पर progress महसूस करते हैं, लेकिन क्या हम सच में लक्ष्य की ओर बढ़ रहे हैं, इसका सहज अंदाज़ा लगाना मुश्किल होता है। इसलिए लोग अक्सर ऐसी रणनीति चुनते हैं जो “प्रगति का एहसास” दे, जबकि वह वास्तव में अक्षम या धीमा रास्ता हो सकता है (जैसे गाड़ी चलाते समय बार-बार right turn लेना)
    • जब मैंने पहली बार AI tools इस्तेमाल किए, तो बिना अटकाव के काम चलता रहने का एहसास अच्छा लगा। लेकिन कई बार ऐसा हुआ कि वास्तव में खुद एक लाइन बदलना ज़्यादा तेज़ होता, फिर भी आदत से AI को ही बुला लिया। यह driving वाले उदाहरण जैसा है — जैसे GPS किसी एक रास्ते में जाम लगने पर बार-बार आपको उसी मूल route की तरफ़ वापस भेजता रहे
    • यह Waze जैसे navigation apps जैसा है, जो कभी-कभी वास्तव में लंबा route बताते हैं, लेकिन उलझे हुए detours के कारण ऐसा महसूस कराते हैं कि आप “लगातार आगे बढ़ रहे हैं,” इसलिए वह तेज़ लगने लगता है। AI tools भी programming को आसान महसूस करा सकते हैं, जबकि वास्तविक productivity घट रही हो। इंसान अक्सर बिना दर्द वाली short-term experience को ही याद रखता है, और क्योंकि चीज़ कठिन नहीं लगी, उसे प्रगति मान लेता है
    • आखिरकार इंसान स्वाभाविक रूप से greedy algorithm को पसंद करता है
    • Linux/Unix users मानते हैं कि keyboard control और CLI tools सबसे अधिक efficient हैं, लेकिन शोध बताते हैं कि अधिकतर कामों में mouse तेज़ होता है। keyboard input तेज़ लगने की एक वजह यह है कि उसमें प्रति सेकंड actions ज़्यादा होते हैं
    • AI से बना code लगभग review ही नहीं होता, और बहुत से डेवलपर्स code review को ही इतना कठिन मानते हैं कि पढ़ने से बचते हैं। इसी वजह से नए frameworks या code rewrite लोकप्रिय हो जाते हैं
      Joel on Software: Things you should never do, part I
      AI से बना बहुत-सा code बस तैयार कर दिया जाता है, थोड़ा-बहुत simple testing कर ली जाती है, और बात वहीं खत्म हो जाती है। यहाँ तक कि ऐसा भी बहुत code बढ़ रहा है जिसे लेखक खुद भी उसके पूरे context या कारण के साथ पूरी तरह नहीं समझता
  • इस शोध का सार यह है कि “AI productivity में वास्तविकता से अधिक बढ़ोतरी का भ्रम पैदा करता है।” केवल कुछ प्रतिभागियों को productivity में हल्का सुधार मिला, जबकि अधिकांश की productivity काफ़ी घट गई। बहुत लोग कहते हैं कि AI की वजह से उनकी productivity विस्फोटक रूप से बढ़ गई है, लेकिन इस शोध की जो असली अंतर्दृष्टि है — कि वह प्रभाव खुद एक भ्रम हो सकता है — उसे नज़रअंदाज़ किया जा रहा है। AI ऐसा उत्पाद है जिसे इस तरह optimize किया गया है कि उपयोगकर्ता को लगे कि उसे यह उपयोग करना चाहिए, कि यह उपयोगी है। व्यक्तिगत value तो perceived reality ही होती है, इसलिए उस पर शक नहीं, लेकिन जो लोग AI पर बहुत अधिक निर्भर हैं उन्हें self-awareness के distortion, नकली उपलब्धि-भाव, और tool dependency से सचमुच सावधान रहना चाहिए। AI भले ही optimized token stream के रूप में जवाब देता हो, लेकिन असली optimization target क्या है, यह सवाल कभी-कभी ज़रूर पूछना चाहिए
    • LLM कुछ सीखने में मददगार होता है, लेकिन उससे बनने वाली समझ बहुत abstract और कुछ हद तक LLM-जैसी हो जाती है। सीखने के लिए अलग-अलग तरीकों को मिलाना बेहतर है
    • AI tools डेवलपर को “तेज़” से ज़्यादा “क्षणिक रूप से फुर्तीला” महसूस कराते हैं। इसमें दिमाग़ पर बोझ कम होने का एक भ्रम है; अलग feedback loops में एहसास बदल जाता है और memory formation के तरीके भी बदलते हैं, इसलिए यह एक दिलचस्प illusion बन जाता है
  • जब “अनुभवी open source डेवलपर्स अपने ही project पर AI इस्तेमाल करने पर धीमे पड़ जाते हैं” वाले अध्ययन पर चर्चा चल रही थी, उसी दौरान मैं एक पूरी तरह दूसरे व्यक्ति के बनाए 3 महीने पुराने codebase और एक अपरिचित framework पर काम कर रहा था। लेकिन Claude Code की मदद से मैंने कुछ ही घंटों में वह काम कर लिया — जैसे data synchronization — जिसमें मेरे पिछले projects में 1–2 दिन, और कभी-कभी 2 हफ्ते तक लग जाते थे। यह जबरदस्त jump-start था। जटिलता बढ़ने पर चीज़ें शायद धीमी होंगी, लेकिन यह देखकर हैरानी हुई कि tool की मदद से शुरुआत कितनी तेज़ हुई
    • मेरा भी ऐसा ही अनुभव रहा है, लेकिन यह अध्ययन उस ramp-up phase के बारे में नहीं है जिससे हम गुज़रे, बल्कि उन open source डेवलपर्स के बारे में है जो पहले से ही अपने projects से बहुत परिचित थे और AI के साथ tasks कर रहे थे। LLM नया codebase समझने की प्रक्रिया निश्चित रूप से तेज़ करता है, लेकिन एक बार परिचित हो जाने के बाद यह उल्टा बाधा बन सकता है — ऐसा मेरा अनुभव है
    • “2 हफ्ते का PR कुछ घंटों में” वाली productivity वाली बात अक्सर सुनने को मिलती है, लेकिन असल में हम development duration का अनुमान कितनी सटीकता से लगाते हैं, इसकी जाँच शायद ही कभी होती है। और यह भी देखना चाहिए कि ऐसे जल्दी निकाले गए PR की quality वैसी ही थी या नहीं जैसा मूल अनुमान था, या सिर्फ़ जल्दी करने के चक्कर में महत्वपूर्ण system context छोड़ दिया गया, जिससे bugs की संभावना बढ़ गई। AI के बिना भी quality से समझौता करके तेज़ हुआ जा सकता है
    • यह भी सवाल है कि AI की मदद से codebase और system की औसत mastery स्वाभाविक रूप से बढ़ती भी है या नहीं। LLM इस्तेमाल करने का learning effect कुछ वैसा लगता है जैसे किसी नई भाषा को पढ़ना तो आ जाए, लेकिन शुरू से खुद लिखना मुश्किल रहे। C++ का उदाहरण लें तो existing code पढ़ना और उसमें बदलाव करना संभव है, लेकिन शुरुआत से नया बनाना कठिन लगता है
    • AI tools की वजह से मुझे बस एक बहुत बड़ा jump-start मिला — मेरा उद्देश्य शोध, लेख या पेपर की आलोचना करना नहीं था, बल्कि सिर्फ़ यह कहना था कि कुछ खास contexts में AI सचमुच बहुत मददगार है। यह सिर्फ code लिखने तक सीमित नहीं है; उदाहरण के लिए Claude Code ने project के अंदर container से सीधे AWS cluster connection तक की कोशिश की, जिससे पूरी infra और structure समझने में बहुत मदद मिली। मेरे अनुभव में 80–90% मामलों में code quality से अधिक “business value” को प्राथमिकता मिलती है। जहाँ code quality वास्तव में महत्वपूर्ण हो, या खास algorithms, data structures की ज़रूरत हो, वहाँ यह कितना उपयोगी होगा, मैं नहीं जानता। लेकिन अच्छे examples और स्पष्ट context दिया जाए तो यह काफ़ी काम का code लिख सकता है — ऐसा अनुभव रहा। tools हर हफ्ते या हर महीने तेज़ी से बेहतर हो रहे हैं। आखिरकार AI कोई जादू नहीं, एक tool है, और product/result की जिम्मेदारी अंततः मेरी ही है
    • यह ध्यान रखना चाहिए कि पेपर (TFA) का मामला ऐसे projects का है जिनसे लोग पहले से बहुत परिचित थे। मेरा अनुभव ठीक उल्टा था: AI अपरिचित परिस्थितियों में ज़्यादा चमका
  • “AI agentic tools (Claude Code, Amp, Gemini CLI आदि) programming में वैसे हैं जैसे woodworking में table saw” — इस तुलना को उद्धृत करते हुए कहा गया कि अगर आप इसका इस्तेमाल सीख लें, तो कुछ काम तेज़ और बेहतर हो सकते हैं, लेकिन अगर परिचित न हों तो उँगली भी कट सकती है। मेरे लिए agentic AI की वजह से मैं पहले से अधिक ambitious projects हाथ में ले पाता हूँ, और जो काम नीरस या दोहराव वाले होते हैं, उन्हें AI को सौंपकर सोचने की जगह मिलती है। दूसरी तरफ़, AI को सब कुछ अपने आप करने देकर बिना समझे commit कर देना ठीक नहीं। tool की तरह इसका बेहतर उपयोग सीखने की मेहनत करनी होगी
    • मुझे table saw वाली उपमा जँचती नहीं। table saw, hand tools की तुलना में एक precise tool है, जबकि agentic AI precision से काफ़ी दूर है
    • “आप AI को गलत तरीके से इस्तेमाल कर रहे हैं” वाला तर्क उन डेवलपर्स का अपमान है जिन्होंने AI के आने से पहले ही पूरे open source stack खड़े किए थे। और अभी तक ऐसा कोई सबूत नहीं है कि AI की मदद से वास्तव में मूल्यवान software बनाया गया हो
  • इस अध्ययन में 50 घंटे से अधिक Cursor अनुभव वाले डेवलपर (जिसमें study participation time भी शामिल है) सिर्फ़ एक थे, और इसी डेवलपर ने 25% तेजी का अनुभव किया। बाकी सभी मूलतः नए थे, और नए tool के साथ नए उपयोगकर्ता का धीमा होना बिल्कुल स्वाभाविक है। मुझे नहीं लगता कि सिर्फ़ इस अध्ययन से AI productivity पर ठोस निष्कर्ष निकाला जा सकता है
    • पेपर की details देखें तो इससे पहले के अध्ययनों में, जहाँ tools का अनुभव इससे मिलता-जुलता या उससे भी कम था, उल्टा speed-up report हुआ था। ज़्यादातर लोगों के पास LLM prompting का पर्याप्त अनुभव था, और खास तौर पर Cursor का VSCode से मिलता-जुलता होना भी ध्यान देने योग्य है, इसलिए अलग learning curve बहुत बड़ी नहीं थी। अगर सभी डेवलपर्स AI tools के इतने अभ्यस्त हो जाएँ कि AI के बिना काम करते समय उनकी क्षमता और गिर जाए, तो संभव है कि AI के साथ उनकी performance बेहतर दिखे, क्योंकि baseline ही नीचे चला गया होगा। कौन-सा tool इस्तेमाल हुआ, यह उतना महत्वपूर्ण नहीं; असली बात यह है कि productivity की self-report वास्तविकता की तुलना में अत्यधिक आशावादी थी। वास्तविक प्रभाव समझने के लिए ठोस measurements चाहिए
      (इस पर पेपर के C.2.7 “Below-average use of AI tools” सेक्शन में अधिक विस्तार से चर्चा है)
    • जो डेवलपर्स लंबे समय से अपना IDE (Vim/Neovim आदि) इस्तेमाल करते आए हैं, उनके लिए Cursor जैसे नए tool पर switch करने से productivity कई महीनों तक काफ़ी गिर सकती है
    • मैं भी यही मानता हूँ। अपरिचित tools इस्तेमाल करने वाला डेवलपर धीमा होगा ही। AI भी इसका अपवाद नहीं है
  • मैं फिलहाल Burn (Rust-आधारित deep learning framework) का नियमित code reviewer हूँ। हाल में मुझे एक bugfix PR बंद करना पड़ा जो लगभग पूरी तरह AI agent द्वारा लिखा हुआ लगा। उस PR ने समस्या की जड़ हल करने के बजाय error को बस ignore कर दिया था, बेवजह लंबा सफ़ाईनुमा code जोड़ दिया था, और error ignore करने के tests भी शामिल कर दिए थे। यह सब commit history भरने जैसी गतिविधि लगा। AI के ऐसे दुरुपयोग का फैलता रुझान चिंताजनक है
    • यह अजीब लगता है कि जब LLM को सही जवाब नहीं पता होता, तो वह बेहूदा जवाब दे देता है, और जब आप कहते हैं कि यह गलत है, तो वह “हाँ, सही कहा, मैं इसे फिर से ठीक करता हूँ” जैसी प्रतिक्रिया देता है। मुझे डर है कि अनुभवहीन लोग issues को अलग-अलग पहचान नहीं पाएँगे, या धीरे-धीरे code की परवाह ही कम करने लगेंगे। यह भी चिंता है कि गंभीर vulnerabilities और abuse cases की बाढ़ आ सकती है
    • एक सहकर्मी के MR की review करते समय मुझे test cases साफ़ तौर पर AI-generated लगे — जैसे thing1, thing2 जैसे नाम, बस variable बदलते गए और बाकी सब एक जैसा। मैंने feedback में कहा कि नाम अधिक distinguishable होने चाहिए, तो इस बार AI ने हर case की विशेषता पूरी गिनाने वाले बेहद लंबे variable names बना दिए, जिसके कारण code एक नज़र में समझना और कठिन हो गया। लेखक को लगा होगा कि उसकी writing speed बहुत बढ़ गई, लेकिन असल में feedback, review और fixes में समय लग गया, और productivity gain पूरी तरह खत्म हो गया
    • एक हल्की-फुल्की राय यह भी थी: “Rust में deep learning framework → AI से जुड़ा दुष्चक्र”
    • commit logs भरने के लिए AI का इस्तेमाल होने का माहौल तो काफ़ी पहले से मौजूद है। AI बस साधारण spam बनाना भी आसान कर देता है
      संदर्भ: बहुत पुराना AI spam issue
    • यह भी कहा गया कि LLM try:catch blocks को बहुत चौड़ा कर देता है, जिससे समस्या के source को trace करना कठिन हो जाता है। मैं चाहता हूँ कि समस्या जल्दी और ज़ोर से सामने आए (=fail fast), ताकि उसे तुरंत ठीक किया जा सके
  • मेरा निजी अनुभव यह है कि AI programming में focus flow बार-बार टूटता है और थकान जल्दी होती है। यह मिथक है कि coding पूरे दिन लगातार होती है; आम तौर पर 1–3 घंटे की गहरी concentration होती है, बीच-बीच में breaks के साथ। यहाँ तक कि सहकर्मी के code या changes पढ़ने का समय भी दिन की progress में गिना जाता है, जबकि वास्तविक प्रगति अक्सर कम होती है। agentic AI (जैसे छोटे code refactoring) उपयोगी हो सकता है, लेकिन बड़ा productivity boost कम ही दिखता है। code autocomplete (जैसे शुरुआती Copilot) तो कई बार बेकार noise ज़्यादा पैदा करता है
    • अगर कोई सचमुच रिकॉर्ड करे कि दिन भर में उसने क्या-क्या किया, तो नतीजा काफ़ी उदास करने वाला हो सकता है। खासकर mature codebases में, एक घंटे का पूरा focus भी शायद बढ़ा-चढ़ाकर कहा गया आँकड़ा हो
  • किसी अपरिचित codebase में tricky bug (जैसे race condition) debug करते समय logging जोड़ना, library functions बदलना, structure सुधारना आदि ज़रूरी होते हैं। ऐसे में अगर AI सिर्फ़ यह कहे कि “यहाँ race condition है और इसे ऐसे ठीक कर दो,” तो short-term में भले जल्दी समाधान मिल जाए, लेकिन code structure और logic की समझ को नुकसान पहुँच सकता है। लंबी अवधि में अगर AI-driven code editing लगातार चलती रही, तो code इतना बिगड़ सकता है कि आगे चलकर AI भी उस पर सही तरह से प्रतिक्रिया न दे पाए
    • जब भी मैं सुनता हूँ कि “मैंने AI की मदद से ऐसी भाषा या codebase में योगदान दिया जिसे मैं जानता नहीं था,” तो short-term में यह ठीक लग सकता है, लेकिन मैं पूछना चाहता हूँ कि वास्तव में आपने सीखा क्या? छोटे कामों के लिए ऐसी contribution उपयोगी हो सकती है, लेकिन लंबे समय की maintenance पर बहुत कम अनुभव-कथाएँ सुनाई देती हैं
  • हाल में AI tools का सक्रिय रूप से उपयोग करने वाले अपने पहले project का retrospective साझा करते हुए मेरा निष्कर्ष यह है: 1) speed नहीं बढ़ी, 2) संभव है कि मैं और धीमा हो गया, 3) लेकिन output की quality बेहतर हुई। धीमापन और quality improvement आपस में जुड़े हुए थे, क्योंकि मैंने AI का उपयोग मुख्यतः idea validation, alternatives explore करने और सहायक माध्यम के रूप में किया। AI की वजह से अपरिचित क्षेत्रों में सीखने का अनुभव अच्छा रहा, और अपने मुख्य क्षेत्र में भी मैंने अपनी या AI की ideas को refine किया, जिससे अंततः quality बेहतर हुई। सिर्फ speed ही सब कुछ नहीं है; quality को quantify करना मुश्किल ज़रूर है, लेकिन फिर भी मुझे यह काफ़ी valuable लगा
    • क्योंकि AI quality improvement में भी मदद कर सकता है, इसलिए आजकल मैं ऐसे AI को पसंद करता हूँ जो assertive हो और हर बात पर अंधाधुंध सहमति न दे। अगर AI से ideas माँगकर मैं कहूँ कि उन पर हमला करो, या मेरी ideas की कमज़ोरियाँ ढूँढने में मदद करो, तो वह काफ़ी productive होता है। भले मैं सब लागू न करूँ, लेकिन यह मुझे कई ऐसे angles सोचने देता है जो पहले ध्यान में नहीं आते। व्यावहारिक रूप से यह कुछ वैसा अनुभव है जैसे domain की पर्याप्त समझ रखने वाले किसी सहकर्मी के साथ चर्चा करना
 
eususu 2025-07-15

मेरे मन में भी कुछ ऐसा ही विचार था, लेकिन उसे शब्दों में व्यक्त करना थोड़ा मुश्किल था.
मेंटल मॉडल इसके लिए काफ़ी उपयुक्त नाम है. लगता है, इसे अक्सर इस्तेमाल करना पड़ेगा.