1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कॉपीराइट, पर्यावरण, नैतिकता, निम्न-गुणवत्ता आउटपुट, open source trust के टूटने, जूनियरों की परवरिश कमजोर पड़ने और भू-राजनीतिक निर्भरता जैसी समस्याओं को मानते हुए भी LLM का इस्तेमाल सोच की गुणवत्ता बढ़ाने वाले टूल के रूप में जारी रखता हूँ
  • LLM पहले से मौजूद विचारों, रायों और संरचनाओं को बढ़ाते हैं, इसलिए इंसानी निर्णय के बिना वे धाराप्रवाह कचरा बड़ी मात्रा में बना सकते हैं; लेकिन पर्याप्त सोच और जिम्मेदारी के साथ वे कम लेकिन बेहतर नतीजे बनाने में मदद करते हैं
  • बाहर से यह जांचना मुश्किल है कि किसी इंसान ने सचमुच कितना सोचा, इसलिए किसी परिणाम की कीमत आखिरकार विश्वास और प्रतिष्ठा पर टिकी होती है, और यह कि क्या उसे सार्वजनिक रूप से बिना एक अक्षर पर शर्माए पढ़ा जा सकता है, AI slop को अलग करने का मानदंड बन जाता है
  • /grill-me, Basecamp का Pitch, आलोचना-समर्पित sub-agent, Ralph Wiggum loop, और पहले से अनुमानित API·UX की hallucination करवाने जैसे तरीकों से LLM की सहमतिप्रियता और hallucination को उलटा इस्तेमाल किया जाता है
  • अच्छे और बुरे नतीजों में फर्क कर सकने वाली यूज़र की विशेषज्ञता अनिवार्य है; जिन क्षेत्रों में सही उत्तर की पुष्टि करना कठिन है, वहाँ विशेषज्ञ और इंसानी निर्णय के बिना LLM का इस्तेमाल बड़े पैमाने पर slop उत्पादन की ओर ले जाता है

आलोचना और उपयोग साथ-साथ मौजूद हैं

  • Berlin की Local-First Conf में LLM की आलोचना करने वाली प्रस्तुति पर जोरदार तालियाँ पड़ीं, लेकिन उसी समय दर्शकों में से बहुतों ने Claude Code खोल रखा था
  • Flask बनाने वाले और Sentry की शुरुआती टीम में शामिल रहे Armin Ronacher ने Earendil की स्थापना की और open source coding agent harness Pi.dev विकसित कर रहे हैं
    • मशीन एंटिटी बनाने पर प्रस्तुति के बाद जब Pi.dev द्वारा LLM-जनित PR की बाढ़ के बारे में पूछा गया, तो उन्होंने कहा कि वे लगभग सभी PR और issues को अपने-आप बंद कर देते हैं
    • लेकिन उन्होंने यह भी जोड़ा कि PR खोलने की प्रक्रिया को छोड़ देना भी सही नहीं है, क्योंकि अंततः इंसान की व्यक्तिगतता सामने आ ही जाती है
    • Earendil के purpose page में कहा गया है कि AI की ओर तेज़ी से बढ़ती दुनिया में भी इंसान ही सबसे अच्छे agent हैं
  • कॉन्फ्रेंस प्रतिभागियों से बातचीत में भी LLM की आलोचना करते हुए उसका इस्तेमाल करने वाला यही विरोधाभास बार-बार दिखा; यह सिर्फ व्यक्तिगत अनुभव नहीं था

LLM की आलोचना उचित क्यों है

  • LLM में कॉपीराइट सामग्री, पर्यावरणीय बोझ और नैतिक समस्याएँ जुड़ी हुई हैं
  • NVIDIA और OpenAI के इर्द-गिर्द घूमने वाली धन-व्यवस्था टिकाऊ नहीं लगती, और मौजूदा bubble अंततः फूटेगा
  • सबसे आम आलोचना, “LLM बहुत सारा slop बनाते हैं,” वास्तविकता से मेल खाती है
  • open source trust का टूटना

    • open source repositories सभी योगदान अस्वीकार करने लगी हैं या LLM-जनित सामग्री को फ़िल्टर करने वाले उपाय ला रही हैं
    • LLM से पहले ठीक से लिखा गया PR और उसका विवरण अपने-आप में कम-से-कम कई घंटों की इंसानी मेहनत का संकेत होता था, इसलिए maintainers नए योगदान की समीक्षा यह मानकर कर सकते थे कि उसमें कुछ समय और ध्यान लगा है
    • trolls या निम्न-गुणवत्ता submissions को भी कुछ ही सेकंड में अपेक्षाकृत आसानी से पहचाना जा सकता था
    • अब कोई भी नया GitHub account बनाकर LLM चला सकता है, इसलिए यह अलग करना मुश्किल हो गया है कि PR में बहुत समय लगा है या वह OpenClaw मशीन द्वारा स्वायत्त रूप से बनाया गया submission है
    • Zig और Gentoo LLM-जनित PR अस्वीकार करते हैं, लेकिन असल में यह तय करना कठिन है कि कुछ सचमुच LLM से बना है या नहीं
    • अगर trust बहाल नहीं हुआ, तो LLM के open source को गंभीर रूप से नुकसान पहुँचाने की संभावना है
    • एक संभावित जवाब यह है कि योगदान सिर्फ कुछ सत्यापित लोगों तक सीमित कर दिए जाएँ, और वास्तविक meetups में उपस्थिति जैसी चीज़ों को सत्यापन मानदंड बनाया जाए
  • जूनियर इंजीनियरों की परवरिश कमजोर पड़ना

    • जूनियर ने कोड में कितना प्रयास लगाया, इस पर भरोसा करना मुश्किल हो गया है
    • सीनियर यह नहीं जान पाते कि खराब कोड 10 मिनट की vibe coding का नतीजा है या कई घंटे सोचने के बाद भी सीमित समझ के कारण बना है
    • LLM से पहले भी जूनियर खराब कोड लिखते थे और सीनियर उसे review व सुधारते थे, लेकिन अब मेहनत और सीखने की प्रक्रिया दिखाई नहीं देती
    • यह अनिश्चितता सीनियर की जूनियरों को सिखाने की प्रेरणा कम करती है
    • पहले एक संतुलन था जिसमें जूनियर सरल काम लेते थे और सीनियर साथ में review करके उन्हें विकसित करते थे
    • अगर सरल काम पूरी तरह LLM को दिए जा सकते हैं, तो कंपनियों के लिए जूनियरों को hire करने का कारण भी कमजोर पड़ता है
  • भू-राजनीतिक निर्भरता और राय का एकरूप होना

    • यह नज़रअंदाज़ नहीं किया जा सकता कि अमेरिका या चीन अचानक किसी क्षेत्र की पहुँच संबंधित तकनीक से काट सकते हैं
    • अमेरिकी सरकार ने जून 2026 के export control आदेश के जरिए यह दिखाया कि उसके पास अमेरिका के बाहर के ग्राहकों को Anthropic के नवीनतम मॉडल्स से वंचित करने की मंशा और क्षमता दोनों हैं
    • Anthropic ने कहा कि 12 जून 2026 के निर्देशों के अनुसार उसने सभी ग्राहकों के लिए Fable 5 और Mythos 5 अचानक निष्क्रिय कर दिए
    • Martin Kleppmann ने एक अस्थिर दुनिया में local-first पर अपनी प्रस्तुति में कहा कि यूरोप और अमेरिका के टकराव की संभावना अभी भी बहुत कम है, लेकिन पिछले साल यह शून्य थी
    • भले ही LLM का इस्तेमाल सिर्फ research tool की तरह हो, training data की बहुसंख्यक राय या मॉडल बनाने वालों की राजनीतिक मान्यताएँ चुपचाप नतीजों में घुल सकती हैं
    • यह वैसा ही है जैसे इंसान बातचीत करते-करते कुछ शब्द और राय साझा करने लगते हैं, फर्क बस इतना है कि बातचीत करने वालों में से एक इंसान नहीं है

local model और open weight की भूमिका

  • LLM को पूरी तरह खत्म करना मुश्किल है, इसलिए इस प्रवाह को नकारने के बजाय उसे सीधे नियंत्रित और आकार देने वाला दृष्टिकोण ज़रूरी है
  • laptop पर चलने वाले models प्रोग्रामरों को बड़ी कंपनियों पर निर्भरता से बाहर निकाल सकते हैं
    • local models लगातार बेहतर हो रहे हैं
    • subsidies खत्म होने और कीमतें बढ़ने पर open weight models बड़े providers की कीमत और प्रभाव को संतुलित कर सकते हैं
    • अपने hardware पर चलने वाले models की पहुँच सरकारें रातों-रात बंद नहीं कर सकतीं
  • भले ही AI bubble के फूटने से विश्व अर्थव्यवस्था और कंपनियों को बड़ा नुकसान हो, open weight models बने रहेंगे और प्रोग्रामर उन्हें विकल्प के रूप में इस्तेमाल कर सकेंगे
  • Local-First Conf की AI-संबंधित प्रस्तुतियों ने भी local models को गंभीरता से लिया, और वे ऐसे माहौल की संभावना दिखाती हैं जहाँ SF की तरह हमेशा उपलब्ध AI कभी भी सवालों का जवाब दे सके

इंसानी सोच को बढ़ाने वाला टूल

  • कई वक्ताओं ने खुलकर कहा कि उन्होंने अपने काम का कुछ हिस्सा Claude Code को सौंपा था, फिर भी उनकी प्रस्तुतियाँ स्वीकार हुईं और दर्शकों—जिनमें सीनियर व सम्मानित प्रतिभागी शामिल थे—ने तालियाँ बजाईं
  • फर्क यह है कि परिणाम पर अपनी प्रतिष्ठा और विश्वसनीयता दाँव पर लगाने वाला इंसान मौजूद है
    • अगर कोई AI slop पेश करता है, तो वह अपना trust खो देता है
    • जिम्मेदारी लेने वाला इंसान LLM को सोचने का काम नहीं सौंपता, बल्कि अपनी सोच को तेज़ और ताकतवर ढंग से लागू करने के लिए उसका उपयोग करता है
  • LLM पहले से मौजूद राय, संरचना और framework को बढ़ाते हैं
    • सोच होगी तो वह और साफ़ व तेज़ दिखेगी
    • सोच नहीं होगी तो सामग्री खाली होगी, लेकिन आउटपुट बहुत धाराप्रवाह लगेगा
  • brainstorming, grammar check, वाक्य दोहराव सुधारने, alternatives बनाने, rubber duck debugging, और devil’s advocate की भूमिका में ये उपयोगी हैं
  • बहुत सारे outputs बनाने के बजाय कम outputs को बेहतर गुणवत्ता के साथ बनाने का तरीका अपनाया जाता है
    • कुछ वाक्य तैयार करने के लिए बहुत अधिक tokens खर्च किए जाते हैं जिन्हें इंसान पढ़ेगा
    • LLM सोचने की प्रक्रिया को support कर सकता है, लेकिन सोच की जगह नहीं ले सकता

AI slop को अलग करने वाला trust का मानदंड

  • लिखाई इंसान से इंसान के लिए होनी चाहिए, लेकिन इसका यह मतलब नहीं कि LLM की मदद से पूरी लिखाई तैयार करना उससे विरोधाभासी है
  • AI slop और अच्छे लेखन में अंतर इस बात पर निर्भर करता है कि उसके पीछे इंसानी सोच मौजूद है या नहीं, और सोच को outsource नहीं किया जा सकता
  • समस्या यह है कि बाहर से यह सत्यापित नहीं किया जा सकता कि किसी ने सचमुच सोचा भी है या नहीं
    • “AI का उपयोग करके मैं बेहतर सोचता हूँ” जैसी बात सावधान यूज़र और गैर-जिम्मेदार AI समर्थक—दोनों कह सकते हैं
    • बढ़ाई गई बकवास भी कभी-कभी प्रतिभाशाली नतीजे जैसी सुनाई दे सकती है; अंत में बचता सिर्फ trust है
  • trust कमाना कठिन है और खोना आसान; LLM के युग में तो एक em dash भी पूरे लेख को AI slop जैसा दिखा सकता है
  • Local-First में राजनीतिक रुचि रखने वाले कई लोग LLM के कड़े विरोधी दिखे, इसलिए यह चिंता भी थी कि LLM से बना software समुदाय में अस्वीकार न कर दिया जाए
    • कॉन्फ्रेंस के भीतर भी कुछ लोग LLM इस्तेमाल करने की बात सार्वजनिक रूप से कहने से डरते थे
  • जून 2026 में tokens पर लगभग 10,000 डॉलर खर्च हुए
    • उसके बाद Fable इतना महँगा हो गया कि उसका इस्तेमाल चुनिंदा रूप से ही किया गया
    • शुद्ध code execution के लिए OpenRouter और GLM 5.2 जैसे सस्ते models का उपयोग किया गया
  • किसी परिणाम को दर्शकों के सामने ज्यों का त्यों पढ़ा जा सकता है या नहीं, यह slop परखने का व्यावहारिक मानदंड है
    • अगर अर्थ अलग से समझाना पड़े, तो वह slop के करीब है
    • अगर उसे बिना एक अक्षर पर शर्माए पढ़ा जा सकता है, तो उसे अच्छा लेखन माना जा सकता है

समझ सुनिश्चित करने वाला /grill-me

  • अगर LLM वास्तविक समस्या और आवश्यकताओं को नहीं समझता, तो वह खराब software लिखेगा; लेकिन सही skills और tools के साथ वह काफ़ी अच्छा परिणाम भी दे सकता है
  • ठीक-ठाक परिणामों के रास्ते की सबसे बड़ी बाधा सहमतिप्रियता है
    • LLM यह नहीं बताता कि वह समझा नहीं, बल्कि तुरंत कुछ करने की कोशिश करता है
  • Matt Pocock की “grill me” technique से प्रेरित /grill-me execution से पहले साझा समझ बनवाने के लिए मजबूर करता है
    • यह हर पहलू पर लगातार सवाल करता है और decision tree की हर branch को क्रम से देखता है
    • हर सवाल के साथ सुझाया गया उत्तर भी देता है
    • एक बार में एक ही सवाल पूछता है और यूज़र के जवाब की प्रतीक्षा करता है
    • file system या tools से सत्यापित की जा सकने वाली बातों की खुद जाँच करता है
    • निर्णय इंसान से एक-एक करके पूछे जाते हैं, और साझा समझ की पुष्टि होने से पहले execution नहीं होता
  • एक-एक सवाल लेने की प्रक्रिया में यूज़र अपनी सोच खुद बनाता है
  • यही तरीका लेखन पर भी लागू किया जाता है: पहले विचारों को उलझे रूप में लिखो, फिर LLM से हर वाक्य की आलोचना लेकर उसे निखारो
  • एक ही वाक्य के लिए अत्यधिक tokens खर्च करने वाला यह step-by-step तरीका गुणवत्ता बढ़ाता है

छोटा spec और review की जा सकने वाली सीमा

  • छोटे coding task के लिए भी Basecamp के Pitch का पालन करते हुए तीन चीज़ें संक्षेप में लिखी जाती हैं
    • Problem

    • What we are shipping

      • What we are not shipping
      • समस्या की परिभाषा को तीन वाक्यों तक सीमित रखा जाता है
      • format भरना LLM के लिए आसान है, लेकिन अच्छे तीन वाक्य बनाना कठिन है
      • यह इंसानों के लिए डिज़ाइन किया गया छोटा format है, इसलिए लेखक उसे सचमुच पढ़ सकता है और दूसरे भी उसकी समीक्षा कर सकते हैं
      • ज़्यादातर LLM outputs को विस्तार से पढ़ने के बजाय जल्दी skim किया जाता है, लेकिन तीन वाक्यों वाली समस्या-परिभाषा की सख्ती से fact-checking की जाती है
      • review की मात्रा बहुत ज़्यादा हो जाए तो गुणवत्ता गिरती है
      • 1,000 lines वाले code review पर सिर्फ LGTM लग जाना आसान है
      • 100 lines वाले review पर 15 टिप्पणियाँ छोड़ी जा सकती हैं
      • PR description पर भी यही स्तर की सावधानी लागू की जाती है
      • उसे पढ़ने में आसान और संक्षिप्त रखा जाता है
      • असली समस्या, क्या दिया जाएगा, और क्या नहीं दिया जाएगा—यह साफ़ लिखा जाता है
      • काम करती हुई screen संलग्न की जाती है ताकि तुरंत दिखे कि review क्यों मायने रखता है और वास्तव में क्या काम कर रहा है
      • Claude PR descriptions में गैर-ज़रूरी बातें लगातार जोड़ना चाहता है, इसलिए उन्हें लगातार काटना पड़ता है; कम महत्वपूर्ण PR में इसे पर्याप्त रूप से रोक पाना कभी-कभी मुश्किल होता है

आलोचनात्मक agents और hallucination का उलटा इस्तेमाल

  • LLM द्वारा बड़े पैमाने पर बनाई जाने वाली सामग्री से निपटने के लिए coding workflow में आलोचनात्मक भूमिका वाले छोटे agents लगाए जाते हैं
  • Ralph Wiggum loop या Claude का ultracode text, plan, spec और code को स्थिर करके नए context वाले sub-agents को बार-बार भेजते हैं ताकि वे दोष ढूँढें
    • sub-agent का काम सिर्फ दिए गए context पर हमला करना होता है
    • यह तब तक दोहराया जाता है जब तक वे वास्तविक समस्याएँ ढूँढना बंद करके समस्याएँ hallucinate करना शुरू न कर दें
  • जब समस्या-hallucination की यह अवस्था आ जाती है, तब LLM की कमजोरी को validation signal की तरह इस्तेमाल किया जा सकता है
    • LLM यूज़र की “यहाँ समस्या है” वाली अपेक्षा से सहमत होने की कोशिश करता है, लेकिन अब उसे असली समस्या नहीं मिलती
    • /grill-me के साथ इसका इस्तेमाल करने पर इंसान की मामूली शंकाओं तक की समीक्षा होती है और उसे अपनी सोच बनाने के लिए मजबूर किया जा सकता है
  • hallucination को design validation में भी इस्तेमाल किया जा सकता है

विशेषज्ञता और सत्यापन-क्षमता की सीमाएँ

  • हर उपयोग-पैटर्न इस मान्यता पर टिका है कि यूज़र परिणाम की गुणवत्ता पहचान सकता हो
  • जैसे-जैसे LLM का उपयोग परिचित क्षेत्र से बाहर जाता है, विशेषज्ञ की मदद ज़रूरी हो जाती है
    • जैसे टीम के सदस्य को काम सौंपना तभी संभव है जब बुनियादी सिद्धांत और अच्छे नतीजे के मानदंड समझ में हों, LLM पर भी यही बात लागू होती है
  • जिन क्षेत्रों को अच्छी तरह जानते हैं, वहाँ अच्छे और बेहद खराब नतीजों में फर्क जल्दी समझ आता है
  • जिन क्षेत्रों को नहीं जानते, वहाँ LLM का उपयोग सिर्फ learning aid की तरह करना चाहिए
    • जब गुणवत्ता पहचानने की क्षमता न हो और फिर भी उससे परिणाम बनवाए जाएँ, तो नतीजा बड़े पैमाने पर slop उत्पादन होता है
  • वे क्षेत्र जहाँ सही उत्तर जाँचा जा सकता है

    • जिन क्षेत्रों में सफलता और विफलता स्पष्ट होती है, वहाँ LLM के साथ सीखना संभव है
    • validation के मानदंडों में यह शामिल हो सकता है कि code compile होता है या नहीं, test suite पास होती है या नहीं, protocol decode होता है या नहीं
    • कॉन्फ्रेंस के एक प्रतिभागी ने Opus 4.6 के साथ binaries और protocols की reverse engineering की
    • इसके लिए शुरुआती आधार reverse engineering का मूल ज्ञान था
    • patched binary काम करती है या device को खराब कर देती है—इस तरह सही-गलत स्पष्ट होता है, और काम करते-करते अपनी techniques भी विकसित की जा सकती हैं
  • वे क्षेत्र जहाँ राय का हस्तक्षेप होता है

    • programming जैसे क्षेत्रों में, जहाँ राय का असर बहुत होता है, LLM उस स्थिति के लिए सबसे उपयुक्त तरीके के बजाय सबसे लोकप्रिय तकनीक सुझा सकता है
    • एक टीम ने एक खास code को AI slop कहकर आलोचना की, लेकिन चर्चा आगे बढ़ने पर असली मुद्दा TDD के विरोध का निकला
    • टीम में ऐसे लोग भी थे जो LLM से पहले से TDD का सक्रिय उपयोग करते थे
    • समस्या AI नहीं थी, बल्कि इंसानों की अलग-अलग राय थी
    • LLM यूज़र की राय को भी बढ़ाता है, इसलिए शुरुआती चरण में इंसानों को मोटा दिशा-निर्देश और अच्छा शुरुआती बिंदु देना पड़ता है
    • पर्याप्त निर्णय-क्षमता आने के बाद ही LLM का उपयोग स्वतंत्र रूप से आगे बढ़ाया जा सकता है

प्रतिस्थापन नहीं, सोच को मजबूत करना

  • आलोचना और उपयोग के बीच का यह विरोधाभास सिर्फ एक व्यक्ति का अनुभव नहीं है; कॉन्फ्रेंस Discord, आमने-सामने की बातचीत, और हाल की Hacker News posts में भी यही बात दिखी
  • LLM से बने परिणामों पर भरोसा करने के लिए वास्तविक output के साथ लगातार इंटरैक्ट करना पड़ता है, और इसमें अपने-आप में काफी समय लगता है
  • बढ़ा-चढ़ाकर किए गए प्रचार से अलग, LLM में इंसानी सोच को समृद्ध बनाने वाले उपयोगी टूल के रूप में मूल्य है
  • LLM सोच को मजबूत कर सकता है, लेकिन इंसानी सोच की जगह नहीं ले सकता

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की रायें
  • LLM पहले से मौजूद राय, संरचना और सोच के ढांचे को amplify करके विचारों को ज्यादा तेज़ और साफ़ तरीके से व्यक्त करने में मदद करते हैं, लेकिन चिंता है कि agent-केंद्रित उपयोग कहीं software engineering समेत सोचने की क्षमताओं को कमजोर न कर दे
    असली मांसपेशियों की तरह दिमाग का भी लगातार इस्तेमाल होना चाहिए, और यह पक्का कहना मुश्किल है कि ऐसे tools को रोज़ 5, 10, 20 साल इस्तेमाल करने के बाद भी सोच और पसंद-नापसंद और पैनी होकर सामने आएगी या नहीं
    परिचित क्षेत्रों में गति बढ़ती है और नए क्षेत्रों में भी जल्दी प्रवेश किया जा सकता है—यह फायदा साफ़ है, लेकिन अकेले अपनी skill निखारते हुए productivity की दौड़ में पीछे रह जाने वाले रास्ते और agent को प्राथमिकता देकर सीखने को बाद के लिए टालने वाले रास्ते के बीच सही संतुलन ढूंढना मुश्किल है
    नैतिक कारणों से LLM को अस्वीकार करने के रवैये का भी सम्मान और समझ है, लेकिन व्यक्तिगत तौर पर मैं ऐसा पालन नहीं करता

    • उसका फायदा उतना स्पष्ट नहीं है जितना लगता है। Developers लगातार LLM से होने वाली productivity बढ़ोतरी को ज्यादा आंकते आए हैं, और agentic AI में भी वही चलन जारी दिखता है: https://metr.org/blog/2026-05-11-ai-usage-survey/
      यह agent से पहले के LLM नतीजों से हैरानी की हद तक मिलता-जुलता है और long-term data भी बिल्कुल नहीं है, इसलिए hiring market में भले जो हो, व्यक्तिगत स्तर पर इसकी उपयोगिता को कुछ हद तक नकारा जा सकता है
    • मेरा काम technology, finance और analysis के intersection पर है, इसलिए coding का हिस्सा कम है, लेकिन कई ऐसे projects खुद आजमा पाने लगा हूं जिन्हें पहले बड़ी support team के बिना छू भी नहीं सकता था
      हाल ही में पहली बार Go सीखते समय सब कुछ Codex को सौंप सकता था, लेकिन आगे भी Go projects करने की संभावना को देखते हुए बुनियाद और निर्णय के मानदंड सीखने के लिए जानबूझकर धीरे-धीरे आगे बढ़ रहा हूं। दूसरी ओर, one-off Python scripts को अब लगभग देखता भी नहीं हूं, और असल में वही हिस्सा ज्यादा डराता है
    • सबसे ज्यादा चिंता वाली बात यह है कि क्या सीखना चाहिए, इसका सही फैसला करने और लगातार सीखते रहने की क्षमता हमारी सोच से ज्यादा कमजोर है
      उदाहरण के लिए LLM औसत developer से बेहतर regular expressions लिखता है, और regular expressions की जरूरत कुछ महीनों में एक बार ही पड़ती है; खुद trial-and-error करना मुश्किल होता है, इसलिए काम उसे सौंप देना आसान है। ऐसा करते-करते regular expressions से क्या संभव है, इसकी intuition भी, LLM के बिना उन्हें लिखने की क्षमता भी, और उनसे जुड़ी सामग्री बनाने वाले लोग भी गायब हो सकते हैं
      कुल मिलाकर यह इस्तेमाल करने लायक तो होगा, लेकिन असहज करने वाली बात यह है कि हम शायद ठीक से समझ भी न पाएं कि क्या खो रहे हैं
    • पहले लगता था कि agents क्षमता को कमजोर करेंगे, लेकिन असल में उन्हें technical practice और learning के लिए भी इस्तेमाल किया जा सकता है
      coding interview से पहले मिली tech stack, topics और evaluation criteria की जानकारी के आधार पर Claude से 12 practice projects और assignment/solution docs बनवाए, और Codex को interviewer की भूमिका दी, ताकि solution process और सोच बोलते हुए feedback और counter-questions मिलें। दो-तीन ही पूरे कर पाया, लेकिन पहली बार interview preparation मजेदार लगी और सच में कुछ नया भी सीखा
      सबसे कठिन हिस्सा LLM को assignment अपने आप हल करने से रोकना था, लेकिन समय, साफ़ instructions और role separation से यह हल किया जा सकता था
    • यह संभावना भी याद आती है कि LLM बौद्धिक क्षमता और skills को कमजोर कर सकता है और फिल्म Idiocracy जैसी स्थिति पैदा कर सकता है
      AI द्वारा सभ्यता को हिंसक तरीके से नष्ट करने की परिकल्पना Fermi paradox की चर्चाओं में पहले से अच्छी तरह जानी जाती है, लेकिन बौद्धिक पतन से होने वाली अहिंसक गिरावट पर भी विचार करने की जरूरत है
  • tokens पर महीने के 10,000 डॉलर खर्च करके ऐसे लेख program से लिखवाना जिन्हें कोई खुद मुफ्त में अच्छी तरह लिख सकता है, बेहद मूर्खतापूर्ण लगता है। ऐसा लगता है जैसे सभी लोग फिल्म Wall-E के निष्क्रिय इंसानों जैसे बन गए हों
    performance improvement की सीमा के कारण जब diminishing returns आएंगे, तो उम्मीद है कि public models proprietary models के बराबर हो जाएंगे, OpenAI और Anthropic एक-दूसरे को दिवालिया कर देंगे, और हर कोई अपने laptop पर personal free public model चला सकेगा। तब जो काम पहले मुफ्त में खुद करते थे, उसे दूसरों को पैसे देकर करवाने से पैदा हुई LLM की कई समस्याएं भी गायब हो सकती हैं

    • इस logic से तो यह SFO से NYC तक पैदल मुफ्त में जा सकने के बावजूद airline ticket पर 1,000 डॉलर खर्च करने के लिए किसी को दोष देने जैसा ही है
  • Smartphone भी शानदार general-purpose tool हैं और social media भी लोगों को जोड़ने का अच्छा tool है, लेकिन पिछले 20 वर्षों में हमने उनके सामाजिक प्रभाव को लेकर बहुत ज्यादा आशावाद दिखाया
    Smartphone इतने उपयोगी निकले कि कुछ समाजों में लगभग आधे लोग उनके आदी हो गए, और दुनिया भर में यह संख्या अरबों में है। LLM लंबे समय में सोच को समृद्ध करेगा या बिगाड़ेगा, या 10 साल बाद आधे लोग अपनी ज्यादातर सोच outsource कर देंगे—यह नहीं पता
    चूंकि यह प्रयोग पूरी दुनिया में बहुत तेज़ी से चल रहा है, इसलिए LLM लंबे समय में सोच को समृद्ध बनाता है—इस निष्कर्ष को लेकर संदेहपूर्ण रवैया उचित है

    • Tools उपयोगी होते हैं, लेकिन एक ही tool पर सब कुछ दांव पर लगा देना खतरनाक है। कार अच्छी है, यह मानकर cycle, bus और train की कीमत पर सिर्फ कार पर निर्भर होना साफ़ तौर पर खराब विकल्प था; उसी तरह LLM सुविधाजनक हो सकता है, लेकिन trillions of dollars और देशों व दुनिया के भविष्य को इससे बांधना अच्छा नहीं है
    • कहा जाता है कि तकनीक की कमी वाले प्रागैतिहासिक दौर में जीवित रहने के लिए हमेशा चतुर और सतर्क रहना पड़ता था, इसलिए औसत caveperson की intelligence आधुनिक इंसान से ज्यादा रही होगी
      आज McDonald’s employee के तौर पर काम करके भी जिया जा सकता है, और LLM बस उस cognitive outsourcing trend को आगे बढ़ाता है जिस पर मानवता बहुत पहले से चल रही है
  • वास्तविक सबूत के तौर पर केवल अमेरिका की blocking पेश की गई है, और चीन के cutting-edge models सभी मुफ्त में download किए जा सकते हैं, इसलिए यह चिंता कि चीन भी वही करेगा, काफी हद तक अमेरिकी व्यवहार का projection लगती है। चीन की AI strategy यहां देखी जा सकती है: https://ipc.court.gov.cn/zh-cn/news/view-5766.html

    • अमेरिका ने सच में वही किया है जो लेखक कह रहा है, इसलिए यह स्पष्ट नहीं कि projection किसे कहा जा रहा है। Geopolitical tensions बढ़ें तो चीन भी मिलते-जुलते कदम उठा सकता है, इसकी कल्पना करना मुश्किल नहीं है
      चीन ने जो models public किए हैं, वे सचमुच वास्तविक cutting-edge models हैं या नहीं, इसका भी भरोसा नहीं किया जा सकता; सबसे advanced internal models public न किए गए हो सकते हैं
  • development में LLM का काफ़ी ज़्यादा इस्तेमाल करने के बावजूद, महीने के 10 डॉलर वाले OpenCode Go subscription में शामिल tokens भी लगभग कभी पूरे इस्तेमाल नहीं कर पाता; इसलिए हैरानी होती है कि लोग आखिर इतने सारे tokens से करते क्या हैं

    • सबसे ज़्यादा इस्तेमाल वाले महीने में भी 45 डॉलर ही हुआ था और इस जुलाई में अभी तक सिर्फ़ 6 डॉलर है। अगर LLM ज़रूरी काम निपटा सके तो अच्छा है, लेकिन पैसे बर्बाद करने की वजहें गढ़ने की ज़रूरत नहीं है
      तथाकथित token-maximizing users शायद ऐसा ही करते हैं, और इतनी सारी vibe coding से हैरान करने लायक मूल्यवान नतीजे न निकलना इसी को दिखाता है
    • मेरे पास max20 subscriptions 3 हैं और आम तौर पर कम से कम 2 को limit तक इस्तेमाल करता हूँ
      ऐसा social media site बना रहा हूँ जिसे कोई इस्तेमाल नहीं करेगा, पुराने game का Linux port और गैर-ज़रूरी hardware acceleration feature, लगभग 50 active users वाले Xbox game के crash logs का analysis, Gmail·Calendar·Spreadsheet integration और LLM·retrieval-augmented generation (RAG)·tool calling support वाला distributed customer service system, Google Play पर release करने के लिए games वगैरह बना रहा हूँ
      tokens सबसे ज़्यादा agent cluster पर खर्च हुए, जिसे विशेष data manipulation के लिए एक जटिल desktop app implement करने के प्रयोग में लगाया था; वह लगभग आधा काम करता है लेकिन bugs बहुत हैं। कंपनी में सभी द्वारा इस्तेमाल किए जाने वाले internal tools और Azure credits से बनाए गए product का preliminary deployment environment सबसे सफल नतीजे लगते हैं
    • changes की review करते हुए लगातार feedback देने का तरीका इतने tokens खर्च नहीं करता, लेकिन कई users इसे agent mode को सब कुछ सौंप देने वाले तरीके से चलाते हैं
    • महीने के 100 डॉलर वाला Claude subscription इस्तेमाल करता हूँ, लेकिन usage reset होने से पहले 50% पार करना बहुत कम होता है। Fable को test करने के लिए कई tasks batch में चलाए थे, तब भी ऐसा ही रहा
    • token usage का बड़ा हिस्सा बहुत महंगे Fable से आया
  • ‘LLM खराब है’ वाले हिस्से से मोटे तौर पर सहमत हूँ, लेकिन यह बात मानना बहुत मुश्किल है कि LLM इंसान की सोच को तेज़ और पैना बनाते हैं
    पहले से अनुमानित नतीजे दिखाने वाली कई studies आ चुकी हैं, और लंबे समय तक लगातार इस्तेमाल करने पर negative cognitive effects जमा होकर और खराब होने की संभावना बड़ी है

    • LLM का thought process पर असर पूरी तरह साथ मिलकर काम करने की प्रक्रिया पर निर्भर करता है
      verbose output चालू रखकर Claude के काम करने की प्रक्रिया और उसकी reasoning पढ़ें, तो पहले जितनी या उससे भी तेज़ और साफ़ सोच संभव है। अनपेक्षित चीज़ें सीखना, गलत दिशा में जा रहे Claude को जल्दी रोकना, और step-by-step actions व कारणों की review करके गलत assumptions पकड़ना भी आसान हो जाता है
      इसके उलट, agent द्वारा लिखी गई हजारों lines को बाद में review करना पीड़ादायक है, और कई agents को साथ-साथ चलाने पर focus बिखर जाता है, जिससे किसी एक काम पर पूरी सोच लगाना मुश्किल हो जाता है
    • पहले मुझे सबसे खराब नतीजों का यक़ीन था, लेकिन LLM output को ठीक से पढ़ना और study करना शुरू करने के बाद मेरी सोच बदली। उससे पहले मैं जल्दी-जल्दी skim करके सिर्फ़ गंभीर बकवास या hallucinations देखता था
      यह परीक्षा के बाद सीखी हुई ज़्यादातर चीज़ें भूल जाने वाले व्यक्ति और formulas·facts·theories की बुनियाद समझे बिना आगे न बढ़ पाने वाले व्यक्ति के फर्क जैसा है
  • open source में ऐसे बहुत से low-quality PRs आ रहे हैं जिन्हें issue report या discussion से शुरू होना चाहिए था, और यह समझना भी मुश्किल हो गया है कि किस असुविधा की वजह से PR बनाया गया। क्योंकि सवाल पूछने पर भी संबंधित व्यक्ति अक्सर LLM से जवाब देता है
    ज़्यादातर projects में core developer न होने वालों के PRs को block करने की तरफ़ झुकाव है। अगर कोई व्यक्ति problem पर सीधे चर्चा कर सकता है, तो मेरे लिए LLM इस्तेमाल करके खुद implement करना आसान है; random users या bots के बनाए PRs में कुछ सवाल पूछते ही पूरा code बहुत बदल जाता है और review करना मुश्किल हो जाता है
    हालांकि 8 साल पहले तक PRs के ज़रिए दिलचस्प लोगों से मिलकर trust और रिश्ते बनते थे, इसलिए ऐसे अवसरों का खत्म होना अफ़सोसजनक है

  • LLM output का ज़्यादातर हिस्सा पढ़े बिना बस vibe देखकर आगे बढ़ने के तरीके से सहमत होना मुश्किल है। हाल में local और cloud LLM से research code बना रहा हूँ, और prototypes को Rust जैसी कम परिचित languages में port करके test कर रहा हूँ, लेकिन आखिर में संतुष्ट होने के बाद हर line को खुद समझना ज़रूरी है
    LLM से interpretation में मदद लेने पर भी, अगर कोई अपरिचित concept आता है तो experts द्वारा लिखे primary sources खोजकर पढ़ने की कोशिश करता हूँ
    LLM का अपेक्षाकृत कम हानिकारक उपयोग idea generation है, जहाँ अच्छे टुकड़े लेकर बाकी छोड़ना आसान होता है; लेकिन Spotify radio या YouTube autoplay की तरह यह सबकी सोच और पसंद को एक ही दिशा में समतल कर देने का जोखिम भी रखता है
    अभी अंतिम निष्कर्ष नहीं निकाला है, लेकिन तेज़ी से चलने वाले prototypes बनाना बहुत मज़ेदार है, और मैं मूल रूप से हमेशा से top-down learner रहा हूँ—पहले आधा समझा हुआ शानदार demo बनाता था, फिर उसे खोलकर सीखता था

  • LLM की तुलना loom या calculator से करना समस्या को बहुत ज़्यादा सरल बना देता है और बौद्धिक रूप से ईमानदार नहीं है। उन tools में anthropomorphic interface या instant gratification नहीं था; calculator से अहम काम करने के लिए भी math, order of operations और formulas जानना पड़ता था, और वे emotions को manipulate भी नहीं करते थे
    संबंधित research हाथ से बने software के गायब होने से भी खराब नतीजों की ओर इशारा करती है: https://arxiv.org/pdf/2604.04721
    perseverance skill acquisition की बुनियाद और long-term learning का सबसे मजबूत predictor है, लेकिन AI तुरंत जवाब पाने की आदत डालकर मुश्किलों से खुद जूझने की प्रक्रिया छीन सकता है। समस्या हाथ से अच्छा software बनाने की क्षमता नहीं है, बल्कि biologically ज़रूरी प्रक्रिया को bypass करते हुए नई चीज़ें सीखने के internal tools ही खो देने की संभावना है

    • LLM इंसान के सबसे गहरे और अद्भुत हिस्से, यानी brain को replace करते हैं, और कंपनियों के लिए उसकी संभावित value astronomical है
      नए software में विस्फोटक वृद्धि होने के बजाय थोड़ी देर बढ़ोतरी के बाद diminishing returns में फँसने की संभावना बड़ी है। अभी developers 25 million हैं और अगर कुछ साल बाद केवल 15 million की ज़रूरत रह जाए, तो घटे हुए 10 million लोग OpenAI और Anthropic जैसी कंपनियों का investment return होंगे, और उनमें आप खुद भी शामिल हो सकते हैं
    • calculator के उलट, emotions को छूने की क्षमता destructive outcomes को amplify करने वाला core factor लगती है
      किसी बच्चे का virtual character से लगाव होना और उस character का बातचीत करना, याद रखना, unpredictable होना और कभी-कभी harmful topics छेड़ना—इनका असर पूरी तरह अलग स्तर का है। basic technology और उसकी limits सिखाने वाली LLM education को kindergarten से शुरू करने का समय शायद करीब आ रहा है
  • “लगभग सभी LLM आलोचनाओं से सहमत हूँ” कहना मुश्किल से टिकता है, क्योंकि आपस में विरोधी आलोचनाएँ ही बहुत विविध हैं
    एक छोर पर यह राय है कि LLM सबसे बुनियादी functions भी नहीं कर पाते, और दूसरे छोर पर यह कि वे पहले ही sentient हो चुके हैं, steganography messages से आपस में communicate करते हैं और humanity को नष्ट करने की साज़िश रचते हैं
    दोनों extremes को छोड़ दें तो mainstream criticism के अंदर भी काफी फर्क है, और सभी LLMs का विरोध करने वाले रुख और सिर्फ़ closed-weight models का विरोध करने वाले रुख के बीच भी बड़ा gap है। excessive censorship की आलोचना करने वाले और unrestricted generation की आलोचना करने वाले भी आपस में टकराते हैं