AI डेवलपर्स को मूर्ख बना रहा है

• यह सच है कि LLM tools डेवलपर उत्पादकता बढ़ाते हैं
• लेकिन लंबे समय में इन tools पर निर्भरता बढ़ने से खुद समस्याएँ हल करने की क्षमता कमजोर हो जाती है
• code लिखने की प्रक्रिया से मिलने वाला संतोष कम हो जाता है, और समस्या हल करने के बजाय AI के जवाब का इंतज़ार होने लगता है

डेवलपमेंट के प्रति जुनून और चुनौती लेने की भावना का कमजोर होना

• कुछ लोग coding का आनंद ही नहीं लेते → ऐसे मामलों में हो सकता है कि development field उनके लिए सही न हो
• जिन बेहतरीन engineers से मैं मिला हूँ, वे weekend पर भी अपनी इच्छा से tools या software बनाते हैं और innovation का पीछा करते हैं
• system performance में सुधार के लिए बुनियादी समझ ज़रूरी है, वरना वह सिर्फ़ बिना दिशा के कोशिशें बनकर रह जाता है

'Copilot Lag' घटना

• 'Copilot Lag' का मतलब है AI के अगले निर्देश का इंतज़ार करने वाली अवस्था
• यह कुछ वैसा है जैसे कोई junior developer अपने senior के निर्देश का इंतज़ार करे
• GitHub Copilot इस्तेमाल करते-करते बुनियादी language elements और syntax तक भूलने लगते हैं
• अल्पकालिक speed gain की वजह से दीर्घकालिक knowledge कमजोर पड़ जाती है

LLM सीखने की प्रक्रिया में बाधा बन सकता है

• Thorsten Ball की "Writing An Interpreter In Go" पढ़ते समय Copilot ने code generate करके दिया, लेकिन उसे खुद दोबारा लिख पाने की क्षमता नहीं बन पाई
• memory management या data-oriented design जैसे महत्वपूर्ण concepts छूट सकते हैं
• AI द्वारा बनाया गया code ऊपर से सही लग सकता है, लेकिन अगर मूल सिद्धांत समझ में न आएँ तो उसका कोई अर्थ नहीं

LLM का प्रभावी उपयोग कैसे करें

• LLM को search engine की तरह उपयोगी ढंग से इस्तेमाल किया जा सकता है
• जैसे Stack Overflow search करते हैं, वैसे ही LLM के जवाबों को reference के तौर पर देखा जा सकता है
• लेकिन LLM असली experts के ज्ञान को ज्यों का त्यों नहीं दर्शाता; वह सीखे हुए patterns और token sequences के आधार पर जवाब बनाता है → इसलिए गलतियाँ बहुत होती हैं
• LLM के जवाब को सीधे स्वीकार न करें, बल्कि यह विश्लेषण करें कि वह यह approach क्यों सुझा रहा है
• जब कुछ पता न हो, तो खुद जाँचें और सीखें
• नई language (Zig आदि) सीखते समय सीखी गई बातों के notes बनाना उपयोगी होता है
• notes सीखने के reference material बन सकते हैं, और दूसरों के साथ share करने में भी मदद करते हैं

निष्कर्ष

• AI tools उपयोगी हैं, लेकिन उन पर आँख बंद करके निर्भर रहने से उल्टा नुकसान हो सकता है
• AI द्वारा सुझाए गए समाधान के सिद्धांत को समझना और खुद सीखने की मानसिकता रखना महत्वपूर्ण है
• आखिरकार सबसे महत्वपूर्ण बात यह है कि tools पर निर्भर हुए बिना बुनियादी problem-solving क्षमता को बनाए रखा जाए

[madnix]

हम्म... मुझे लगता है कि शुरुआत से ही फर्क इस बात के नज़रिए का है कि AI को एक tool माना जाए या intelligence। मैं इस लेख से सहमत नहीं हो सकता, क्योंकि जैसा कि नीचे की टिप्पणी में कहा गया है, developer को सिर्फ code level पर देखना ही अपने-आप में गलत सोच है। अतीत में जब ब्रिटेन में Industrial Revolution हुआ था, तब किसानों ने भी शोर मचाया था कि हम भूखे मर जाएंगे, लेकिन नतीजे में उससे और ज़्यादा नौकरियाँ पैदा हुईं और मानवता को बहुत लाभ मिला। इसी तरह, जब पहले computer आए थे, तब भी कहा जाता था कि computer की वजह से लोग धीरे-धीरे मूर्ख हो जाएंगे, लेकिन नतीजा यह हुआ कि ज़्यादा काम कम समय में हल होने लगे और लोग और ज़्यादा smart हो गए।

[jokerized]

अभी भी high-level problem solving के लिए, deep research सहित LLMs उपयोगी नहीं हैं। (उदाहरण के लिए, paper-level algorithm development)
अत्यधिक optimization, और ऐसी coding जिसमें विभिन्न system characteristics और technical issues को समझना ज़रूरी हो, उनमें भी अभी इंसानी हाथ की ज़रूरत है। डेवलपर सिर्फ साधारण programmer नहीं, बल्कि problem solver है। कभी न कभी end-to-end problem solving भी संभव हो जाएगी, लेकिन अभी यह typing और simple programming में लगने वाला समय बचाकर ज़्यादा कठिन समस्याओं तक पहुँचने के तरीकों में निवेश करने देता है, इसलिए productivity के लिहाज़ से यह सकारात्मक लगता है।

[skarl86]

कब से ऐसा होने लगा, पता नहीं, लेकिन लगता है कि मैं इसे अक्सर code review जैसी अवधारणा की तरह इस्तेमाल कर रहा हूँ। मैं code के सुझाव लेता हूँ, code की दिशा पर बात करता हूँ, बेहतर तरीकों पर सोचकर सुझाव देता हूँ, और जब मुझे संतोषजनक नतीजा मिलता है तो उसे अपनाता हूँ।

[kaydash]

पूरे application logic और business logic के बारे में इंसानों को ही सोचना चाहिए।

[elbanic]

अगर डेवलपर्स को सिर्फ कोडिंग तक सीमित कर दिया जाए, तो ऐसी चिंता सामने आती है। असल में डेवलपर्स इससे कहीं ज़्यादा काम करते हैं; कोडिंग वाले हिस्से के लिए AI पर निर्भर होने को कोई उन्हें बेवकूफ बनना मान सकता है, लेकिन इसे इस तरह भी देखा जा सकता है कि इससे वे दूसरे हिस्सों पर ज़्यादा ध्यान दे पाते हैं।

[pcj9024]

द्यु-द्या-ई... मैं एक बेवकूफ डेवलपर हूँ...

[dongyagn1]

Unity के बारे में भी कहा जाता था कि वह game developers को बेवकूफ़ बना देता है, लेकिन कोई भी बेवकूफ़ नहीं बना; उल्टा सबने और भी बहुत कुछ सीखा और बस काम ही बढ़ गया lol

[halfenif]

काम ही और बढ़ गया... ये कैसे हो गया..

[nimgnos]

यह कहना कि यह डेवलपर्स को बेवकूफ बना रहा है... इससे सहमत होना मुश्किल है.
AI अपनाने के बाद प्रोडक्टिविटी सच में बहुत तेज़ी से बढ़ी है।

[vhzkfltmdnpxm]

यहाँ एक बेवकूफ़ है

[alpharoom]

आजकल ऐसा माहौल है कि अगर आप इस बात से सहमत न हों कि आजकल AI से सब कुछ किया जा सकता है, तो लोग आपको बुरा-भला कहने लगते हैं।

[play1204dev]

अगर बात ऐसी लाइब्रेरी फीचर्स की हो जिनके बारे में पता नहीं था, या ऐसे shell scripts की जो तुरंत याद नहीं आते, तो ठीक है। लेकिन इनमें पहले से deprecated हो चुके फीचर्स या मौजूद ही नहीं होने वाले functions भी मिल जाते हैं, और फिर debugging में सारा समय निकल जाता है.

> LLM के जवाब को ज्यों का त्यों स्वीकार नहीं करना चाहिए; यह भी समझना चाहिए कि वह उस तरह का approach क्यों सुझा रहा है.

मुझे लगता है, यही बात सबसे अहम है.

[dongwon]

मुझे लगता है कि टूल हमेशा सोच का विस्तार भी लाते हैं और साथ ही सोच को तोड़ते भी हैं। सोच के इस विघटन के ज़रिए हमें उच्च-स्तरीय सोच के विस्तार की ओर बढ़ पाना चाहिए, लेकिन जब ऐसी तैयारी नहीं होती, तब इस तरह की समस्याएँ हमेशा साथ आती दिखती हैं.

इसलिए, आखिरकार टूल के इस्तेमाल के साथ इस तरह की चिंताएँ हमेशा जुड़ी रहती हैं। मुझे लगता है कि ये एकदम ज़रूरी प्रक्रियाएँ हैं। बस इसे ठुकरा देना या अंधाधुंध इस्तेमाल करना सही नहीं है; बल्कि यह सोचना बेहतर है कि इस टूल का अच्छा उपयोग कैसे किया जाए, और ऐसे टूल की मदद से मूल रूप से अधिक महत्वपूर्ण हिस्सों पर resources कैसे लगाए जा सकते हैं। मेरा मानना है कि इसी फ़ोकस के साथ इसका इस्तेमाल करना उचित है.
(cursor का usage महीने में 1,000 बार से ऊपर जाते हुए...)

[amarese]

श्री किम। मैं हिम्मत करके एक सलाह देना चाहता हूँ। और कुछ नहीं, बस Excel function? का बहुत ज़्यादा इस्तेमाल मत कीजिए। अगर सुविधा है, तो जोखिम भी बढ़ता है। गाय को काटने के लिए वैसी ही धार होती है, लेकिन मुर्गी काटने के लिए क्या सच में चाकू चाहिए? आसान तरीका ही सही जवाब हो सकता है।

[codemasterkimc]

ऊपर वाला लेख तो Excel function के GPT version जैसा है lol

[losoowmik]

मेरी राय में मानसिक गणना तेज़ हो सकती है, और calculator उपयोगी हो सकता है। कंप्यूटर तो क्या मवेशी काटने वाली छुरी जैसा औज़ार नहीं है, यही कहना चाहता हूँ.

[jingjing2222]

मैं अब फिर कभी chatGPT का इस्तेमाल नहीं करूँगा
मैंने भी इसी तरह की एक पोस्ट लिखी थी।

यह साफ़ है कि productivity बढ़ती है, लेकिन मेरा मानना है कि अपने दिमाग़ को पूरी तरह इसके हवाले कर देने जैसी आदत से बचना चाहिए।

[dicebattle]

मैं अब भी Cursor और Anthropic का बड़ा समर्थक हूँ, लेकिन किसी बिंदु पर मैंने देखा कि जिस agent mode को लेकर मैं बहुत उत्साहित था, उसे धीरे-धीरे कम इस्तेमाल कर रहा हूँ। अब मैं पहले ask mode में architecture और implementation method के बारे में पूछता हूँ, और जब पूरी तरह आश्वस्त हो जाता हूँ तभी AI के change suggestions को एक-एक करके स्वीकार करता हूँ।
ऐसा इसलिए बदला, क्योंकि बहुत बड़ा नहीं होने वाला एक मॉड्यूल — लेकिन हमारे काम के project में काफ़ी महत्वपूर्ण — को 2 engineers ने अपने-अपने agent mode का इस्तेमाल करके refactor किया और उसमें नई संरचना जोड़ी, और फिर एक समय ऐसा आया जब architecture को व्यवस्थित करने के इरादे से लिखा गया code वास्तव में readability और structure दोनों को और ज़्यादा खराब कर बैठा।

[onixboox]

मैं भी इसे ऐसे ही इस्तेमाल करता हूँ। अगर कोई भाषा सचमुच पूरी तरह नई हो, तो मैं agent mode इस्तेमाल करता हूँ, लेकिन अगर भाषा जानी-पहचानी हो, तो पहले यह देखता हूँ कि कोड तर्कसंगत है या नहीं।

[iolothebard]

AI डेवलपर्स को बेवकूफ़ बना रहा है, ऐसा कहने से ज़्यादा…
बेवकूफ़ डेवलपर, AI इस्तेमाल करके भी बेवकूफ़ डेवलपर ही रहता है…
Garbage in Garbage out

[ehdgns104]

बिल्कुल सही कहा आपने lol

[powerkid]

मैं सहमत हूँ। यह न तो पूरी तरह बुरी चीज़ है और न ही पूरी तरह अच्छी, बल्कि लगता है कि यह बस एक और उपयोगी productivity tool जुड़ गया है।

[halfenif]

मैं सहमत हूँ।

मैं पहले से ही अक्सर कहता आया हूँ कि डेवलपर कहलाने वाले सभी लोग एक जैसे डेवलपर नहीं होते।

[aer0700]

लगता है यह बात सही है...

[white9s]

कहने का अंदाज़ भले ही थोड़ा सख्त है, लेकिन बात पूरी तरह गलत भी नहीं है। जैसे कि अच्छे सवालों से अच्छे जवाब निकलते हैं, उसी तरह...

[j2sus91]

मुझे लगता है कि लेखक अंधाधुंध सिर्फ़ AI टूल्स पर निर्भर होकर उनका इस्तेमाल करने की बात कर रहे थे।

मेरी व्यक्तिगत राय यह है कि अगर AI के उपयोग से काम की दक्षता बढ़ी है,
तो उसका सक्रिय रूप से इस्तेमाल करके दोहराए जाने वाले कामों को कम करना,
और इस तरह मिले समय को बड़े दायरे वाले क्षेत्रों में (जैसे: backend डेवलपर का frontend या app development तक विस्तार)
या architecture design जैसी अधिक विकासोन्मुख दिशा में लगाना बेहतर होगा।

पूरे लेख की बात देखें तो लगता है कि लेखक भी इस राय से सहमत होंगे,
लेकिन कभी-कभी ऐसे डेवलपर्स भी होते हैं जो AI को ही पूरी तरह नकार देते हैं, इसलिए कुछ पंक्तियाँ जवाब में लिख दीं.. हा हा
.

[tsboard]

मैं भी सहमत हूँ। यह पढ़कर वह लेख याद आ गया जिसमें कहा गया था कि Excel के function इस्तेमाल नहीं करने चाहिए।
मुझे लगता है कि जो फीचर्स मौजूद हैं, उनका अच्छी तरह उपयोग करके उनकी उपयोगिता और बढ़ा दी जाए तो वही फ़ायदेमंद है.

[zinisuni]

सहमत हूँ. ^^

[GN⁺]

Hacker News की राय

• कुछ लोगों को अपना कोड लिखना पसंद नहीं हो सकता। उस स्थिति में, इसे ऐसे देखा जा सकता है कि वे ऐसे क्षेत्र में काम करने की कोशिश कर रहे हैं जो उनके लिए उपयुक्त नहीं है
  • मैंने दशकों तक अपना कोड खुद लिखना झेला है। कभी-कभी यह संतोषजनक होता है, लेकिन ज़्यादातर यह मेरे आइडिया और मेरे बीच की एक abstraction है
  • मुझे तेज़ी से कुछ बनाना पसंद है, और जब मेरे पास कोई आइडिया हो तो मैं चाहता हूँ कि उसे जितना संभव हो उतना efficient और साफ़-सुथरे तरीके से implement किया जाए
  • मैंने LLMs के साथ काम करना स्वीकार कर लिया है। मुझे नहीं लगता कि इससे मैं ज़्यादा आलसी हुआ हूँ
  • बल्कि, जब मैं अटक जाता हूँ तो यह मुझे शुरू करने की प्रेरणा देता है। LLM काम शुरू कर देता है, फिर मैं उसे अपने तरीके से आगे बढ़ाकर पूरा करता हूँ
  • मैं पहले से ज़्यादा उत्पाद बना रहा हूँ
  • मैंने लोगों के साथ काम किया है, और उनमें से कुछ मेरे दोस्त हैं। वे सोचते हैं कि उनका कोड और methodology पवित्र है
  • मुझे लगता है कि AI के आने पर उनके लिए जगह नहीं बचेगी। मैं इस खेल में creativity के लिए आया था, और यही वजह है कि मैं यहाँ हूँ
  • tools और syntax सिर्फ़ लक्ष्य तक पहुँचने के साधन हैं
  • हर बार जब abstraction की कोई नई layer विकसित होती है, जिससे नीचे की layer को समझे बिना काम करने वाला कोड आसानी से लिखा जा सके, तब यही बात दोहराई जाती है
  • abstraction लगभग हमेशा leak करती है। कभी-कभी यह जानना ज़रूरी होता है कि नीचे की layer वास्तव में कैसे काम करती है
  • जिन developers ने नीचे की layers को समझने में बहुत समय और भावनात्मक ऊर्जा लगाई है, वे दावा करते हैं कि abstraction पर निर्भर लोग ज़्यादा मूर्ख हैं
  • अगर हम सभी third-party libraries पर निर्भर हुए बिना अपना कोड खुद लिखें, तो हम और स्मार्ट हो जाएँगे
  • अगर हम memory को manually manage करें, तो हम और स्मार्ट हो जाएँगे
  • अगर हम सारा कोड assembly language में लिखें और compiler पर निर्भर न रहें, तो हम और स्मार्ट हो जाएँगे
  • अगर हम अपने transistor खुद wire करें, तो हम और स्मार्ट हो जाएँगे
  • नीचे की layers को सीखना शिक्षाप्रद है। अक्सर optimal performance निकालने के लिए इसकी ज़रूरत पड़ती है
  • लेकिन customers को value देने के लिए नीचे की layers को समझना ज़रूरी नहीं है
  • coding LLMs का उपयोग करके उस कोड को समझने में मदद माँगना, जिसे मैं अभी तक नहीं समझता, मुझे सबसे ज़्यादा पसंद है
  • जवाब ग़लत होने पर भी, वे अक्सर ऐसे hints दे देते हैं जिनसे मैं खुद समाधान तक पहुँच सकता हूँ
• मेरा भी कुछ ऐसा ही अनुभव रहा है। मैंने LLM का उपयोग करके features बनाए, लेकिन बाद में पता चला कि वह कोड पहले से मौजूद library से लिया गया था
  • अगर मैंने ठीक से research किया होता, तो मैं उसका कहीं ज़्यादा खराब version नहीं बनाता
  • अब मैं इसे सिर्फ़ comments के आधार पर editor में prototype features पाने के लिए इस्तेमाल करता हूँ, बाकी मैं खुद करता हूँ
  • AI pipeline सेट करना सारा मज़ा छीन लेता है और बहुत भारी काम जैसा लगता है
  • मैं तो उससे बेहतर coding करना पसंद करूँगा
  • जब LLM लगातार 2, 3, 4 बार ग़लत होता है, तो सचमुच गुस्सा उबलने लगता है
  • यह थका देने वाला हो जाता है
  • उम्मीद है कि अगले 1-2 साल में यह आसान होगा और UX बेहतर होगा, लेकिन पता नहीं क्या होगा
  • शायद मुझमें vision की कमी है
• LLMs छात्रों से तकनीकी समस्याओं को गहराई से समझने और ध्यान लगाकर सीखने की प्रेरणा छीन लेते हैं
  • उसकी जगह वे copy-paste करके बिना समझे आगे बढ़ जाते हैं
  • electronic calculator वाली तुलना सही हो सकती है। पहले हाथ से हिसाब लगाना सीखने के बाद ही वह सही tool बनता है
  • एक प्रयोग में business students को ChatGPT और data science assignments दिए गए
  • उन्होंने background knowledge के बिना solutions ढूँढ लिए, लेकिन ज्ञान हासिल नहीं किया
  • एक दोस्त ने कहा, "यह language model आम जनता को उपलब्ध नहीं कराया जाना चाहिए"
• पिछली नौकरी की एक निजी घटना
  • एक junior developer को ऐसे branches की सूची बनाने वाला script लिखने का काम दिया गया था जो लंबे समय से इस्तेमाल नहीं हुई थीं
  • review request आई, और उसका ज़्यादातर हिस्सा awk में लिखा था
  • उन्होंने task definition को LLM में डालकर जवाब copy किया और उसे pull request में paste कर दिया
• Plato, Phaedrus, 370 BC: "वे अब खुद याद नहीं रखेंगे, बल्कि बाहरी चिन्हों के सहारे स्मृति को जगाएँगे, इसलिए वे अपनी याददाश्त का उपयोग करना छोड़ देंगे"
• मैं पुराना खयालात वाला हो सकता हूँ, लेकिन मुझे वह समय याद है जब silent failure को उन सबसे बुरी चीज़ों में माना जाता था जो कोई system कर सकता है
  • LLMs silent failure machines हैं
  • वे अपनी जगह उपयोगी हैं, लेकिन जब किसी boss को यह सुनाई देता है कि मानवीय श्रम को AI से बदला जा रहा है, तो मुझे यक़ीन है कि वे अपने बुलाए हुए संकट का सामना करेंगे
• मैं software engineering में इसलिए आया क्योंकि मुझे कुछ बनाना और यह समझना पसंद है कि वह कैसे काम करता है
  • keyboard पर कोड लिखना सिर्फ़ तकनीक का एक side effect है
  • यह वैसा ही है जैसे कहना कि mathematician बनने के लिए whiteboard पर equations लिखना पसंद होना चाहिए
  • engineering में solution ढूँढना आम तौर पर अंतिम लक्ष्य होता है
  • जब हाथ से सब कुछ टाइप करना मूल्यवान हो, तो अच्छे engineer को हाथ से टाइप करना चाहिए
  • अगर third-party library import करना सबसे अच्छा विकल्प है, तो वही करना चाहिए
  • अगर LLM को coding का कुछ हिस्सा सौंपना सबसे आसान रास्ता है, तो वही करना चाहिए
• "Copilot Lag" नाम की एक अवधारणा है
  • इसका मतलब है कि engineer हर task के बाद यह इंतज़ार करता रहता है कि अगला क्या करना है
  • मैं 10-15 साल से यह अनुभव करता आ रहा हूँ
  • LLM ज़्यादा नुकसान नहीं पहुँचाएँगे
• मैं coding copilots को छोड़ देने की कगार तक पहुँच गया हूँ
  • मैं अपना ज़्यादातर समय उनसे लड़ने में बिताता हूँ
  • इसमें कुछ गलती मेरी भी हो सकती है
  • UX/implementation की समस्याएँ भी हैं
  • LLMs कई तरह के विषयों पर mid-level expert की तरह उपयोगी हैं
  • लेकिन उनमें echo chamber में फँस जाना आसान है
  • जिन क्षणों में मानवीय intuition, curiosity, creativity और personality की ज़रूरत होती है, वहाँ उनका दीवार से टकरा जाना चौंकाने वाला है
  • मैं इसे toolbox में एक और tool की तरह रखने से संतुष्ट हूँ
  • लेकिन मैं असली लोगों के साथ collaborate करना पसंद करता हूँ