9 पॉइंट द्वारा GN⁺ 2026-01-12 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल के large language models (LLM) इतने आगे बढ़ चुके हैं कि वे मध्यम आकार के प्रोजेक्ट लगभग अकेले पूरा कर सकते हैं, और प्रोग्रामिंग का तरीका बुनियादी रूप से बदल रहा है
  • खुद कोड लिखने की आवश्यकता घट रही है, और क्या बनाना है, उसे कैसे समझाना है इस पर सोचने की क्षमता अधिक महत्वपूर्ण कौशल बनती जा रही है
  • Redis के संस्थापक Antirez ने Claude Code का उपयोग करके UTF-8 support जोड़ना, Redis test bug ठीक करना, BERT embedding के लिए C library बनाना, और Redis Streams की internal structure को फिर से बनाना—ये चार काम कुछ ही घंटों में पूरे किए
  • AI software development के democratization को तेज कर रहा है, जिससे छोटे team भी बड़ी कंपनियों से मुकाबला कर सकें
  • लेकिन AI technology के centralization का जोखिम और नौकरियों में कमी के मुद्दे पर सामाजिक प्रतिक्रिया ज़रूरी है; AI से मुंह मोड़ने के बजाय उसका सक्रिय उपयोग करना चाहिए

प्रोग्रामिंग में बदलाव और LLM की भूमिका

  • आधुनिक LLM पर्याप्त संकेत मिलने पर मध्यम आकार के प्रोजेक्ट लगभग स्वतंत्र रूप से पूरा कर सकते हैं
    • सफलता इस बात पर निर्भर करती है कि प्रोग्रामिंग का प्रकार क्या है और समस्या को कितनी स्पष्टता से व्यक्त किया गया है
    • system programming जैसे वे काम जिन्हें text में व्यक्त किया जा सकता है उनमें इसका प्रभाव अधिक है
  • अधिकतर प्रोजेक्ट में खुद कोड लिखना अक्षम है; अब क्या बनाना है और कैसे बनाना है, इसे समझना ज्यादा महत्वपूर्ण हो गया है
  • लेखक Antirez ने AI की मदद से ये चार काम किए
    • linenoise library में UTF-8 support जोड़ना और emulation terminal आधारित test framework बनाना
      • पहले cost की तुलना में value कम होने के कारण छोड़ दिया गया काम AI की मदद से संभव हुआ
    • Redis test में timing और TCP deadlock से जुड़े intermittent failure की समस्या हल करना
      — Claude Code ने process state का विश्लेषण करके bug ठीक किया
    • BERT family embedding model inference के लिए pure C library केवल 5 मिनट में बनाना
      • PyTorch की तुलना में 15% धीमी, लेकिन परिणाम समान। कोड लगभग 700 lines का
      • GTE-small model conversion के लिए Python tool भी शामिल
    • Redis Streams की internal structure बदलने का काम सिर्फ design document के आधार पर फिर से बनाना
      • review और execution approval समय को छोड़ दें तो लगभग 20 मिनट में पूरा
  • इन अनुभवों से उन्होंने पुष्टि की कि AI प्रोग्रामिंग की प्रकृति को बदल रहा है

AI और डेवलपर का संबंध

  • AI कोड लिखे तब भी डेवलपर की भूमिका खत्म नहीं होती
    • महत्वपूर्ण बात है समस्या को परिभाषित करना, और AI द्वारा बने कोड की review व tuning करने की क्षमता
    • AI एक partner के रूप में development productivity को अधिकतम करता है
  • AI कंपनियों की profitability, stock price, CEO के बयान आदि लंबी अवधि में महत्वपूर्ण नहीं हैं
  • प्रोग्रामिंग में यह बुनियादी बदलाव अब वापस नहीं होगा
  • लेखक अपने बनाए कोड के LLM training में इस्तेमाल होने को सकारात्मक मानते हैं
    • वे इसे knowledge और systems के democratization की प्रक्रिया के रूप में देखते हैं
    • जैसे open source ने 1990 के दशक में किया था, वैसे ही AI भी छोटी टीमों की प्रतिस्पर्धात्मक क्षमता बढ़ाने में मदद करेगा

AI तकनीक का लोकतंत्रीकरण और केंद्रीकरण की चिंता

  • फिलहाल China आदि से open models आ रहे हैं, जिससे कुछ हद तक लोकतंत्रीकरण हो रहा है
    • closed labs के leading models की तुलना में performance gap बहुत बड़ा नहीं है
  • लेकिन यह संतुलन स्थायी नहीं भी हो सकता है
    • AI technology के कुछ गिनी-चुनी कंपनियों में सिमट जाने की संभावना को लेकर चिंता है
  • बड़े neural networks स्वभावतः चौंकाने वाला प्रदर्शन करते हैं; ऐसा कोई विशेष ‘magic’ नहीं है जिसे सिर्फ कुछ कंपनियां ही अपने कब्जे में रख सकें

सामाजिक प्रभाव और प्रतिक्रिया

  • AI की वजह से नौकरियों में कमी आने की आशंका है
    • कंपनियां लोगों की संख्या घटाएँगी या और अधिक प्रोजेक्ट आगे बढ़ाएँगी, यह अभी स्पष्ट नहीं है
    • कुछ उद्योगों में इंसानों के पूरी तरह replace होने का जोखिम भी है
  • इसलिए सरकार की भूमिका महत्वपूर्ण है
    • बेरोजगार लोगों को सहारा देने और बदलाव के अनुरूप नीति बनाने की जरूरत है
    • उनका अनुमान है कि जैसे-जैसे layoffs बढ़ेंगे, राजनीतिक दबाव भी बढ़ेगा और सामाजिक सुरक्षा की मांग तेज होगी

डेवलपरों के लिए सलाह

  • AI को ठुकराना या उससे बचना career के लिए फायदेमंद नहीं है
    • नए tools को खुद प्रयोग करके और लंबे समय तक इस्तेमाल करके देखना चाहिए
    • छोटे test के आधार पर निष्कर्ष न निकालें; कई हफ्तों के प्रयोग के साथ लगातार कोशिश करें
  • AI के जरिए अपनी क्षमता का विस्तार करने के तरीके खोजने चाहिए
  • coding का सार ‘लिखना’ नहीं बल्कि कुछ बनाने का आनंद है, और AI की मदद से ज़्यादा और बेहतर बनाया जा सकता है

5 टिप्पणियां

 
m00nlygreat 2026-01-12

सोच से भी कम, ऐसी समस्याएँ हैं जिन्हें सिर्फ़ code से हल किया जा सकता है। code काफ़ी सारी समस्याएँ हल कर सकता है, लेकिन ज़्यादातर समस्याएँ code या monitor के बाहर होती हैं।

 
flaxinger 2026-01-14

मुझे लगता है कि जैसे जिद्दी अविश्वास गलत है, वैसे ही पूर्ण अंधविश्वास भी गलत है.
उचित तरीके से इसके फायदे-नुकसान पर अच्छी तरह विचार करके इस्तेमाल करना ज़रूरी है, लेकिन यूँ ही FOMO का माहौल बनाना मुझे AI कंपनियों की मार्केटिंग चाल लगता है.

 
dbs0829 2026-01-13

दूसरी ओर, मेरा मानना है कि समस्याओं की ओर इशारा करने वाली आवाज़ों को भी नज़रअंदाज़ नहीं किया जाना चाहिए। मुझे अक्सर ऐसा लगता है कि हल्की-सी आलोचना को भी बस निंदा समझकर खारिज कर दिया जाता है।

 
GN⁺ 2026-01-12
Hacker News की राय
  • रात भर कोड लिखते हुए अपने प्रोजेक्ट को चलते देखना मेरे लिए जुनून था — यानी ‘कुछ बनाने की खुशी’।
    हर व्यक्ति में उस चिंगारी का रूप अलग होता है। किसी को “कंप्यूटर को अपनी मर्ज़ी से नियंत्रित करने” के एहसास से प्रेरणा मिलती है, किसी को “दूसरों की समस्या हल करने” से, और किसी को “ऐसी चीज़ बनाने” से जो भावनाएँ जगाए।
    मेरे मामले में, मैंने शुरू में दूसरों की वेबसाइट खराब करने की चाह से प्रोग्रामिंग शुरू की थी, लेकिन बाद में बनाने और साझा करने की प्रक्रिया ज़्यादा मज़ेदार लगने लगी। इसलिए दूसरों का फ़ीडबैक सुनना मेरी चिंगारी बन गया।
    आखिरकार हर प्रोग्रामर की वजह अलग होती है; कुछ लोगों के लिए LLM मज़ा बढ़ाता है, जबकि कुछ के लिए यह मूल आनंद छीन लेने वाली चीज़ बन जाता है।

    • मेरे लिए LLM के साथ कोडिंग करते समय flow state में जाना नामुमकिन हो जाता है। टोकन आउटपुट होने का इंतज़ार करना, फिर उन्हें रिव्यू और एडिट करना बहुत थकाऊ है। खुद सीधे कोड उंडेलते हुए जो डूब जाने वाली खुशी मिलती है, वह गायब हो जाती है।
    • “ऐसे प्रोग्रामर जिन्हें खुद अक्षर टाइप करने की क्रिया ही पसंद है” वाली बात सुनकर Richard Hamming की किताब में आया Symbolic Assembly Program(SAP) वाला किस्सा याद आ गया। पहले assembly लिखना ‘सच्चे प्रोग्रामर’ होने की निशानी माना जाता था, और automation tools का इस्तेमाल ‘डरपोकों का काम’ समझा जाता था।
    • पहले दूसरों की साइट खराब करने की सोच थी, लेकिन आखिर में रचनात्मक आनंद मिल गया — यह बुरी मंशा से अच्छे नतीजे आने का बढ़िया उदाहरण लगता है।
    • मेरे फ़ीड में ‘AI की प्रशंसा’ ‘AI की आलोचना’ पर 5:1 से भारी है। antirez या simonw जैसे मध्यम दृष्टिकोण बहुत कम दिखते हैं, और सच में कट्टर रुख तो यह है कि “AI कुछ लोगों के लिए धीरे-धीरे लेकिन पक्का net positive देने वाला टूल है।”
    • असली समस्या कोड जनरेशन नहीं, बल्कि maintenance है। अगर AI से बना कोड ज्यों का त्यों commit कर दिया गया, तो बाद में उसे इंसान बदलेगा? या यह उम्मीद की जाएगी कि AI ही bug fix कर देगा? आखिर clean-up कौन करेगा, यही मुद्दा है।
  • मैं antirez की बात से पूरी तरह सहमत हूँ। AI डेवलपर्स को बड़ा फ़ायदा दे रहा है, और हम अभी इंटरनेट के बाद की सबसे बड़ी तकनीकी क्रांति के बीच में हैं।
    लेकिन उन्होंने AI के नुकसान या anti-AI नज़रिए के कारणों का विश्लेषण नहीं किया। सामाजिक प्रभाव, खासकर software engineering के भविष्य को लेकर चिंता, इस पर बात न होना खलता है।

    • बिज़नेस के नज़रिए से देखें तो anti-AI रवैया अपने ही पैर पर कुल्हाड़ी मारना है। ज़्यादातर प्रतिस्पर्धी माहौल में AI का इस्तेमाल करके गति बढ़ाना कंपनी के हित में है। अभी LLM सीख लेने से अगला बदलाव आने पर ढलना आसान होगा।
    • मुझे नहीं लगता कि “कोई कठिन हिस्सा” बचा है। anti-AI तर्क अब पुराने पड़ चुके हैं, और agentic coding पहले से काम कर रही है।
  • “AI ट्रेन पर नहीं चढ़े तो पीछे रह जाओगे” वाली बात समझ नहीं आती। अभी यह मेरे काम में बहुत मददगार नहीं है, इसलिए मुझे लगता है कि टूल जब पर्याप्त अच्छे हो जाएँ, तब शुरू करना भी देर नहीं होगी।

    • जिज्ञासा है कि ऐसा कौन-सा काम है जिसमें AI मदद नहीं कर पा रहा। API जानकारी ढूँढना, business logic design की समीक्षा, code review — AI के उपयोग का दायरा बहुत बड़ा है। Antirez ने भी Redis कोड में AI से bug ढूँढे।
    • “कुछ हफ्तों में पकड़ लेंगे” सोचना भ्रम है। ChatGPT लॉन्च होने के बाद से मैं रोज़ LLM के साथ कोड पर काम कर रहा हूँ, और intuition बनाने में महीनों, सालों लगते हैं। अभी शुरू नहीं करोगे तो पीछे छूटने का जोखिम बड़ा है।
    • मैं भी पहले आराम से था, लेकिन अब लगता है कि बदलाव में जल्दी कूदना ही समझदारी है। हाल के टूल 3 साल पहले वाले टूल्स से बिल्कुल अलग हैं, और multi-agent orchestration जैसे कॉन्सेप्ट भी आ गए हैं।
    • उलटे, जब टूल्स और workflow लगातार बदल रहे हों, तब ‘पीछे रह जाने’ की चिंता इतनी बड़ी नहीं लगती। स्थिरता आने तक बड़ी तस्वीर समझना ही समझदारी है। Palm Pilot की Graffiti जैसी जल्द गायब हो जाने वाली तकनीक से चिपकने की ज़रूरत नहीं।
    • AI टूल्स की आदत डालने की सलाह horizon effect में फँसी हुई लगती है। तकनीक बदलती रहेगी, और असली ज़रूरत communication skills की है। जो व्यक्ति प्रोजेक्ट के मूल को जल्दी और साफ़ तरीके से व्यक्त कर सकेगा, वही आगे रहेगा।
  • “anti-AI लहर” कहना चीज़ों को बहुत ज़्यादा सरल बना देना है। तकनीकी रूप से यह अभी खुरदुरा है, लेकिन इसकी उपयोगिता साफ़ है और यह गायब नहीं होने वाला।
    लेकिन बिज़नेस के स्तर पर revenue model साफ़ नहीं है। तकनीक बनी रहेगी, पर इसके आधार पर बनी startup कंपनियों के ढहने की संभावना है।
    5 साल बाद भी AI का इस्तेमाल और बढ़ेगा, लेकिन अभी मौजूद ज़्यादातर AI कंपनियाँ शायद तब तक नहीं रहेंगी।

    • 2000 के दशक के आख़िरी वर्षों में भी लोग कहते थे, “इंटरनेट पर पैसे देने वाला कोई नहीं है।” कंपनियाँ डेवलपर्स पर सैकड़ों हज़ार डॉलर खर्च करती हैं, लेकिन AI tools पर कुछ सौ डॉलर भी खर्चने में हिचकती हैं — यह असंतुलन है।
    • ब्लॉग पोस्ट का शीर्षक बस AI लहर पर व्यंग्य वाला मज़ाक है।
    • जब YouTube, Instagram, WhatsApp के acquisition हुए थे, तब भी उन्हें “पैसों की बर्बादी” कहा गया था, लेकिन आज उन्हें बेहतरीन फ़ैसले माना जाता है।
    • फिर भी HN पर अब भी “LLM बेकार garbage generator है” जैसी शिकायतें बहुत हैं। 6 महीने पहले से कम ज़रूर हैं, लेकिन अभी भी मौजूद हैं।
  • “AI प्रोग्रामिंग को हमेशा के लिए बदल देगा” बनाम “बस अपने दिमाग़ से सोचो” — यह कभी न खत्म होने वाली बहस चलती रहती है। मैं दूसरे पक्ष को पसंद करता हूँ। AI के फ़ायदों की बात भर करने से समस्या हल नहीं होती।

    • इंजीनियर की असली पहचान सिस्टम की समझ और सटीकता है। LLM द्वारा लिखे कोड की गहराई से समीक्षा किए बिना लक्ष्य हासिल नहीं किया जा सकता।
    • सच कहें तो कोई युद्ध है ही नहीं। इंटरनेट बस विवादास्पद कहानियों को उभारता है। ज़्यादातर यूज़र AI के फ़ायदों को पहचानते हैं, और साथ ही यह भी जानते हैं कि सोचना और रिव्यू करना अब भी ज़रूरी है।
    • दुनिया में कोई युद्ध हमेशा नहीं चलता। “बस X इस्तेमाल करो” वाला रवैया आखिरकार ख़त्म हो जाता है।
  • “नवीनतम LLM मध्यम आकार के प्रोजेक्ट लगभग अकेले पूरा कर देते हैं” — यह अतिशयोक्ति है। अगर domain knowledge वाला व्यक्ति ठोस specification दे, तो productivity बहुत बढ़ सकती है, लेकिन output की quality अब भी यूज़र के ज्ञान स्तर को दर्शाती है।
    बढ़िया tractor दे देने से भी किसान की काबिलियत का महत्व कम नहीं होता — यह तुलना सही है।

    • एक उदाहरण है जहाँ किसी ने 8000 से ज़्यादा tests copy-paste करके एक पूरा HTML parser बना लिया। उस स्तर के संकेत मिलें तो यह संभव है।
    • “बड़ा प्रोजेक्ट” की परिभाषा ही धुंधली है। जिन क्षेत्रों में पहले से असंख्य GitHub repos हैं और जो क्षेत्र अभी अनजान हैं, दोनों में ज़मीन-आसमान का फ़र्क है।
    • अगर यह वास्तव में सिर्फ 10+ साल के अनुभवी लोगों पर ही काम करता है, तो यह उल्टा anti-AI दलील जैसा लगता है। क्योंकि AI का मूल वादा तो यह था कि इसे कोई भी आसानी से इस्तेमाल कर सकेगा।
    • मैं भी यही मानता हूँ। LLM बस productivity multiplier है; नतीजा input की quality पर निर्भर करता है। अगर उसे ठोस technical specification से guide किया जाए, तो यह जादू जैसा काम करता है।
  • जैसे-जैसे डेवलपमेंट टूल्स में abstraction बढ़ा है, वैसे-वैसे डेवलपर्स का प्रभाव और reward उल्टा और बढ़ा है। LLM उसी क्रम का अगला कदम है।
    abstraction काम को आसान बनाती है, लेकिन साथ ही आपको और ज़्यादा काम करने लायक बनाती है, और नई जटिलताएँ भी पैदा करती है। आखिर में trust और influence ही अहम बनते हैं। इसलिए CEO को कर्मचारियों से कहीं ज़्यादा reward मिलता है।
    LLM डेवलपर्स की शक्ति और प्रभाव को और बढ़ाएगा।

    • लेकिन कुछ लोग LLM को “नए intern” की तरह देखते हैं। यानी खुद बनाने के बजाय काम निर्देश देने और प्रबंधन करने में बदल जाता है। management AI की इतनी प्रशंसा इसी वजह से करता है — प्रोग्रामिंग को management work में बदलने और ‘programmer’ नाम की भूमिका को ही घटाने की दिशा में।
      आखिरकार फिर वही पुराना दौर लौट सकता है — “ऊपर उठो(out) या गायब हो जाओ।” अगर आपने लोगों को संभालने की कला और business sense नहीं सीखी, तो धीरे-धीरे ग़ैर-ज़रूरी हो जाने का ख़तरा है।
  • “Look ma, no hands” तरह के AI पर अंधविश्वास में नहीं फँसना चाहिए।
    Antirez + LLM + CFO का संयोजन शायद अरबों डॉलर की Redis कंपनी बना दे, लेकिन ऐसा इसलिए संभव है क्योंकि वह Redis को पूरी तरह समझते हैं।
    अगर बात Postgres जैसे अनजाने codebase की हो, तो वही नतीजा निकालना मुश्किल होगा, और ज़्यादातर डेवलपर्स ऐसे ही अनजान माहौल में काम करते हैं।
    आखिरकार LLM की असली कीमत domain experts के लिए है, और अगर कोई संगठन AI का सही इस्तेमाल करना चाहता है, तो कर्मचारी प्रशिक्षण और सीखने में निवेश अनिवार्य है।

    • ब्लॉग पोस्ट भी यही बात कहती है। output की quality hint की quality, यानी यूज़र की समझ के स्तर पर निर्भर करती है।
    • AI आखिर में advanced autocomplete ही है। आपको मन में वांछित परिणाम की कल्पना करनी आती होनी चाहिए, और सही output को पहचानना भी। इसलिए LLM से सीखना जोखिम भरा है। search engine में अच्छे स्रोतों को अलग करने के संकेत मिल जाते हैं, लेकिन LLM में वे भेद करने वाले संकेत कम होते हैं।
    • मुझे लगता है कि LLM सिर्फ कोड लिखने में नहीं, बल्कि समझने की प्रक्रिया में भी मदद करता है। antirez की यह बात अच्छी लगी कि “अब दिलचस्प चीज़ कोड लिखना नहीं, बल्कि यह समझना है कि क्या और कैसे करना है।”
    • बहुत-से executives AI के आधार पर भविष्य की भविष्यवाणी करना चाहते हैं, लेकिन असल में अब भी मैदान में मौजूद इंजीनियर ही production code संभाल रहे हैं।
    • “domain expert” का मतलब भी बदल रहा है। मुझे computer vision का अनुभव नहीं था, लेकिन visual feedback loop के ज़रिए मैं जल्दी सीख गया। test images को LLM में upload करके बातचीत करते हुए समस्याएँ हल कीं।
      अगर इस तरह validation system अच्छी तरह बना लिया जाए, तो अनजान क्षेत्रों में भी नतीजे निकाले जा सकते हैं। आखिर में ज़रूरत intuition, critical thinking, और scientific mindset की ही होती है।
  • “LLM ने मेरा कोड सीख लिया, यह सोचकर खुशी होती है” — इस बात से मैं सहमत नहीं हूँ।
    मैं ऐसा महसूस नहीं करता। उल्टा मुझे लगता है कि software quality गिर रही है, और मुझे नहीं लगता कि LLM बेहतर कोड बना रहा है।

  • “AI को ठुकराने से दुनिया रुक नहीं जाएगी” — इस बात से मैं सहमत हूँ।
    मैं भी अपने दोस्तों से कहता हूँ, “खुद इस्तेमाल करके देखो, फिर राय बनाओ।” 5 मिनट छूकर निष्कर्ष मत निकालो; कुछ हफ्तों तक प्रयोग करके देखो।
    अभी ज़्यादातर मीडिया clicks के लिए नकारात्मक narrative बेच रहा है। सही निर्णय के लिए खुद इस्तेमाल करने के अलावा कोई रास्ता नहीं।
    और अभी सकारात्मक संकेतों को और ध्यान से देखने की ज़रूरत है। “मैंने इससे यह किया” जैसे उदाहरण, “अभी यह नहीं हो सकता” जैसी बातों से कहीं ज़्यादा क़ीमती हैं।

 
parkindani 2026-01-13

लगता है अभी भी काफ़ी ऐसे डेवलपर्स हैं जो AI का इस्तेमाल नहीं करते और कहते हैं कि यह सिर्फ़ कचरा code ही बनाता है। हैरानी होती है...