मुझे पीछे छूट जाने दो

• Android डेवलपमेंट की शुरुआत 2014 में Java क्लास में पता चले एक मुफ्त कोर्स और पहली to-do ऐप से हुई, और हाथ में मौजूद सॉफ़्टवेयर का वास्तविक दुनिया को छूना इसकी प्रेरक शक्ति बना
• 10 साल का करियर ऐसे ऐप्स को मेंटेन करते हुए बीता जिनसे यूज़र्स को वास्तविक लाभ मिलता था, जैसे dating app, दवाइयों की उपलब्धता, और यात्रा सहायता; इसी दौरान तकनीक के उद्देश्य की पुष्टि हुई
• कोर्स, hackathon, पहली नौकरी, और Droidcon NYC से गुजरते हुए यह महसूस हुआ कि तैयार प्रोडक्ट से ज़्यादा लंबे समय तक लोगों से बने संबंध और खुले ज्ञान का साझा रह जाता है
• LLM इतने बेहतर हो गए हैं कि compile होने वाला code और review तक दे सकते हैं, लेकिन Stack Overflow शैली की खोज, प्रतिवाद, voting, और trial-and-error से पैदा होने वाली समझ को कमजोर करते हैं
• सॉफ़्टवेयर डेवलपमेंट केवल दोहराए जाने वाले कामों की automation से बदला नहीं जा सकता; यह एक कला और शिल्प है, और ऐसा काम होना चाहिए जिसे इंसान मिलकर इंसानों के लिए बनाएं और साझा करें

---

Android डेवलपमेंट शुरू करने की वजह

• Android डेवलपमेंट की शुरुआत 2014 में कॉलेज की Java क्लास के दौरान एक सहपाठी द्वारा साझा किए गए मुफ्त online course से हुई, और पहला लक्ष्य local storage वाली एक to-do list app बनाना था
• तैयार ऐप को फ़ोन पर चलाकर माता-पिता को दिखाने का क्षण “बल्ब जलने वाला क्षण” बनकर रह गया, और हाथ में लेकर सीधे interact की जा सकने वाली वास्तविक सॉफ़्टवेयर होने की बात ने इसे गहरा अर्थ दिया
• ऐप जेब में हमेशा मौजूद रहने वाला ऐसा टूल था जो व्यवस्थित रहने और productivity में मदद करता था, और इस अनुभव से यह महसूस हुआ कि लोगों पर सकारात्मक असर डालने वाले टूल देना ही तकनीक का उद्देश्य है
• 2018 में बाद में अपनी पत्नी से मिलाने वाली dating app पर सीधे काम करते हुए सॉफ़्टवेयर के वास्तविक दुनिया पर प्रभाव को और सीधे अनुभव किया
• इसके बाद 10 साल तक Android डेवलपर के रूप में कौशल को निखारते हुए ऐसे ऐप्स को मेंटेन किया जो वास्तविक यूज़र्स को लाभ पहुंचाते थे, जैसे किसी खास व्यक्ति को ढूंढना, दवाइयों तक पहुंच बढ़ाना, और यात्रा में मदद करना

इस डेवलपमेंट यात्रा को बनाने वाले लोग

• ऐप्स से भी ज़्यादा लंबे समय तक जो चीज़ बनी रही, वह थी उन ऐप्स को संभव बनाने वाले लोगों से जुड़ाव

• कोर्स और खुला ज्ञान

  • शुरुआती लक्ष्य था जितनी हो सके उतनी जानकारी सोख लेना, और हर हफ़्ते लेक्चर सुनकर प्रोफेसर द्वारा पढ़ाई जा रही Android सामग्री सीखना
  • Googler द्वारा weather app बनाना सिखाने वाला एक और course भी लिया, और क्लास के बीच के समय तथा lunch break तक का इस्तेमाल ऐप बनाने में करने जितना डूब गया
  • कैमरे के पीछे मौजूद लोगों के गहरे ज्ञान और उसे सार्वजनिक रूप से साझा करने की उनकी इच्छा ने गहरा प्रभाव छोड़ा

• hackathon और team building

  • इसके बाद के कुछ साल खुद बनाकर अभ्यास करने में बीते, और 10 से ज़्यादा hackathon में भाग लेते हुए सैकड़ों भावी software engineer से जुड़ाव बना
  • दोस्तों के साथ कार से 2 से 8 घंटे की यात्रा कर 3 दिनों तक लगभग बिना सोए social app, pet tracker, और NFC tag CTF game जैसी चीज़ें बनाईं
  • caffeine के सहारे टिके रहना और tech stack पर बहस करना भी था, लेकिन असली इनाम था हँसी, दोस्ती, और टीम के रूप में कुछ बनाने का गर्व
  • क्या बनाया गया या कोई पुरस्कार मिला या नहीं, यह महत्वपूर्ण नहीं था; अनुभव स्वयं ही इनाम बनकर रह गया

• पहली नौकरी और RxJava

  • graduation के बाद digital marketing company में specialist Android डेवलपर के रूप में पहले दिन बगल में बैठे सहकर्मी ने पूछा, “RxJava के बारे में तुम क्या जानते हो?”
  • RxJava के बारे में बिल्कुल न जानने से घबराहट हुई, लेकिन सहकर्मी ने जज नहीं किया; उसने reactive programming, साथ में बनाए जाने वाले ऐप का संदर्भ, और जल्दी catch up करने का तरीका समझाया
  • दोनों दफ़्तर में हँसी लाने वाले सहकर्मी बने, और साथ ही काम और growth के लिए गहरा जुनून बनाए रखा

• Droidcon NYC और ज्ञान लौटाना

  • उसी सहकर्मी ने पहली Android conference, Droidcon NYC, में ले गया, और समान संकीर्ण रुचि वाले सैकड़ों engineers और दर्जनों speakers के बीच का माहौल बहुत प्रभावशाली रहा
  • speakers को स्वेच्छा से ज्ञान साझा करते देख अगली पीढ़ी के Android engineers के साथ अपनी विशेषज्ञता बांटने की इच्छा पैदा हुई
  • दूसरे engineers की मदद करने के मौके ढूंढना, और पहले मिली मदद को आगे पहुंचाना, करियर का एक महत्वपूर्ण सिद्धांत बन गया

LLM द्वारा वादा किया गया डेवलपमेंट तरीका और वास्तविक अनुभव

• LLM के आम होने के साथ यह सरल वादा कि “अब coding सीखने की ज़रूरत नहीं, बस जो चाहिए उसे prompt में लिखो और code बन जाएगा” मौजूदा software development तरीके के लिए चुनौती बन गया
• शुरुआत में नई तकनीक की संभावनाओं को लेकर उत्साह था, लेकिन वास्तविक उपयोग में यह कभी अस्तित्वहीन methods सुझाता, कभी साफ़ bugs बनाता, और सबसे खराब स्थिति में ऐसा code देता जो compile ही नहीं होता था
• बाद में “यह और बेहतर होगा” वाले वादे के बाद फिर इस्तेमाल करने पर सचमुच सुधार दिखा; यह compile होने वाला code लिखने लगा, stack trace का विश्लेषण कर fix सुझाने लगा, और code review तक करने लगा
• लेकिन ये बेहतर क्षमताएँ साथ ही मानवीय अनुभव को भी खत्म करने लगीं
• कुछ न पता होने पर AI से पूछना और लक्ष्य तक पहुंचाने वाले पहले कामचलाऊ जवाब पर निर्भर होना आसान हो गया, और पहले की तरह Stack Overflow पर वही समस्या झेल चुके किसी व्यक्ति द्वारा सार्वजनिक रूप से साझा किए गए समाधान के रास्ते को देखकर सीखना कम हो गया
• Stack Overflow पर सिर्फ मदद ही नहीं मिलती थी, बल्कि मान्यताओं को चुनौती देने और खारिज करने वाला feedback भी मिलता था; search, review, और community voting के ज़रिए किसी समाधान के समर्थन और विरोध को देखकर समस्या और उसके समाधान को मूल रूप से समझा जा सकता था

automation से कमजोर होती सीख और सहयोग

• engineers को automation पसंद है, लेकिन automation सबसे अच्छा काम छोटे और दोहराए जाने वाले कामों में करती है
• जब कुछ बनाना हो, तब 10 साल में निखारी गई अपनी skills की जगह मशीन को काम सौंप देने से resilient और लंबे समय तक टिकने वाला software बनाने के लिए ज़रूरी critical thinking कमजोर पड़ सकती है
• एक दृष्टिकोण यह भी है कि LLM तेज़ी से code बना देते हैं, इसलिए सिस्टम के बारे में और आलोचनात्मक ढंग से सोचा जा सकता है, लेकिन software development सीखने के मूल तत्व trial-and-error को खो देना आसान है
• trial-and-error केवल यह देखने तक सीमित नहीं कि ऐप चलती है या crash करती है; यह उस architecture, library, pattern, और style को खोजने के लिए कई तरीके आज़माने की प्रक्रिया है जो लक्ष्य हासिल करने के लिए सबसे उपयुक्त हो
• समाधानों पर feedback भी अगर सहकर्मी के सामने बैठकर implementation choices और trade-offs पर चर्चा करने के बजाय किसी black box से पूछा जाए, तो वास्तविक प्रोजेक्ट में क्या काम आया और क्या नहीं, इस पर आधारित बातचीत गायब हो जाती है
• trade-offs पर चर्चाएँ अक्सर सिद्धांत नहीं बल्कि किसी और के सीधे अनुभव पर आधारित होती थीं, और ऐसी बातचीत implementation संबंधी निर्णय को और गहरा बनाती थी

इंसानों के लिए सॉफ़्टवेयर

• LLM एक prediction machine है; इसे खुले तौर पर सीखने और बनाने का चुनाव करने वाले engineers की लंबे समय की प्रतिबद्धता पर प्रशिक्षित text generator और statistical system के रूप में परिभाषित किया गया है
• सार्वजनिक रूप से बनाना तकनीक को बंद कर देना नहीं था, बल्कि युवा engineers के लिए खोजने, समझने और सीखने योग्य वास्तविक उदाहरण बनाना था
• जब code compile नहीं होता, तब LLM साथ बैठकर हँसता नहीं; और जब कोई पूछे “यह कैसे काम करता है?”, तब वह सॉफ़्टवेयर की ऐसी समझ भी नहीं बनाता कि कोई उत्साह से समझा सके
• सबसे बढ़कर, वह मुड़कर मुस्कुराते हुए साथ में “हमने इसे बनाया” कहने की खुशी में शामिल नहीं हो सकता
• लोगों से जुड़ना, अपनी vulnerability दिखाना, मुश्किलें साझा करना, और मदद पाने के बाद blog post या talk के ज़रिए उसे फिर से साझा करना—ये आदतें AI के उपयोग से कमजोर हुई हैं, लेकिन इन्हें फिर से वापस लाने की ज़रूरत है
• सॉफ़्टवेयर डेवलपमेंट एक कला और शिल्प है जिसमें समर्पण, धैर्य, और मजबूत community की ज़रूरत होती है, और इसे इंसानों द्वारा इंसानों के लिए बनाया जाना चाहिए
• अगर AI के साथ बनाना सचमुच भविष्य है, तो उस भविष्य में पीछे छूट जाना भी स्वीकार है

[xunre]

मेरा मानना है कि प्रोग्रामिंग एक जीवनशैली है।

[GN⁺]

Hacker News की राय

• यहाँ प्रोग्रामिंग कम्युनिटी का हिस्सा न बन पाने के विपरीत अनुभव साझा करने वाली टिप्पणियों को अच्छी तरह रखा गया है, लेकिन सोचने के लिए एक और बिंदु है
  हमें इस पूरे सॉफ़्टवेयर तंत्र के निचले स्तर पर मौजूद उन लोगों को याद रखना चाहिए, जिनसे शायद हम सीधे बात भी नहीं करते। ज़रूरी नहीं कि वे सिर्फ़ “users” हों; developers के लिए भी बहुत सा software होता है, लेकिन फिर भी users को ध्यान में रखा जाना चाहिए
  software की quality को probabilistic code extruder के हवाले करना दुनिया में जारी होने वाले software की quality को तेज़ी से गिरा रहा है। LLM से पहले भी मानवीय गलतियाँ या विकृत वित्तीय incentives जैसी समस्याएँ थीं, और यह उन्हीं पर एक और परत जोड़ता है। low-quality और user-hostile software को deploy करने से असली लोगों को छोटे-बड़े नुकसान होते हैं। generative AI की तरफ़ यह कथित “अपरिहार्य” फिसलन developers, users, investors और इससे जुड़ने वाले हर व्यक्ति को नुकसान पहुँचाती है। नुकसान अलग-अलग समय और अलग-अलग तरीक़ों से, धीरे-धीरे सामने आता है, इसलिए उसे नज़रअंदाज़ करना आसान है, लेकिन वह सचमुच हो रहा है
  “AI” हानिकारक है। मुझे पीछे छूट जाने दो

  • software quality को “probabilistic code extruder” के हवाले करने से quality अचानक गिरती है, यह सच है या नहीं, मुझे सचमुच नहीं पता, और शायद आप भी इसे लेकर आश्वस्त नहीं हो सकते। अभी यह सब ज़्यादा तर एहसास जैसा है
    कुछ personal projects चलाने वाले व्यक्ति के रूप में मैं कह सकता हूँ कि AI की मदद से एक ठीक-ठाक CI pipeline बनाकर, test coverage बढ़ाकर, और बेहतर architecture बनाकर quality वस्तुनिष्ठ रूप से बेहतर हुई है। पहले मेरे पास ऐसी मज़बूती पर निवेश करने की क्षमता नहीं थी, लेकिन AI की वजह से यह संभव हुआ
    बेशक आप कह सकते हैं कि मेरा code खराब है और tests भी कमज़ोर हैं, लेकिन ऐसा लगता है जैसे आपने पहले ही निष्कर्ष तय कर लिया है। industry में 25 साल काम करने के अनुभव से मैं कह सकता हूँ कि वह फ़ैसला ग़लत है। हाँ, median codebase का क्या होगा, यह किसी को नहीं पता। हो सकता है मैं असामान्य रूप से ज़्यादा मेहनती हूँ। agentic coding का दौर अभी सिर्फ़ 6–12 महीने पुराना है, इसलिए अभी फ़ैसला रोककर रखना चाहिए
  • मैं इस बात से सहमत हूँ कि LLM द्वारा बनाया गया software लोगों की ज़िंदगी पर नकारात्मक असर डालने की संभावना रखता है। दूसरी ओर, बहुत सा ऐसा software भी बनेगा जो पहले कभी बन ही नहीं सकता था
    कुछ उपयोगों में घटिया software भी software न होने से बेहतर हो सकता है। कुल मिलाकर यह अच्छा होगा या बुरा, इसकी भविष्यवाणी करना मुश्किल है
  • अगर “AI हानिकारक है” वाली नज़र से देखें, तो structured programming, compilers, object-oriented programming, code generation, और agentic engineering—सबको हानिकारक कहा जा सकता है
    इन सबकी समानता यह है कि ये ऐसे tools हैं जिन्हें आलसी लोग ऐसी बैसाखी की तरह इस्तेमाल कर सकते हैं, जिससे कुछ-कुछ चलने वाला लेकिन समस्याग्रस्त code बाहर आता है। आलस्य एक चुनाव है, और चुनाव इच्छा व ज़िम्मेदारी रखने वाले इंसान करते हैं
  • मैं पूरी तरह सहमत हूँ कि low-quality और user-hostile software असली लोगों को नुकसान पहुँचाता है
    अगर AI tools की मदद से हम और खराब software ज़्यादा तेज़ी से बना रहे हैं, तो हमें अपने इस्तेमाल के तरीक़े पर फिर से सोचना चाहिए। अगर इससे बेहतर software नहीं दिया जा सकता, तो फिर इसका इस्तेमाल आखिर किस लिए हो रहा है, समझ नहीं आता
  • इस बात का कोई प्रमाण नहीं है कि quality गिरी है। बल्कि बात लगभग उलटी लगती है
    मैंने ऐसे मामले देखे हैं जहाँ AI code review tools deploy होने वाली defects को पकड़ने में बेहद प्रभावी रहे हैं

• मेरा programming अनुभव लेखक से इतना अलग रहा है कि मुझे जिज्ञासा होती है कि मैं क्या चूक गया। मैंने हमेशा अकेले programming की है, और मुझे याद नहीं कि मैंने कभी online या offline programming पर गहरी बातचीत की हो। यह मज़ेदार और रोमांचक लगता है, लेकिन अफ़सोस कि मुझे ऐसा मौका नहीं मिला
  मेरे लिए AI पहली चीज़ है जिसने मुझे उन ठोस समस्याओं या परिस्थितियों पर राय जैसी कोई चीज़ दी है, जिनका मैं सामना करता हूँ। मैं बहुत विशिष्ट रूप से पूछ सकता हूँ कि जिस चीज़ पर मैं अभी काम कर रहा हूँ, उसके लिए सबसे अच्छा approach क्या है, फिर जवाब पढ़कर और परखकर तय करता हूँ कि किस दिशा में जाना है। अब भी मुझे अक्सर बेतुके जवाब मिलते हैं, लेकिन तब भी यह मुझे “क्या AI ने जो कहा वह सच है?” जैसा सवाल खुद से पूछने पर मजबूर करता है, और इस तरह समस्या के प्रति मेरी सोच को और गहरा करता है

  • AI, Google और yellow rubber duck debugging—दोनों को मिलाकर बनी चीज़ जैसा लगता है
  • लंबे समय तक Android community बहुत क़रीबी रही, और online व offline दोनों जगह ऐसी बातचीत चलती रहती थी। मूल पोस्ट के लेखक भी काफ़ी सक्रिय contributor थे
    अफ़सोस की बात है कि अधिग्रहण से पहले का Twitter इसका केंद्र था, और उसके बाद से community पहले जैसी नहीं रही
  • मेरा अनुभव भी ऐसा ही था, इसलिए मैंने खुद workshops आयोजित करना शुरू किया, और वह सचमुच शानदार रहा—हर बार बहुत कुछ सीखने को मिला। अगर आप किसी भी विषय पर लोगों से मिलना चाहते हैं, तो खुद workshop host करिए
  • second-order effects को सूचीबद्ध करके उन पर विचार करना चाहिए। साथ निभाने वाले इस नज़रिए को कई दृष्टिकोणों में से सिर्फ़ एक माना जा सकता है, लेकिन यह बहुत शक्तिशाली है
  • proprietary AI की समस्या यह है कि Anthropic, Google, OpenAI जैसी कंपनियाँ AI के इस्तेमाल से users की तुलना में ज़्यादा लाभ उठाती हैं
    PostgreSQL, GCC, Git, HTTP, Emacs जैसे tools को इस्तेमाल करने से वे खुद कुछ “पाते” नहीं हैं। वे लोकप्रिय हो सकते हैं और उनमें contributions बढ़ सकते हैं, लेकिन बात वहीं तक है। Claude को जितना ज़्यादा इस्तेमाल किया जाएगा, Anthropic उतना ही अमीर होगा, और दुनिया की programming पर नियंत्रण रखने वाली शक्ति की स्थिति में पहुँचना उसके लिए उतना आसान होगा। इसलिए proprietary AI चाहे हमें कितना भी पसंद हो, हमें फिर से सोचना चाहिए कि बदले में हम क्या सौंप रहे हैं। वह सिर्फ़ 200 डॉलर प्रति माह नहीं है

• Mario Savio ने औद्योगिक क्रांति के चरम पर एक बात कही थी
  एक समय आता है जब मशीन का कामकाज इतना घृणित हो जाता है, और मन इतना दुखता है, कि आप उसमें भाग नहीं ले सकते, यहाँ तक कि निष्क्रिय रूप से भी नहीं। तब आपको अपने शरीर को गियरों, पहियों, लीवरों और पूरी मशीनरी पर डालकर उसे रोकना पड़ता है। और जो लोग उस मशीन को चलाते और उसके मालिक हैं, उन्हें बताना पड़ता है कि अगर हम आज़ाद नहीं हैं, तो मशीन भी बिल्कुल नहीं चल सकेगी
  तब भी मशीनें बहुत-सा काम करने लगी थीं, लेकिन हम अब भी ठीक से काम कर रहे हैं। आख़िरकार यह भी tools का उपयोग ही बन जाएगा और लगता है कि यह मानव बुद्धि को एक और शिखर तक ले जाएगा

  • “मानव बुद्धि को एक और शिखर तक” ले जाने वाली बात से सहमत होना कठिन है। अभी ऐसा कोई संकेत नहीं दिखता कि मानव बुद्धि अपने ऐतिहासिक शिखर के क़रीब है
    मानव ज्ञान शायद हो, लेकिन बुद्धि नहीं। सामूहिक रूप से हम मूर्ख हैं और और ज़्यादा मूर्ख होते जा रहे हैं, और AI से पैदा होने वाली आलसी, बिना सोचे-समझे प्रवृत्ति उस प्रवाह को तेज़ करेगी
  • समझ नहीं आता कि बुद्धिमत्ता को बढ़ावा क्यों देना चाहिए। अगर सब “बुद्धिमान” हो जाएँ तो क्या बदल जाएगा? ज़्यादा से ज़्यादा इस पत्थर पर हम स्वस्थ रहकर लगभग 50 साल ही जी पाएँगे
    मैं खुद को तुलनात्मक रूप से “बुद्धिमान” मानता हूँ, लेकिन मुझे लगता है कि इस विचार को ज़रूरत से ज़्यादा महत्व दिया गया है। मैं बेवकूफ़ और बेफ़िक्र होकर जीना चाहता हूँ। साइकिल चलाना चाहता हूँ, आसमान में तीर चलाना चाहता हूँ, escargot खाना चाहता हूँ, और समय आने पर सोते-सोते मर जाना चाहता हूँ। लेकिन हक़ीक़त में मुझे काम करना है और नर्सिंग होम ढूँढने हैं
  • क्या वे पुराने tools जिन्होंने हमें शारीरिक श्रम से मुक्त किया, मानव शारीरिक क्षमता को भी किसी नए शिखर तक ले गए थे?
  • वह बात औद्योगिकीकरण के बारे में नहीं, बल्कि साथ न देने के बारे में थी। मशीन व्यवस्था का रूपक थी, और संदर्भ 1960s का था
  • यहाँ “हम” कौन हैं? क्या आप फ़ैक्टरी में मशीनें सीधे चलाते हैं? क्या आपको पता है कि 1900 में मशीन चलाने वाले लोग कैसा महसूस करते थे?
    वैसे भी, यांत्रिक प्रतिस्थापन और सोच के प्रतिस्थापन की तुलना नहीं की जा सकती, लेकिन सबसे कम सोच-विचार वाले pro-AI comments ऊपर आने लगते हैं

• इस लेख ने मुझे बहुत-सी बातें समझाईं। लगता है मैं लेखक की पीड़ा को समझ सकता हूँ, और पढ़ते समय यह साफ़ महसूस हुआ। यह बात थोड़ी चौंकाने वाली थी कि फ़र्क “लोगों” ने पैदा किया, और मुझे एहसास हुआ कि शायद मुझे ऐसे अनुभव लगभग कभी नहीं मिले, इसलिए इस तकनीक को देखने के मेरे तरीक़े पर उसका बड़ा असर पड़ा होगा
  मेरे लिए software बनाना ज़्यादातर एकाकी प्रक्रिया रहा है, और यह मेरे आसपास के लोगों की तुलना में कहीं ज़्यादा जुनूनी काम था। मैं किसी tech-केंद्रित इलाक़े में नहीं रहता, न ही ऐसे माहौल में हूँ जहाँ programming, software engineering, या AI को अच्छी तरह जानने वाले लोगों से बहुत बात कर सकूँ। लेखक की तरह मुझे भी नई technologies या नई languages सीखनी पड़ीं, लेकिन मैंने यह किसी बहुत अनुभवी developer की मदद से नहीं, बल्कि घर पर अकेले सीखा
  LLM ने हमें ऐसी स्थिति में छोड़ दिया है जहाँ कई बातें एक साथ सच हैं, और आगे बढ़ने के लिए हमें यह ढूँढना होगा कि इन्हें कैसे संतुलित और सुलझाया जाए। LLM का इस्तेमाल करते हुए सीखा भी जा सकता है और नहीं भी, और यह उपयोगकर्ता के approach, ज़रूरत और इच्छाशक्ति का नतीजा है। LLM के उपयोग में भी लगभग हर चीज़ की तरह कौशल होता है, और उपयोगकर्ता का कौशल इस technology के बारे में उसकी धारणा और आसपास के लोग उसे कैसे देखते हैं, इस पर असर डालता है। अपरिपक्व उपयोगकर्ता ज़्यादा नकारात्मक भावनाएँ पैदा करते हैं
  कुछ लोग वे काम ख़ुद करना पसंद करते हैं जो मशीनें अच्छी तरह करती हैं, इसलिए वे नहीं चाहते कि मशीन करे; दूसरे लोग ऐसे काम नापसंद करते हैं, इसलिए चाहते हैं कि मशीन कर दे। इस साल किसी समय मुझे एहसास हुआ कि मुझे programming से ज़्यादा systems बनाना, design करना और problems solve करना पसंद है
  software development कई चीज़ों का बंडल है, लेकिन उसे एक ही चीज़ मानकर बात करने से और भ्रम पैदा होता है। कोई व्यक्ति application का logic ख़ुद सोचना चाहता है और LLM से code लिखवाना चाहता है, जबकि कोई दूसरा चाहता है कि LLM solution सोचे, implement करे और test भी करे। ये दोनों बिल्कुल अलग लोग हैं, जिनके लक्ष्य और इच्छाएँ अलग हैं। जब कोई Claude या ChatGPT को देखता है, तो हो सकता है वह उससे बिल्कुल अलग चीज़ देख रहा हो जो आप देखते हैं

  • बहुत अच्छी तरह से कहा। मैं भी उसी तरफ़ हूँ। code की बारीकियों पर ideas उछालने और brainstorming करने वाला शायद ही कोई था
    ज़्यादातर समय मुझे किताबों और online posts में गहराई से उतरकर चीज़ों के काम करने के तरीके का अपना मानसिक मॉडल बनाना पड़ता था, और वह प्रक्रिया काफ़ी मददगार थी
    अब AI सीखने का एक tool है, सही तरीक़ा दिखाने वाला tool है, और यह विस्तार से समझाने वाला tool है कि क्या हुआ। आप सवाल पूछ सकते हैं, गलतियों की ओर इशारा करवा सकते हैं, कई implementations के बीच आ-जा सकते हैं, और आख़िरकार बेहतर programmer बन सकते हैं। जैसा कई लोगों ने कहा है, AI हर व्यक्ति के लिए अलग मायने रखता है। मेरे लिए यह सशक्त बनाने वाला, समझ देने वाला, और विनम्र बनाने वाला tool रहा है। सीखने के लिए हमेशा बहुत कुछ था और समय कम पड़ता था, लेकिन अब ज़रूरी नहीं कि वह हमेशा वैसा ही लगे

• proprietary AI की समस्या यह है कि Anthropic, Google, OpenAI जैसी कंपनियाँ AI के उपयोग से उपयोगकर्ताओं की तुलना में ज़्यादा लाभ कमाती हैं। PostgreSQL, GCC, Git, HTTP, Emacs जैसे tools उनके इस्तेमाल से कुछ “हासिल” नहीं करते। उन्हें लोकप्रियता मिल सकती है, योगदान बढ़ सकते हैं, लेकिन बस इतना ही
  आप जितना ज़्यादा Claude इस्तेमाल करते हैं, Anthropic उतना ही अमीर होता जाता है, और दुनिया की programming पर शासन कर सकने वाली शक्ति की स्थिति में पहुँचने की उसकी संभावना बढ़ती जाती है। इसलिए proprietary AI आपको कितना भी पसंद हो, हमें फिर से सोचना चाहिए कि बदले में हम क्या सौंप रहे हैं। वह सिर्फ़ 200 डॉलर महीना नहीं है
  मैं open models और open source agents के पक्ष में हूँ, लेकिन बड़ी कंपनियों को और ज़्यादा शक्ति नहीं देना चाहता। अगर 5 साल बाद इन बड़ी कंपनियों की हमारे ऊपर और ज़्यादा ताक़त हो गई, तो software engineering कैसे बदलेगी, यह सोचकर डर लगता है। उदाहरण के लिए, Claude Code prompts के बीच ads न देखने हों तो और पैसे दो, या generated code आपके app में ads न ठूँसे, इसके लिए और पैसे दो। क्या हम सच में चाहते हैं कि आज के global internet में जो बेहद घटिया अनुभव है, वही software engineering workflow के भीतर गहराई तक धँस जाए?

  • 70~90 के दशक में जब database पहली बार आए थे, तब Oracle, IBM, Sybase, SQL Server जैसी बहुत-सी proprietary database कंपनियाँ थीं, लेकिन आज open source database डिफ़ॉल्ट विकल्प हैं
    अभी के LLM हालात को देखकर लोग तरह-तरह की अतिवादी भविष्यवाणियाँ कर रहे हैं, लेकिन बाज़ार कैसे विकसित होगा, यह किसी को नहीं पता
    programming क्षमता और vibe coding संस्कृति भी शुरुआती electric vehicles जैसी है। electric vehicles के लिए कुछ भूमिकाएँ ऐसी थीं जहाँ वे internal combustion engines से बेहतर फिट बैठते थे, लेकिन वही काम पूरी तरह करने लायक बनने में उन्हें 10 साल और लगे। इस दौरान infrastructure की कमी और technology के अपरिपक्व होने के कारण बहुत-से लोग electric vehicles को अजीब खिलौना, अव्यावहारिक, महँगा और ख़तरनाक कहकर खारिज करते थे
    अभी जो असली moat दिख रहा है, वह data center demand जैसी चीज़ है, लेकिन यह भी scale होगा और commoditized हो जाएगा, और RAM production भी इसकी बराबरी कर लेगा

• ज़्यादातर इंसान काम से उद्देश्य और अर्थ पाते हैं। हमेशा से ऐसा ही रहा है। अगर लोगों की ज़िंदगी से अर्थ को बड़े पैमाने पर हटा दिया जाए, तो क्या होगा? नज़ारा अच्छा नहीं होगा

  • यह अर्थ हटाने की समस्या नहीं है। जो भी साधारण इंसान सोचता-विचारता है, वह करने के लिए कुछ न कुछ ढूँढ़कर अपनी ज़िंदगी भर सकता है। सच तो यह है कि ज़्यादातर लोगों के लिए काम उल्टा इसमें बाधा बनता है
    असली समस्या तब “दिलचस्प” हो जाती है जब सभी सर्वहारा के लिए ज़रूरी तनख़्वाह हटा दी जाती है
  • जब लोगों की ज़िंदगी से बड़े पैमाने पर अर्थ हटा दिया जाता है, तो ऐसी AI कचरा-जैसी पंक्तियाँ निकलती हैं: “AI ईमेल डिलीवेरेबिलिटी विशेषज्ञ जो आपके ईमेल की जाँच और सुधार करता है — Top-Rated विशेषज्ञों द्वारा समर्थित”

• मैं इस लेख से सहमत हूँ। अभी जो हो रहा है, उस पर मेरी प्रतिक्रिया भी “मुझे पीछे छोड़ दो” वाली है
  लेकिन डेवलपर के रूप में बढ़ने के पुराने तरीके के मज़े को याद करना न सिर्फ़ गलत वजह है, बल्कि डार्विनवादी नज़रिए से बहुत ख़तरनाक भी है। ग्राहक आख़िरकार इस बात की परवाह नहीं करते कि चीज़ कैसे बनाई गई; वे long-term support, लागत, पूर्वानुमेयता वगैरह की परवाह करते हैं
  फिर भी, क्या यह कहा जा सकता है कि उद्योग ने सच में ऐसा कोई आगे बढ़ना हासिल किया है जिसका शुद्ध प्रभाव सकारात्मक हो, यह मुझे नहीं पता। पूरा मामला एक बड़ा गड़बड़झाला है। कई मामलों में AI हमें उसी दिशा में turbo mode में धकेल रहा है, जिससे चीज़ें सिर्फ़ ज़्यादा गंदी और महंगी नहीं, बल्कि ख़तरनाक भी बन रही हैं
  मैं “मुझे अकेला छोड़ दो” इसलिए कहता हूँ क्योंकि अगर इस गड़बड़झाले को पहले सिद्धांतों से ठीक से सोचा जाए, तो इसे एक अवसर की तरह देखा जा सकता है

  • शायद ग्राहक इस बात की भी परवाह करें कि यह कैसे बनाया गया

• यह लेख जैसे एक झूठी द्वैधता बनाता है कि या तो AI बिल्कुल मत इस्तेमाल करो, या फिर हर काम AI को सौंप दो। असल दुनिया ऐसे नहीं चलती। आप खुद चुन सकते हैं कि काम का कितना हिस्सा AI को देना है। मानवीय विशेषज्ञता, समुदाय, और तकनीक के प्रति जुनून के लिए अभी भी बहुत बड़ी जगह है
  AI को लेकर सार्वजनिक बहस देखकर cognitive behavioral therapy में बताई जाने वाली cognitive distortions याद आती हैं। ख़ासकर black-and-white thinking और catastrophizing। ये अक्सर चिंता या मनोविक्षिप्तता के लक्षण भी होते हैं, और कभी-कभी सोचता हूँ कि क्या पूरा समाज भी ऐसे लक्षणों से गुज़र सकता है
  https://en.wikipedia.org/wiki/Splitting_(psychology)
  https://en.wikipedia.org/wiki/Cognitive_distortion#Decatastr...

  • निजी प्रोजेक्ट्स में तो मैं सचमुच सहमत हूँ। लेकिन नौकरी में हमेशा आपके पास यह विकल्प नहीं होता
    अगर टीम को PR throughput और token usage से नापा जाने लगे, तो जो लोग पूरी तरह vibe coding करते हैं, उनके बगल में मैं और “खराब” दिख सकता हूँ। मुझे डर है कि अगर मैं vibe coding नहीं करूँगा, तो प्रमोशन में पीछे रह जाऊँगा
    vibe coding के ख़राब होने के संकेत lagging indicators होते हैं। performance problems, service degradation, और बड़े data migration जैसी vibe coding की समस्याएँ हमेशा बाद में सामने आती हैं
  • सही बात है। निष्पक्ष रूप से देखें तो पूरी तरह अपनाने वाले और पूरी तरह ठुकराने वाले, दोनों तरफ़ लोग होंगे, और उनकी आवाज़ ऊँची होगी
    लेकिन वे अल्पसंख्यक होंगे, और बहुसंख्यक लोग बीच का रास्ता ढूँढ़ लेंगे

• मैं एक senior PHP developer हूँ, और हाल ही में मुझे Ruby on Rails प्रोजेक्ट पर भेजा गया है। यह मेरे लिए पूरी तरह अनजान माहौल है। ग्राहक ने कहा है कि LLM का जितना हो सके उतना इस्तेमाल करो
  समस्या यह है कि अगर आप AI से कोडिंग कराते हैं, तो codebase को सीखना लगभग असंभव हो जाता है। जब तक जानबूझकर गहराई में न जाएँ, आप शायद ही कभी एक बार में कुछ पंक्तियों से ज़्यादा कोड देखते हैं, और speed की माँग के कारण शायद उसके लिए समय भी न मिले। नतीजतन टीम में कोई भी कोड के किसी हिस्से को गहराई से नहीं जानता। यह पिछले 25 सालों में मेरे कोड लिखने के तरीके से बहुत अलग है, और कम मज़ेदार भी
  100 साल पहले आप सिर्फ़ कारीगरों द्वारा बनाया गया फ़र्नीचर खरीद सकते थे। सचमुच के कारीगर। आज IKEA और हस्तनिर्मित, दोनों विकल्प हैं। ज़्यादातर लोग यह नहीं देखते कि वह कैसे बना; अगर वह अपना काम कर दे, तो वे IKEA चुन लेते हैं। फिर भी कुछ लोग हैं जो अब भी हस्तनिर्मित फ़र्नीचर पसंद करते हैं, और उसके लिए अच्छा-खासा पैसा देते हैं
  लगता है software भी उसी दिशा में जा रहा है, और अफ़सोस के साथ मैं सहमत हूँ। software development एक शौक बन जाएगा। जैसे बहुत लोग अपने खाली समय में woodworking करते हैं। शायद बहुत कम असली विशेषज्ञ बचेंगे, जो ज़्यादातर consulting करेंगे। शायद वे training data बनाएँगे, या ऐसे frameworks डिज़ाइन करेंगे जिनमें AI महारत हासिल करेगा। पता नहीं। लेकिन इतना तय है कि आगे चीज़ें अलग होंगी, और सब कुछ अच्छे के लिए नहीं होगा
  अभी AI इंसानों के लिए बना रहा है, और कभी-कभी दूसरे AI के लिए भी। बहुत जल्द AI दूसरे AI के लिए बनाएगा, और कभी-कभार इंसानों के लिए। बाद में AI मुख्य रूप से AI के लिए बनाएगा, और इंसानों के लिए बनाना दुर्लभ हो जाएगा

  • जहाँ मैं रहता हूँ, वहाँ अब भी कारीगरों से फ़र्नीचर खरीदा जा सकता है। मैंने स्थानीय दुकान से एक बिस्तर खरीदा था, वह बिल्कुल महंगा नहीं था और मैं काफ़ी संतुष्ट था
    शायद आपको अपने देश में भी देखना चाहिए कि क्या ऐसा है। लोग अपने-आप मान लेते हैं कि IKEA ने हर जगह की स्थानीय दुकानों को मार दिया है, लेकिन अगर खोजें तो स्थानीय फ़र्नीचर की दुकानें बहुत मिलती हैं
  • मैं कारीगर को देने लायक पैसे नहीं रखता, इसलिए IKEA खरीदता हूँ। अब इतने कारीगर बचे ही नहीं कि इतनी मात्रा में बनाकर कीमत नीचे ला सकें

• यह लेख या तो LLM ने लिखा है, या फिर आजकल की मानक ब्लॉग-लेखन शैली में लिखा गया है। वह शैली खुद ही धीरे-धीरे LLM जैसी होती जा रही है
  Sam Kriss ने हाल की एक पोस्ट में ऐसे “संकेतों” को अच्छी तरह पकड़ा है: https://samkriss.substack.com/p/if-you-let-ai-do-your-writin...

  • ख़ासकर HN पर तो जैसे “LLM पहचानो” खेल चल रहा है, और लगभग हर लिंक किए गए लेख पर यह टिप्पणी ज़रूर आ जाती है कि इसे AI ने लिखा है
    क्या लोग यह नहीं समझते कि AI के “संकेत” परिभाषा के अनुसार इंसानों से ही आते हैं? Sam Kriss का लेख चटकीली शैली की आलोचना करते हुए Salman Rushdie और Arundhati Roy को उदाहरण के तौर on रखता है कि वे भी AI जैसे “सस्ते हथकंडे” इस्तेमाल करते हैं, और पूरे सम्मान के साथ कहूँ तो इसे मानना मुश्किल है। अजीब रूपक इस्तेमाल करने पर किसी को LLM-उपयोगकर्ता ठहराने वाली बात के यह ख़तरनाक रूप से क़रीब है। इंसान LLM के बिना भी बहुत लंबे समय से अजीब चीज़ें लिखते आए हैं
    और इस लेख में आख़िर कौन से “संकेत” हैं? यह तो काफ़ी सीधा-सादा पढ़ाई देता है, और इसमें कोई अजीब रूपक भी नहीं है। em dash भी असल में कोई सुराग नहीं है, बल्कि इस लेख की तरह “ - ” जैसा space-hyphen-space इस्तेमाल करना तो काफ़ी मानवीय लगता है। सबसे बढ़कर, मैं उस व्यक्ति को benefit of the doubt देना चाहूँगा जिसने लिखा है कि वह LLM के साथ programming नहीं करना चाहता
    “अनाथों को पीटने वाली मशीन मुझे अस्तित्वगत बेचैनी और डर से भर देती है, लेकिन वह बात पाठक तक पहुँचाने के लिए मुझे उस मशीन से कुछ और अनाथ पिटवाने पड़ेंगे” जैसी पंक्ति अजीब लगती है
  • मेरे पास AI से बना कचरा देखने का समय नहीं है। मुझे Claude से कोड लिखवाने वापस जाना है ;)