AI मुझे बेवकूफ़ बना रहा है

• AI से लिखना लेख, कोड और दस्तावेज़ लिखने में बहुत बड़ा आकर्षण है, लेकिन यह डर भी बढ़ाता है कि खुद लिखने और सोचने की क्षमता कम हो रही है
• AI द्वारा बनाए गए नतीजों को दोबारा पढ़ने पर अक्सर लगता है कि “यह बस AI जैसा है”, और उनमें अपनी बोलचाल या मंशा ठीक से नहीं आ पाती
• पिछले 1~2 साल में कोडिंग में AI पर बहुत ज़्यादा निर्भर रहते हुए लगभग सिर्फ़ prompt ही लिखे, और ऐसा लगता है जैसे खुद कोड लिखने का तरीका भूल गया हूँ
• अब फिर से हाथ से कोडिंग करना सीखने की कोशिश कर रहा हूँ, और मानता हूँ कि कोड पढ़ने-लिखने वाले लोगों की ज़रूरत AI के बाद भी बनी रहेगी
• Claude में लिखी चीज़ पेस्ट करके जाँच लेने की इच्छा खुद में ही आत्म-संदेह है, और AI उसी असुरक्षा पर टिके उस प्रतिद्वंद्वी की तरह है जिसका सामना करना होगा

---

AI के इस्तेमाल से लेखन और कोडिंग क्षमता कमज़ोर होने की चिंता

• AI से लिखना लेख, कोड और दस्तावेज़ तैयार करने में बेहद लुभावना है, लेकिन इससे यह एहसास भी होता है कि खुद लिखने की क्षमता घट रही है
• पहले भले ही लेखन या सॉफ़्टवेयर डेवलपमेंट में खुद को असाधारण नहीं मानता था, फिर भी कुछ हद तक सक्षम समझता था, लेकिन जैसे-जैसे AI का उपयोग बढ़ा, अपनी स्किल्स बिगड़ती हुई महसूस होने लगीं
• AI से लिखे नतीजों को दोबारा पढ़ने पर वे “बस AI जैसे” लगते हैं, अपनी बोलचाल या इरादे से मेल नहीं खाते, और जो कहना चाहते हैं उसे ठीक से नहीं पकड़ पाते
• यह चिंता आत्म-संदेह और imposter syndrome को बढ़ाती है, और यहाँ तक कि इस बात पर भी संदेह पैदा करती है कि क्या वाकई मैं खुद कोई नतीजा बना सकता हूँ

फिर से हाथ से कोडिंग सीखने की वजह

• पिछले 1~2 सालों में कोडिंग के लिए पूरी तरह AI का इस्तेमाल किया, लगभग सिर्फ़ prompt ही लिखे, और ऐसा महसूस हुआ कि खुद एक लाइन कोड भी नहीं लिखी
• नतीजतन ऐसा लगता है जैसे कोडिंग का तरीका ज़्यादातर भूल चुका हूँ, और जो कोडिंग कभी जीवन का केंद्र थी, उसे खो देने का एहसास दुखद और उदास करने वाला है
• अब फिर से हाथ से कोडिंग करना खुद सीख रहा हूँ
• मानता हूँ कि AI होने पर भी सॉफ़्टवेयर डेवलपमेंट की क्षमता पूरी तरह गायब नहीं होगी
  • कोड पढ़ने और लिखने वाले लोगों की ज़रूरत बनी रहेगी
  • ऐसे लोगों की संख्या कम हो सकती है, लेकिन ऐसे लोगों की ज़रूरत फिर भी रहेगी
• उम्मीद है कि AI पिछले 20~30 सालों से चल रहे सॉफ़्टवेयर डेवलपर्स की माँग अधिक होने वाले रुझान को पलट भी सकता है
  • Robert Martin (Uncle Bob) के व्याख्यान की तरह, कंप्यूटर साइंस के पेशा बनने से पहले भौतिकविद, गणितज्ञ और विद्वान जैसे विशेषज्ञ प्रोग्रामिंग किया करते थे
  • सॉफ़्टवेयर डेवलपर्स की माँग तेज़ी से बढ़ने के साथ विशेषज्ञता धुंधली पड़ गई, ऐसा मानता है
• यह लेख AI के बिना लिखा गया है, फिर भी यह चिंता होती है कि कहीं इसमें कुछ अजीब या छूटा हुआ तो नहीं, और Claude में पेस्ट करके जाँच लेने की इच्छा उठती है
• वही इच्छा दरअसल वह आत्म-संदेह है जिस पर AI पलता है, और जिससे लड़ना अभी भी ज़रूरी है

[GN⁺]

Hacker News की राय

• मुझे इस दावे से बहुत ज़्यादा सहमति नहीं है। जब भी मैं AI से कोड लिखवाता हूँ, मुझे लगातार उस बेचैनी वाली भावना से जूझना पड़ता है कि AI ने जो किया है उसे पूरा खंगालूँ और अपने कोड से उसे पूरक या ठीक करूँ
  कुछ ही मिनटों में vibe coding से चलने वाला ऐप मिल जाने का dopamine तो होता है, लेकिन वह बेचैनी उसे संतुलित कर देती है और लगता नहीं कि वह एहसास जल्दी जाने वाला है
  हाँ, शायद ऐसा इसलिए है क्योंकि मेरे पास अनुभव है; अगर मैं junior या mid-level developer होता तो मैं भी इसमें आसानी से फँस सकता था। करियर की शुरुआत में जानकार mentors से code review में पिटकर जो घाव मिले, अगर वे न होते तो शायद वह एहसास भी न होता

  • मेरे अनुभव में Claude बस कोड उगलना जानता है। उसे कोई भी समस्या दो, वह उसे “कोड कम करने” के बजाय “और ज़्यादा कोड लिखने” में बदल देता है
    Claude जो बनाता है उसका बहुत सावधानी से code review करना पड़ता है, नहीं तो codebase बढ़ता ही जाएगा और technical debt 100% की ओर asymptotically बढ़ेगा
    मैं Claude के हर output की review करता हूँ, और उनमें से 90~95% पर नतीजा यही होता है: “वाह, चलता तो है। लेकिन कोड बहुत ज़्यादा है। अब चलो 3 घंटे हाथ पकड़कर इसे तब तक घटाते हैं जब तक कुछ और हटाने लायक न बचे”
  • “कुछ मिनटों में vibe coding” जैसी चीज़ नहीं करनी चाहिए। किसी ने मज़ाक में यह शब्द कहा था, लेकिन industry ने उसे मज़ाक की तरह नहीं लिया; कुछ लोग सचमुच सोचते हैं कि यह विकास का असली तरीका हो सकता है, जबकि ऐसा नहीं है
    agents के साथ बेहतर collaboration का तरीका खोजना होगा। जिन हिस्सों को इंसान को देखना चाहिए उनकी review करो, और बाकी को “outsource” कर दो, तो आप वैसे code और design तक जल्दी पहुँच सकते हैं जैसे आप खुद programming करके पहुँचते
    मैं भी agent द्वारा लिखे गए लगभग 90% code की review करता हूँ, लेकिन हज़ारों शब्द खुद टाइप करने और files के बीच लगातार कूदने से बेहतर मुझे कुछ prompts लिखना या बोलना ज़्यादा अच्छा लगता है। शायद मैं बस typing से थक चुका हूँ
  • पूरी तरह सहमत। मैं game development में AI को सहायक की तरह इस्तेमाल कर रहा हूँ। अगर कुछ नया या दिलचस्प करना हो तो कोड खुद लिखना पड़ता है, नहीं तो मुसीबत शुरू हो जाती है
    लेकिन जो काम बहुत समय लेते हैं और बोरिंग हैं, उनके लिए मैं पहले साफ़ architecture design करता हूँ और फिर implementation AI को सौंप देता हूँ। फिर भी बाद में वापस जाकर देखना पड़ता है कि उसने कोई उल्टा-सीधा काम तो नहीं कर दिया
    हाल का अच्छा उदाहरण: Godot से बन रहे एक game में Codex ने पहले से मौजूद Area2D की functionality को शुरू से फिर से implement करने की कोशिश की
    AI से कोई मायने रखने वाला काम करवाओ तो वह footguns और अजीब decisions से भरा होता है। शायद सैकड़ों डॉलर के tokens खर्च करो तो अलग हो, लेकिन महीने के 10 डॉलर खर्च करने वाले के लिए यह सिरदर्द उसके लायक नहीं
    ऊपर से मेरा project hobby है और coding अब भी मज़ेदार लगती है। save/load, data file parsing, settings menu जैसी बोरिंग चीज़ें ही AI को देता हूँ, और जहाँ human judgment चाहिए वहाँ उसे दूर रखता हूँ
  • अभी अनुभव सच में बहुत कीमती है। agents को बहुत अच्छी तरह guide किया जा सकता है, लेकिन जैसा आपने कहा, juniors की चिंता होती है
    मैं सोचना चाहता हूँ कि मैं agents का इस्तेमाल और गहराई से जाने और तेज़ी से सीखने के लिए करता। पहले Stack Overflow, कई IRC channels, Reddit वगैरह जोड़कर समाधान बनाना काफ़ी मुश्किल होता था
    लेकिन कॉलेज में मैंने assignments भी नकल किए थे और जवाबों को ठीक से review भी नहीं किया था, इसलिए पक्का नहीं कह सकता। फिर भी मैं सिर्फ degree के लिए नहीं, दिलचस्पी से programming करता था, तो शायद फ़र्क पड़ता
    खैर, अच्छा है कि LLM युग आने से पहले ही मैंने बहुत अनुभव और असफलताएँ देख लीं
  • LLM जो code बनाते हैं, मेरे हिसाब से वह बस औसत दर्जे का होता है। मैं यह नहीं कहूँगा कि मैं clean code का कोई प्राधिकारी हूँ, लेकिन इतना समझता हूँ कि code अच्छी तरह structured है या नहीं
    मैं जो कोड खुद लिखता हूँ वह हर बार Claude या GPT से बेहतर होता है
    एक बार मैंने अपने पहले से लिखे project से specs निकालीं, LLM को सिर्फ वे specs देकर उसे दोबारा implement करने को कहा, और फिर code compare किया; LLM वाला version तो उल्टी जैसा था

• developer के नज़रिए से यह सब कुछ हद तक job security जैसा लगता है
  मैंने कुछ समय LLM इस्तेमाल किए हैं; वे काफ़ी अच्छे हैं और उनका उपयोग करना भी मुझे पसंद है। मैंने कुछ apps vibe coding से बनाए, और idea का तुरंत जीवित हो जाना dopamine देता है
  लेकिन मेरे अनुभव में अगर आँख बंद करके भरोसा करो तो काट खानी ही पड़ेगी। vibe coding वाले projects में भी यह मेरी माँग के बिना “features” जोड़ता रहता है
  personal project हो तो अंतिम नतीजा उम्मीद जैसा हो तो ज़्यादा फ़र्क नहीं पड़ता, लेकिन कंपनियाँ इतनी लचीली नहीं होंगी। ग्राहकों को भी शायद हर fix या update के साथ features बदलना या जुड़ना पसंद नहीं आएगा
  मौजूदा स्थिति का सार यह है: बहुत-सी कंपनियाँ इसी दिशा में जा रही हैं, और सही engineering के बिना AI ज़्यादा code लिखते हुए apps को अनजाने में बदल सकता है
  AI का डर और hiring में कमी के कारण market में आने वाले junior engineers की संख्या घटेगी
  जब AI उपयोग एक critical point पर पहुँचेगा तो बड़े पैमाने पर बदलाव होंगे, और उन्हें “prompt” करने वाले लोग दबाव में आने लगेंगे
  दिमाग़ में संभालकर रखने वाली functionality और बढ़ जाएगी। क्योंकि LLM पर 100% भरोसा नहीं किया जा सकता, developer को फिर भी ठीक-ठीक पता होना चाहिए कि application क्या कर रहा है
  आखिर में bugs बढ़ेंगे, और developers अतिरिक्त लोगों की माँग करते हुए शिकायत करेंगे। फिर hiring दोबारा शुरू होगी
  अभी सबसे मुश्किल स्थिति नए developers की है, और सबसे अच्छी स्थिति शायद उन लोगों की है जो पहले से market के अंदर हैं

  • इसमें 10~20 साल पहले के outsourcing boom जैसी कई समानताएँ हैं। छोटी, सस्ती कंपनियों ने देखा कि वे एक अमेरिकी developer की तुलना में कम लागत पर किसी दूसरे देश की पूरी development team रख सकती हैं, और वे बहुत उम्मीदों लेकिन कम process के साथ कूद पड़ीं
    सफल होने की तैयारी लगभग नहीं की गई; सबसे सस्ता विकल्प आँख बंद करके रखा गया, उसे धुँधली requirements दे दी गईं, और लगातार technical review या supervision लगभग नहीं हुआ
    नतीजा भी कुछ वैसा ही था जैसा आपने कहा। शुरुआत में सबसे गंदे code से prototype जल्दी खड़ा हो गया और सबको वह सफलता जैसा लगा, लेकिन समय बीतने पर technical debt और खराब decisions बड़ा resistance बन गए, प्रगति धीमी होती गई, और अंत में project रुक गया या मर गया
    इस बार अलग हो सकता है, लेकिन मेरे शुरुआती काम का बड़ा हिस्सा ऐसे projects को साफ़ करना था। काश नए developers को भी वही मौके मिलें
  • बस उम्मीद है कि bugs बढ़ने और developers के अतिरिक्त लोगों की माँग करने तक मैं टिक जाऊँ
  • मैं भी लगभग इसी निष्कर्ष पर पहुँचा हूँ। interns को सही पारंपरिक रास्ता सिखाने की मैं सच में बहुत कोशिश कर रहा हूँ
  • इस समग्र एहसास से मैं सहमत हूँ कि बिखरे हुए custom solutions बहुत बढ़ेंगे और उन्हें maintain करना पड़ेगा, जिससे hiring भी बढ़ सकती है। लेकिन इसे मुख्य संभावना मान लेने में अभी भी हिचक है, क्योंकि मैंने बहुत कुछ और भी देखा है
    सबसे पहले, efficiency gain बहुत बड़ा है। किसी भी कीमत के किसी भी tool से ज़्यादा। हमारी company का मुख्य product एक web app है, और पिछले कुछ वर्षों से हम उसी मुख्य product को rewrite कर रहे हैं
    एक दोपहर में मैंने अपनी पसंद के stack में नया project बनाया और कुछ ही घंटों में उस product का MVP vibe coding से खड़ा कर दिया जिस पर हम काम कर रहे थे
    वह perfect नहीं था, लेकिन मैंने features एक-एक करके छोटे prompts में माँगे, और हर feature में 5~10 मिनट लगे। वह काफ़ी professional दिख रहा था और किसी भी मानक से “काफ़ी अच्छा” था
    थोड़ा और समय मिलता तो शायद मैं अकेले ही वह चीज़ ship और maintain कर सकता था जिसे एक छोटी dev team ने कई साल में बनाया था। दुख की बात है कि यह efficiency tool से ज़्यादा सस्ता “पूरी टीम replacement” लगता है
    दूसरा पहलू non-technical CEOs का AI hype है। हमारे CEO और executives ने Claude की agent tools को पूरी तरह अपना लिया है, और वे रोज़ mockups, apps, और tool chains खड़े कर रहे हैं
    उनमें लत साफ़ दिखती है, और वे लाभ को सीधे महसूस कर रहे हैं। अभी ऐसा हुआ नहीं है, लेकिन अगर CEO development team का ज़्यादातर हिस्सा निकालकर कुछ skilled developers के साथ पूरा app vibe coding से बनाने लगे तो मुझे हैरानी नहीं होगी
    अभी वे कहते हैं “AI replacement नहीं, multiplier है!”, और उसी वाक्य में यह भी कहते हैं, “अगर इससे हमें अगले कुछ साल hiring न करनी पड़े तो यह जीत है!”
    मुझसे सीधे पूछा गया कि पूरे app को vibe coding से क्यों नहीं बना सकते, और मेरे पास ठोस जवाब नहीं था। “हमें app maintain करना नहीं आएगा” जैसी बातें ठीक लगती हैं, लेकिन Claude एक developer के हाथ में भी काफ़ी कुछ कर सकता है
    यह भी कहा जाता है कि “AI app को अनजाने में बदल सकता है और bugs डाल सकता है,” लेकिन सही observability, testing और कुछ extra prompts के साथ इन्हें मिनटों या घंटों में ठीक किया जा सकता है
    सच कहूँ तो company का पूरी development team बनाए रखना अब मुझे तर्कसंगत नहीं लगता। चाहे जितने projects शुरू करो और initiatives चलाओ, backlog तेज़ी से घटता है और individual developer throughput बेतुका बढ़ जाता है
    non-technical CEOs को technical debt, cognitive debt, खराब software design practices, coding सीखना, developers को तेज़ बनाए रखना, problem-solving का आनंद, अच्छे algorithms या architecture की कलात्मकता—इनमें दिलचस्पी नहीं होती
    उन्हें ऐसा product चाहिए जो ठीक-ठाक चले, value दे, पैसे के लायक हो, और जितना हो सके उतने सस्ते investment में launch हो जाए। दुर्भाग्य से AI लगभग हर पहलू में इन शर्तों पर खरा उतरता है
    उम्मीद है कि नए software की भारी मात्रा demand बढ़ाएगी, लेकिन डर है कि AI की इतनी बड़ी उत्पादन क्षमता में वृद्धि की भरपाई के लिए यह काफ़ी नहीं होगी

• मैंने अगले महीने TypeScript सीखने के लिए समय अलग रखा है। उस प्रक्रिया में AI को पूरी तरह बाहर रखने का इरादा नहीं है
  योजना है कि एक किताब शुरू से अंत तक पढ़ूँ, फिर code लिखूँ। लगता है यह तरीका मैंने किसी podcast में Mitchell Hashimoto से सुना था
  मूल पोस्ट की तरह मैंने भी prompt coding में बहुत समय बिताया है, इसलिए इसे लेकर उत्साह भी है और डर भी

• सिर्फ इसलिए कि आप हाथ से code नहीं लिख रहे, यह संभव नहीं कि आप कम बुद्धिमान हो जाएँ। अगर ऐसा होता, तो हर छुट्टी से लौटकर हमें और मूर्ख हो जाना चाहिए था
  chatbot से बात करने से आपके दिमाग़ की neural connections मर नहीं जातीं
  असल में जो हुआ है वह यह कि आपने कुछ समय के लिए एक बहुत technical skill को आराम दिया है। दुनिया का कोई भी इंसान अगर किसी skill का कुछ समय तक उपयोग नहीं करे, तो उसका थोड़ा हिस्सा “भूल” जाता है
  लेकिन जानकारी गायब नहीं होती; बस ज़्यादा relevant जानकारी के दबाव में उसकी priority कम हो जाती है। थोड़ा-सा revision करो, वह लौट आती है
  AI से पहले भी ऐसा होता था कि मैं कई भाषाओं में से किसी एक में पूरा program लिखने के बीच महीनों का gap रख देता था। function definition कैसे शुरू करते हैं जैसी साधारण चीज़ भी भूल जाता था
  लेकिन सच में वह भूला हुआ नहीं होता था; पुराना एक function देख लेने पर function definition की बाकी संभव syntaxes भी याद आ जाती थीं। घबराने की ज़रूरत नहीं, आपका दिमाग़ सामान्य रूप से काम कर रहा है

• स्कूलों में AI के ख़तरों की बहुत बात होती है, लेकिन वही खतरे किसी भी learning environment पर लागू होते हैं
  मैंने हाल ही में नई नौकरी शुरू की है, और AI की वजह से onboarding मेरे लिए कहीं ज़्यादा कठिन हो रही है। जो सहकर्मी AI कम इस्तेमाल करते हैं, उनकी तुलना में मैं role में ढलने में बहुत धीमा हूँ
  मैं ऐसी language में coding कर रहा हूँ जिसमें मैं सहज नहीं हूँ, इसलिए vibe coding का लालच और ज़्यादा है। फिर भी मेरी क्षमता इतनी है कि Claude जब बकवास या अनावश्यक रूप से लंबा जवाब देता है, तो मैं पहचान लेता हूँ
  लेकिन जितना ज़्यादा समय मैं Claude से code लिखवाने में बिताता हूँ, उतना कम महसूस होता है कि मैं इस job के लिए ज़रूरी skills बना रहा हूँ। PR भेजते समय भी अपने काम को लेकर वह confidence नहीं होता जो होना चाहिए, और यह अच्छा नहीं लगता
  सच कहूँ तो एक और हिस्सा यह है कि जो सवाल मुझे लोगों से पूछने चाहिए, उनके लिए मैं Claude से कहता हूँ कि Slack और docs में ढूँढ़ ले
  AI मेरी social anxiety को खिला रहा है, और मुझे उस human contact से बचने का लालच दे रहा है जो समझ के लिए भी अच्छा है और बुनियादी social interaction के लिए भी ज़रूरी है
  यह ज़िम्मेदारी से बचना लग सकता है, लेकिन यह बात उठानी ज़रूरी है कि कोई तकनीक खास तरह के लोगों के लिए बहुत addictive हो सकती है और उन्हें नकारात्मक behavior loop में फँसा सकती है
  अगर मैं अभी AI पर निर्भरता टाल दूँ, तो शायद बाद में मैं इतना सक्षम हो जाऊँ कि परिणामों को verify करना आसान हो और repetitive काम AI को सौंप सकूँ। यह कठिन है, लेकिन ज़रूरी है

  • मैं सुझाव दूँगा कि Claude से कहो कि वह तुम्हें ज़रूरी चीज़ें सिखाए। जैसे: इस string को uppercase कैसे करूँ? इस समस्या को कैसे approach करना चाहिए? क्या इस काम का कोई standard तरीका है?
    इससे तुम प्रक्रिया के दौरान सीख पाओगे। search engine की तरह इस्तेमाल करने की ज़रूरत नहीं; उस समय जो जानना हो वह पूछो, तो token chain हिलती है और खास तौर पर language beginners के लिए काम की चीज़ निकलती है
    इस तरह तुम पहले skill बनाने और बाद में delegation शुरू करने वाली अपनी योजना पर अमल कर सकते हो
    मैं खुद ऐसे ही करता आया हूँ, और मेरे लिए यह अच्छा संतुलन है। जिस code का मूल्यांकन करना न आता हो वह Claude से लिखवाना मुझे पागलपन लगता है, लेकिन लगता है यह राय अल्पसंख्यक है
  • अभी apprenticeship-style training, यानी internships, के लिए सबसे बुरा समय है। सब चाहते हैं कि AI से जल्दी और अच्छा ship हो, लेकिन इतनी तेज़ iteration में skills सीखने का समय लगभग नहीं बचता
  • LLM codebase का सार निकालकर उसे जल्दी समझने में काफ़ी उपयोगी रहे हैं
    vibe coding के अलावा यह मेरे लिए उन गिने-चुने असली use cases में से एक है जिनका मैंने अनुभव किया है

• मैं AI का इस्तेमाल सोचने-समझने की जगह नहीं, बल्कि repetitive और boring code writing से बचने के लिए करता हूँ। prototype बन जाने के बाद AI code लिखने में काफ़ी सक्षम होता है
  शुरुआती proof-of-concept के लिए मैं खुद एक खुरदुरा prototype लिखता हूँ—बिना comments के, hardcoded variables के साथ। उसके बाद AI उसे product-level तक polish कर देता है
  इससे मैं work ethic, skill level, और high code quality बनाए रखने की क्षमता में अलग-अलग लोगों को manage करने के बजाय agents की team को direct कर पाता हूँ
  AI कई बार codebase के existing patterns बनाए रखने या industry best practices से मेल खाने में भी काफ़ी अच्छा होता है
  AI का इस्तेमाल करने पर अब programming languages में उतना ज़्यादा नहीं लिखना पड़ता। English हो या LLM से बात करने की कोई भाषा, वही मुख्य भाषा बन जाएगी

  • “prototype बन जाने के बाद AI code लिखने में पूरी तरह सक्षम है” — पूरी तरह? यह तो बिलकुल भी perfect नहीं है
    आजकल मेरे दिन का ज़्यादातर हिस्सा code generation robots की बनाई खामियों को ठीक करने में निकलता है
    हाँ, मैं prototype polish नहीं कर रहा; मैं 8 साल से ज़्यादा पुराने एक critical product को maintain, evolve और modernize कर रहा हूँ
  • आख़िर repetitive और boring code होता क्या है?
    किसी project में ऐसा उबाऊ दोहराव वाला कोड ईमानदारी से कितना होता है?
  • ज़्यादातर समय LLM को काम की planning और prototype outline बनाने में जाता है। नहीं तो पूरा नतीजा भयानक गड़बड़झाला बन जाता है
    बहुत सोच-समझकर prompts बनाने पड़ते हैं, इसलिए underlying framework और language को ठीक से समझना ज़रूरी है। नहीं तो सब कुछ भयानक गड़बड़झाला बन जाता है
    मुझे यह भी नहीं पता कि कई agents को कैसे manage करूँ। वे आम तौर पर काफ़ी जल्दी खत्म कर देते हैं। runs के बीच कुछ और करना भी मुश्किल है। हर समय “बस 1 मिनट और, अभी खत्म” वाली स्थिति बनी रहती है
    काम पूरा होने पर output का मूल्यांकन करना पड़ता है। इसलिए “काम” के दौरान गहरी सोच भी नहीं हो पाती। यह pattern social media जैसा है—लगातार attention, लगभग तुरंत reward
    नतीजे में attention span लगातार टूटता है, और बुरी तरह टूटता है
    समस्या यह है कि ऐसी planning कुछ घंटों में गायब हो जाती है, और फिर output का analysis और iteration करते हुए उसकी बेवकूफ़ियों को छाँटना पड़ता है
    कई agents के outputs सँभालना लगातार context switching है। लंबी अवधि में इसके साथ अच्छा हो—यही उम्मीद है
    agents को खुला छोड़ दो और उन्हें कुछ भी बनाने दो, तो output लगभग तय है कि भयानक गड़बड़झाला होगा। बस

• मौजूदा project में मैं हर दिन Java, Ruby और JavaScript में coding करता हूँ। पहले जिन language differences को साधारण Google search से देख लेता था, अब उनके लिए बहुत tokens बर्बाद होते हैं
  Ruby और JavaScript के null-safe operator का फ़र्क, या Ruby और Java के continue/break statements जैसी चीज़ें मैं बार-बार गड़बड़ा देता हूँ
  Claude से मैं सबसे मुश्किल जो काम करवाता हूँ वह पुराने Java loops को ज़्यादा modern streams में refactor करना है, इसलिए शायद मैं काफ़ी निराशाजनक user हूँ। ऐसा code इंसानों के लिए मौके पर लिखना लगभग असंभव हो सकता है

  • “इंसानों के लिए लिखना लगभग असंभव” — यह सुनकर दुख हुआ। ऐसे refactors मुझे सबसे ज़्यादा पसंद हैं, क्योंकि उनका scope छोटा होता है, correctness verify करना आसान होता है, और वे छोटे puzzle जैसे लगते हैं
    अगर खुद का collector बनाना पड़े या standard library के किसी ज़्यादा obscure हिस्से का इस्तेमाल करना पड़े, तो बोनस points
  • Google का टूट जाना भी मददगार नहीं है। जो पहले साधारण Google search था, वह अब वैसे भी AI-घुसपैठ वाला गिरा हुआ built-in अनुभव बन गया है

• एक उल्टा उदाहरण भी है। /plan mode में AI के साथ ideas आगे-पीछे करना, उसकी गलत assumptions पकड़ना, और ज़रूरत पड़ने पर उससे अपने knowledge gaps साफ़-साफ़ समझवाना—यह सब बौद्धिक रूप से काफ़ी stimulating है और मुझे बेहतर engineer बना रहा है
  असल बात यह है कि AI के पास Socratic तरीके से जाओ, उसकी हर सलाह को सोच-समझकर परखो, और उसके आत्मविश्वासी लहज़े व पूरी तरह structured logic के जादू में मत फँसो

• मेरा अनुभव बिल्कुल उल्टा है। शायद इसलिए कि मेरे domain में code/software product नहीं, बल्कि tool है
  मैं बहुत ज़्यादा तेज़ी से और बहुत ज़्यादा सीख रहा हूँ। उदाहरण के लिए, अभी मैं Raman, NMR जैसी spectroscopy hardware के साथ काम कर रहा हूँ, और Claude से device तथा hardware level पर interface करने वाला code लिखवाया है
  data sheets खंगालने और ढेर सारे wrapper code लिखने की जगह यह Claude ने कर दिया
  Claude के साथ अलग-अलग techniques पर चर्चा करना, implement करना, test करना—इससे मैं बहुत तेज़ आगे बढ़ पा रहा हूँ। पहले यही loop 5~10 गुना ज़्यादा समय लेता
  results देखने के लिए तुच्छ code लिखने में मानसिक ऊर्जा खर्च नहीं करनी पड़ती, इसलिए मैं इस equipment, techniques और data के बारे में कहीं ज़्यादा सीख रहा हूँ
  मैं 10 साल से ज़्यादा समय से developer हूँ। अब जाकर ऐसा लग रहा है कि मैं उस दुनिया की ओर बढ़ रहा हूँ जहाँ code को लगातार product बनाने के बजाय एक tool की तरह इस्तेमाल किया जा सकता है, और यह मुझे खुशी देता है

  • यह कि code product नहीं बल्कि tool है, शायद सिर्फ आपकी बात हो। tool के रूप में code तो हमेशा से मौजूद रहा है

• मुझे नहीं लगता कि बहुत से लोगों को हाथ से code लिखने का समय मिलने का सौभाग्य होगा
  सच में अगर हम अपने लिखे code को देखें, तो मेरे मामले में उसका अधिकांश हिस्सा नया या शानदार नहीं, बल्कि वही पुराना “X के लिए backend बनाओ”, साधारण bug fixes, और mid-to-senior programmers के लिए छोटे-मोटे tasks होता है
  ज़्यादा कठिन काम आम तौर पर code के ऊपर की architectural decisions होते हैं, और मैं यह भी सोच रहा हूँ कि ऐसे systems कैसे बनाए जाएँ जो LLM को feature implementation में पटरी से उतरने न दें
  मेरी बात बस इतनी है कि अभी हाथ से code लिखना ठीक लग सकता है, लेकिन आगे चलकर shareholders और ऊपर बैठे लोग चाहेंगे कि LLM की मदद से features जल्दी ship हों और bugs जल्दी fix हों
  अगर आप वह speed नहीं दे पाए तो आपकी performance कम मानी जाएगी। अंततः मायने यह रखता है कि shareholders क्या चाहते हैं, न कि हम क्या चाहते हैं
  हाँ, अगर आप थकते नहीं हैं तो leisure time में हाथ से code लिख सकते हैं। मैं निराशावादी नहीं लगना चाहता, लेकिन मुझे लगता है कि यह काफ़ी जल्द वास्तविकता बन जाएगा

  • शुरुआत से ही मुद्दा speed का नहीं था। तेज़ प्रगति इस बात से नहीं आती कि वही primitive elements जल्दी लिखे जाएँ, बल्कि इस बात से आती है कि बेहतर systems design किए जाएँ और मज़बूत abstractions बनाए जाएँ
  • हर किसी के पास हाथ से code लिखने का समय है। क्योंकि AI असली productivity gain पैदा ही नहीं करता