- LLM को लेकर मौजूदा चर्चा स्पष्ट मात्रात्मक आधार के बिना हो रही है
- हर उपयोगकर्ता का अनुभव बहुत खंडित है, और वास्तविक उपयोग परिवेश या पृष्ठभूमि ज्ञान जैसे मुख्य तत्व लगभग साझा ही नहीं किए जाते
- गैर-निर्धारक प्रकृति के कारण वही काम भी हर बार अलग नतीजा दे सकता है, इसलिए विश्वसनीयता पर सीमाएँ हैं
- उद्योग के नेताओं के बढ़ा-चढ़ाकर किए गए दावे बिना आलोचनात्मक जांच के स्वीकार्यता और अत्यधिक अपेक्षाओं को बढ़ा रहे हैं
- लेखक स्वयं भी रोज़मर्रा में कई तरह के AI टूल्स का उपयोग करते हैं, लेकिन व्यवहार में केवल लगभग आधी बार ही मनचाहा परिणाम मिलता है
LLM को लेकर बहस और तकनीक पर नज़रिया
LLM पर आलोचना और माहौल
- हाल की AI, खासकर LLM (large language model), पर बहसों में आलोचनात्मक दृष्टिकोण को अक्सर "ऐसे लोगों की राय जो तकनीक को ठीक से नहीं समझते" कहकर खारिज करने का माहौल बन गया है
- Hacker News आदि पर "AI से सवाल पूछना ही यह दिखाता है कि आप उसकी मूल प्रकृति नहीं समझते" जैसी प्रतिक्रियाएँ बार-बार दिखाई देती हैं
उपयोगकर्ताओं के अनुभवों के बीच अंतर
- LLM की वास्तविक उपयोगिता को लेकर एक ओर वे उपयोगकर्ता हैं जो कहते हैं कि "कुछ हद तक मदद मिलती है", और दूसरी ओर वे हैं जो कहते हैं कि "सब कुछ आज़मा लिया, पर खास काम का नहीं निकला"
- यह अंतर इसलिए पैदा होता है क्योंकि अनुभवों के लिए ठोस मानदंड और जानकारी साझा नहीं की जाती
- किस तरह के प्रोजेक्ट में इसका उपयोग किया गया
- codebase की स्थिति (नया प्रोजेक्ट, परिपक्व code, private source आदि)
- उपयोगकर्ता की विशेषज्ञता, और वह विशेषज्ञता वास्तविक समस्या से कितनी जुड़ी थी
- LLM द्वारा बनाए गए आउटपुट को वास्तव में refine करके deploy करने तक कितना अतिरिक्त श्रम लगा, जैसी ठोस जानकारी का अभाव
अनुभवों की तुलना की कठिनाई और गैर-निर्धारकता
- मान लें कि कोई उपयोगकर्ता सारी जानकारी विस्तार से साझा भी कर दे, तब भी दूसरे उपयोगकर्ता के साथ अनुभवों की तुलना करना लगभग असंभव है
- LLM और automation agents मूल रूप से गैर-निर्धारक होते हैं
- एक ही समस्या पर, एक ही तरह से prompt देने पर भी हर बार अलग परिणाम मिल सकते हैं
- प्रोजेक्ट का प्रकार, इस्तेमाल किया गया model, tools, language आदि जैसे कई बदलते कारकों के कारण एकसमान सत्यापन कठिन है
उद्योग के नेता और बढ़ा-चढ़ाकर बनाई गई अपेक्षाएँ
- ऐसे कई उदाहरण हैं जहाँ उद्योग के नेताओं ने LLM की उपलब्धियों को जरूरत से ज्यादा उभारा है
- उदाहरण: एक उद्योग नेता ने "Claude Code" का उपयोग करके पुराने bug को हैरान कर देने वाली आसानी से ठीक करने का अनुभव साझा किया, और बिना विस्तृत जानकारी के उसे व्यापक समर्थन मिला
- code के आकार, bug की कठिनाई, अतिरिक्त मेहनत की जरूरत, इस्तेमाल की गई programming language या framework जैसी मुख्य जानकारी छोड़ी गई, और केवल अत्यधिक सकारात्मक संदेश ही फैलाया गया
- ऐसे उदाहरण 1.8 हज़ार से अधिक प्रतिक्रियाएँ और 204 reposts दर्ज करते हैं, जिससे बढ़ा-चढ़ाकर किया गया marketing बहुत आसानी से फैल जाता है
उपयोग अनुभव और वास्तविकता की समझ
- लेखक भी Vercel के v0, Claude Code, Midjourney जैसे कई AI टूल्स का हर दिन उपयोग करते हैं
- Swift का ज्ञान न होने पर भी SwiftUI से monitoring app बनाना
- Midjourney से इवेंट के लिए poster अपने आप तैयार कराना
- Elixir आधारित MCP server functions को code करना जैसे अनुभव शामिल हैं
- लेकिन सफलता की संभावना लगभग 50% ही है, और परिणाम कभी भी लगातार एक जैसे नहीं होते
- कभी-कभी LLM सचमुच जादू जैसा महसूस होता है, लेकिन वास्तव में वह एक गैर-निर्धारक सांख्यिकीय model भर है
- लेखक का कहना है कि इस वास्तविकता के बावजूद, उद्योग की चर्चा अब भी द्वैध सोच (जादू बनाम engineering) तक ही सीमित है
निष्कर्ष
- LLM और AI के आसपास का परिदृश्य पक्की और स्पष्ट सत्यापन व्यवस्था के बिना बढ़ी-चढ़ी कल्पना, अपेक्षा और विश्वास को प्राथमिकता देता दिखता है
- आलोचनात्मक सोच को छोड़े बिना, कार्यक्षमता और प्रभाव की वास्तव में बारीकी से जाँच करने की कोशिश महत्वपूर्ण है
- इस बहस में सबसे जरूरी चीज़ ठोस और मात्रात्मक जानकारी साझा करना है
- LLM की सीमाओं और संभावनाओं को संतुलित नज़रिए से देखने की जरूरत है
1 टिप्पणियां
Hacker News राय
जहाँ मैं काम करता हूँ वहाँ के management को 10x productivity बढ़ोतरी वाली बातें सुनकर निराशा होती है। कुछ बातें तो हमारी कंपनी के शुरुआती adopters खुद भी कहते हैं। लेकिन ऐसी expectations बहुत ज़्यादा ऊँची हैं। इसमें Amdahl का नियम भी लागू होता है, क्योंकि मेरा ज़्यादातर समय coding में नहीं बल्कि सोचने और communication में जाता है। मान भी लें कि coding सचमुच 10x तेज हो जाए (जो ज़्यादातर मामलों में नहीं होता), तब भी कुल productivity बस 10~15% बढ़ेगी। फिर भी यह काफ़ी अच्छा नतीजा है, लेकिन 10x नहीं
शायद इसलिए कि मेरा मौजूदा काम थोड़ा ज़्यादा R&D जैसा है, LLM मुझे "सोचने" वाले हिस्से में भी "coding" जितना ही बड़ा फ़ायदा देता है (communication मैं खुद ठीक से संभाल लेता हूँ)। LLM के साथ सोचने का काम करना वैसा लगता है जैसे 20 साल पहले web search को master करना। पुराने search engines में मुझे पता होना चाहिए था कि क्या ढूँढना है, लेकिन अब LLM यह भी ढूँढ देता है कि क्या ढूँढना चाहिए (और मेरी जगह search भी कर देता है)। जो काम पहले मुश्किल श्रेणी में आते थे, वे अब LLM की वजह से आसानी से हल हो जाते हैं। अभी मैं अपनी web search का लगभग 1/3 ChatGPT o3 से करता हूँ। अब इसे छोड़ने की कल्पना भी नहीं कर सकता। इसके अलावा LLM मेरे अधूरे विचारों को व्यवस्थित करता है और चर्चा साथी बनता है, यह psychological factor भी बड़ा है। इसकी वजह से बहुत-से काम काफ़ी कम डरावने लगते हैं, और यह फ़र्क भी बड़ा है
मेरी कंपनी में भी स्थिति ऐसी ही है। internal शुरुआती adopters जो productivity gains बताते हैं, वे अक्सर बहुत संकीर्ण तरीके से मापे गए होते हैं, या उनका arithmetic ही थोड़ा ढीला होता है
LLM junior developers की तुलना में senior developers को ज़्यादा acceleration दे सकता है (क्योंकि juniors अच्छे/बुरे code में फ़र्क अच्छी तरह नहीं कर पाते)। अगर एक senior बेहतर LLM workflow इस्तेमाल करे, तो शायद वह पहले के दस juniors जितनी productivity दे सके। बल्कि कमज़ोर developers के मामले में productivity practically negative भी हो सकती है (क्योंकि वे senior का समय खा लेते हैं)। ठीक-ठाक junior भी वही repetitive काम करते रह जाते हैं जो LLM पहले से बेहतर करता है। इसलिए मुझे लगता है कि नौकरियाँ सचमुच ख़त्म हो सकती हैं
अगर LLM tools इस्तेमाल करने से productivity सिर्फ 10~15% बढ़ती है, और LLM tools की लागत की वजह से hiring cost 10~15% ज़्यादा महँगी हो जाती है, तो मुझे इसमें कोई ख़ास लाभ नहीं दिखता। मेरा मानना है कि कुल production cost को देखना चाहिए
personal projects में तो आसानी से लगभग 10x तक तेज़ी मिल जाती है। लेकिन कंपनी में कई teams के साथ चर्चा, requirements बदलना, PR review वगैरह के कारण यह माहौल फिट नहीं बैठता। ऐसा optimized design और standard patterns वाला setup छोटे startup या solo projects तक सीमित है। कई लोग जुड़ते ही consensus बनाना भी मुश्किल हो जाता है। AI को सर्वोत्तम नतीजे देने के लिए सब कुछ standardized होना चाहिए, लेकिन हक़ीक़त में हर चीज़ थोड़ी-थोड़ी अलग होती है, इसलिए असली organizations में उतना असर मिलना कठिन है। कुछ इच्छाशक्ति वाले developers मिलकर काम करें तो 10x भी संभव हो सकता है, लेकिन enterprise environment में यह लगभग असंभव है। मुझे लगता है AI middle management और project planning में ज़्यादा फिट बैठता है
लेखक जिस शिकायत करने वाले पक्ष की बात कर रहा है, वह मैं हूँ। जब ChatGPT अभी काफ़ी कमज़ोर था तब मैंने एक greenfield product launch किया। उसके बाद Claude और webchat~XCode के बीच copy-paste, फिर Cursor इस्तेमाल किया। build errors अक्सर आते थे, लेकिन फिर भी productivity कम से कम 3x हो गई। अब agent performance बेहतर हो गई है और Claude 4 भी आ गया है, इसलिए मैं coding लगभग नहीं करता। Architect/Manager की भूमिका में मैं अपनी expertise से सिर्फ agents को अच्छी तरह direct करता हूँ। startup में कई महीनों से मैंने खुद code की एक भी line नहीं लिखी। मैं खुद PR उठाने से पहले सब कुछ review करता हूँ, और testing भी अच्छी तरह करता हूँ, लेकिन Cursor+Sonnet का combination पागलपन की हद तक अच्छा है। line count जैसी चीज़ें मायने नहीं रखतीं, बल्कि पुराने codebase के अनुभवी experts मुझसे छोटे bugs के सवाल पूछते हैं। Claude की वजह से मैं frontend developer का काम भी छूने लगा था, इसलिए सावधान हूँ। मैं सिर्फ queries नहीं फेंकता, बल्कि बहुत बारीक research, planning और step-by-step exploration करवाता हूँ। domain knowledge ज़रूरी है। फिर भी यह देखना अजीब है कि कुछ लोग इसे इतना उपयोगी बना ही नहीं पाते। लगता है हर हफ़्ते ऐसे दो articles देखता हूँ
मेरा अनुभव भी ऐसा ही है, बस context थोड़ा अलग है (PhD student)। मैं LLMs को लेकर skeptical था, लेकिन Claude Code के बाद मेरा काम करने का तरीका पूरी तरह बदल गया। फिर भी curation पूरी तरह मेरी ज़िम्मेदारी है (यह PhD में सीखी जाने वाली एक अहम soft skill भी है, और LLM जल्दी goal या context खो देता है या उसे याद नहीं रखता)। अगर आप सटीक communication कर सकते हैं, तो CC के साथ computation को ऐसे organize किया जा सकता है जो पहले असंभव था। programming आसान नहीं होती, लेकिन एक बिल्कुल नया format बन जाता है
मुझे जानना है कि अविश्वसनीय LLM code को जल्दी inspect करने का तरीका क्या है, या LLM unit tests भी लिखता है या नहीं, average prompt length क्या है, यानी असली verification/inspection process कैसी है
यह भी सवाल है कि क्या आप LLM output पर तुरंत भरोसा कर लेते हैं। LLM पूरे project context को ठीक से नहीं समझ पाता, और उसमें hallucination बहुत होते हैं, इसलिए verification ज़रूरी है
मुझे लगता है LLM code quality कुल मिलाकर अभी भी काफ़ी कमज़ोर है। कई बार बार-बार corrections करवाने पड़ते हैं, इसलिए अक्सर खुद लिख देना ज़्यादा तेज़ होता है। लेकिन बड़े mechanical refactoring में agents बहुत उपयोगी हैं। जटिल vim macro या AST scripts लिखने के बजाय मैं agents का इस्तेमाल करता हूँ
कई महीनों तक खुद code की एक भी line न लिखना मुझे व्यक्तिगत रूप से बहुत boring लगेगा
इससे तो बस blog post में किए गए दावों (verification न होना, बहुत बड़े performance claims वगैरह) की फिर पुष्टि होती है। account भी नया बनाया हुआ लगता है
मेरे हिसाब से असली service industry labor का बड़ा हिस्सा Excel sheets में data इधर-उधर ले जाने, या CRM/email~Excel के बीच data transfer जैसी manual work में जाता है। बड़ी कंपनियों में ऐसे repetitive काम करने वाले full-time staff software engineers से शायद सौ गुना तक ज़्यादा होंगे। इसलिए अगर LLM OCaml नहीं कर पाता तो भी फ़र्क नहीं पड़ता; अगर वह Excel में इंसान से बस थोड़ा बेहतर हो जाए, तो बहुत बड़ी value बनती है। MCP जैसी चीज़ों से email-CRM-Excel को जोड़कर automation करने से error rate और hallucination भी बहुत कम हो जाते हैं। इंसान भी nondeterministic होते हैं, इसलिए ऐसे processes में determinism ज़रूरी नहीं है। LLM और crypto utility या adoption के मामले में पूरी तरह अलग हैं। यह smartphone adoption की याद दिलाता है। मेरे non-technical दोस्त भी अब LLMs को तरह-तरह से इस्तेमाल करते हैं
मुझे लगता है crypto से तुलना रचनात्मक नहीं है। तकनीकी रूप से दोनों का कोई संबंध नहीं। हाँ, technology overconfidence जैसा phenomenon ज़रूर है। जिन लोगों ने अब तक basic automation भी नहीं देखी, उन्हें LLM SF जैसा लग सकता है। यह क्षेत्र पहले कभी इतना mainstream नहीं हुआ। आगे चलकर यह success, failure, अलग-अलग opinions और real-world experience का wild west होगा। अच्छी बात यह है कि अब मेरे दोस्त का app idea भी वह खुद प्रयोग करके देख सकता है
manual data cleaning करने वाले FTEs (Full-time Employee) सिर्फ data नहीं सरकाते; उन्हें result verification, deadlines और legal responsibility भी निभानी होती है। LLM temporary exception cases (जैसे छुट्टी के दिन value 0 होनी चाहिए) को context के बाहर से पकड़कर check नहीं कर सकता। ऐसे verification के लिए एक FTE रखना पूरी तरह उचित हो सकता है
एक software engineer पर 100 manual data-pipelining FTEs वाली बात शायद कुछ खास कंपनियों पर ही लागू होती होगी। मुझे नहीं लगता कि असली back-office/data entry काम अधिकांश नौकरियों का हिस्सा है। AI के impact से मैं सहमत हूँ, लेकिन इस दावे पर संदेह है कि लगभग पूरी white-collar workforce बस email+data entry लोग हैं
मुझे लगता है आप इस तरह के roles की complexity को कम आँक रहे हैं
एक retired programmer के नाते, मैं probability से generated code को mission-critical ज़िम्मेदारी देने की कल्पना नहीं कर सकता। अगर थोड़े edits से काम चल जाए तो समझ सकता हूँ। coding के बाहर के क्षेत्रों (brainstorming, creative thinking, research support) में LLM चौंकाने वाले हैं। मैं LLM को एक thinking partner की तरह मानता हूँ। गलतियाँ होती हैं, लेकिन उन्हें दूसरे sources से verify करके या किसी दूसरे LLM से review करवाकर आसानी से पकड़ा जा सकता है
मेरा स्वभाव भी पूरी तरह skeptical है, लेकिन जब सच में इस्तेमाल किया तो यह हर तरह से उम्मीद से बढ़कर निकला। कुछ घंटों में ऐसे projects को prototype~launch तक पहुँचा दिया जिनमें महीनों लगते। जो चीज़ें मैं कर सकता था वे तेज़ हो गईं, और जो मैं नहीं कर सकता था (जिनके लिए outsourcing या hiring करनी पड़ती) वे भी मामूली लागत और तेज़ी से हो गईं। बेशक यह perfect नहीं है, और परेशान करने वाली बातें भी हैं (explicit instructions ignore करना, झूठ बोलना वगैरह), लेकिन मेरे लिए यह game changer है
LLM को thinking partner की तरह इस्तेमाल करना थोड़ी देर तक अच्छा लगता था, लेकिन किसी बिंदु पर उसकी delusion सामने आ जाती है। LLM बहुत अच्छे से यह भ्रम पैदा करता है कि वह knowledge या reasoning कर रहा है। खासकर उन क्षेत्रों में जिन्हें मैं नहीं जानता, यह और खतरनाक है। search engine में आप sources के आधार पर reliability compare कर सकते हैं, लेकिन LLM में वह नहीं होता। गलतियाँ पकड़ना भी हमेशा आसान नहीं होता
40 साल के experience वाला developer हूँ, और कुछ महीने पहले से LLMs इस्तेमाल करना शुरू किया है; इससे मेरा काम करने का तरीका बहुत बदल गया है। log error messages paste करो और 1 मिनट में fix, design brainstorming, नई solutions के सुझाव वगैरह। code verify तो करता हूँ, लेकिन इसकी accuracy और intelligence हर दिन चौंकाती है। (यह crypto जैसा बिल्कुल नहीं है)
मैं LLM skeptic हूँ, लेकिन सच यह है कि इंसानों द्वारा लिखा हर code भी मूल रूप से probabilistic ही होता है। इसलिए code review, unit tests, pair programming और guides मौजूद हैं। LLM हो या इंसान, किसी भी output को बिना आलोचनात्मक सोच के इस्तेमाल नहीं करना चाहिए। लेकिन मुझे चिंता है कि LLM कोई जादू नहीं है, और कहीं इसे सिर्फ boilerplate बढ़ाने के लिए misuse न किया जाए, जबकि efficiency, safety और refactoring जैसे long-term values को नज़रअंदाज़ कर दिया जाए
मेरे हिसाब से LLM जिस चीज़ में सबसे अच्छा है, वह data science है। IO साफ़ होता है, इसलिए result verification आसान है। अगर आप किसी खास data की characteristics जानते हैं, तो test code generate करवाना भी आसान है। जहाँ context चाहिए, वहाँ Claude Code बड़ा फ़र्क लाता है। उदाहरण के लिए PCAP file में हर UDP packet के अंदर multiple messages extract करना, filtering, pattern matching, testing के लिए अलग करना आदि। अगर आप कहें, "इन सभी functions के लिए unit tests लिखो," तो LLM self-verification तक कर सकता है
मैं एक साल से लगभग हर दिन LLM इस्तेमाल कर रहा हूँ, और 90% मामलों में यह मेरी समस्या हल कर देता है। मुझे समझ नहीं आता कि AI/LLM पर नकारात्मक राय को कब गंभीरता से लेना चाहिए। मेरे अनुभव में मैंने कभी पूरा codebase डालकर जादू की उम्मीद नहीं की; मैं सिर्फ सटीक और specific सवाल पूछता हूँ जिन्हें मैं जानता/समझता हूँ, और solution को verify किए जा सकने वाले तरीके से लागू करता हूँ। अगर आप ऐसा नहीं कर रहे, तो आप LLM का गलत इस्तेमाल कर रहे हैं। असली जादू देखने के लिए छोटे, रोज़मर्रा के, और consistent इस्तेमाल सबसे ज़रूरी हैं
Weatherman parody की तरह ताना मारा गया: "60% संभावना है कि यह हमेशा काम करेगा।" मैं भी GPT और Claude को Cursor के साथ हर दिन इस्तेमाल करता हूँ। GPT o3 general knowledge search के लिए अच्छा है, और Claude कई बार fail हो जाता है। model खुद थोड़ा बेवकूफ़ लगता है, लेकिन कभी-कभी सीधे मुद्दे पर भी पहुँच जाता है। अगर आपको खुद पता है कि क्या चाहिए, और आप LLM को ठीक से train/handle कर लेते हैं, तो इसे productive तरीके से इस्तेमाल किया जा सकता है
"मेरे अनुभव में यह 90% ठीक चलता है" जैसे दावे पर भी भरोसा करना मुश्किल लगता है
लगता है लेखक commentators की गलत टिप्पणियों से नाराज़ है। असल में मुझे लगता है कि LLM की समस्याएँ और सीमाएँ वही लोग सबसे अच्छी तरह जानते हैं जो रोज़ उससे टकराते हैं, यानी users=promoters। translation, transcription, code generation (एक तय scale तक) जैसी समस्याएँ, जो पहले असंभव या लगभग असंभव थीं, अब पूरी तरह या लगभग हल हो गई हैं
क्या translation, transcription, code generation सच में असंभव के क़रीब थे? Google Translate, Whisper जैसी चीज़ें तो बहुत पहले से थीं
असली flaws तो detractors ही उजागर करते हैं, जबकि promoters अक्सर LLM को बिना आलोचना के ऐसे पेश करते हैं जैसे वह हर चीज़ कर सकता हो
हाल में AGI और AI जैसे शब्दों का इस्तेमाल, खासकर scientific papers में, बहुत अस्पष्ट लगता है। कम-से-कम हर paper में अपनी definition साफ़ कर देनी चाहिए। अगर AGI की स्पष्ट definition हो, तो यह भी logically साबित किया जा सकता है कि कोई AI उस definition को पूरा करता है या नहीं। चाहे इसका practical उपयोग कम लगे, फिर भी यह अर्थहीन शब्दों से बेहतर है। अभी तो AGI बिना definition के ऐसे इस्तेमाल होता दिखता है जैसे लोग उससे बच निकलना चाहते हों। wiki में "लगभग सभी cognitive tasks में इंसान के बराबर या उससे आगे" जैसा लिखा है, लेकिन इसे measure करना असंभव है। फिर ऐसे खोखले शब्द का इस्तेमाल क्यों किया जाए, यही सवाल है
ज़रूरी नहीं कि सब लोग उसे एक ही मतलब में इस्तेमाल करें। AGI शब्द के लिए आपका अपना criterion हो सकता है (भले ही ज़्यादातर लोग उससे सहमत न हों)। मेरे लिए crypto का मतलब अब भी cryptography है। mainstream और मेरे personal criteria अलग हो सकते हैं
अगर AI की कोई definition है, तो वह यह है: "जिसे अभी तक हासिल नहीं किया गया, उसे AI कहा जाता है" — AI effect का लिंक
हाल ही में हमारी कंपनी ने LLM का इस्तेमाल शुरू किया। पहला काम था 20,000 customer support calls का transcription और data extraction (competing products, pain points, representative use cases आदि)। जो research पहले कई हफ़्ते लेती, वह कुछ घंटों में पूरी हो गई। हमने नई business strategy भी बनाई, और हमें सचमुच बड़ा value मिला। LLM natural language processing engine के रूप में बहुत शानदार है। hype बहुत है, लेकिन हमारे लिए यह वास्तव में उपयोगी है। यह बस एक tool है; मुझे नहीं लगता कि इसे किसी को साबित करने की ज़रूरत है
मुझे लगता है overhype पूरी तरह harmless नहीं है। इससे market distortion, overinvestment, downsizing, और अवास्तविक expectations जैसी नकारात्मक चीज़ें भी पैदा होती हैं। ऐसे articles market और expectations को ठंडा करने के लिए ज़रूरी हैं। LLM बेचने वाले लोग आम तौर पर support call summary की बात नहीं करते, बल्कि staffing replace करने वाले तरह-तरह के बढ़ा-चढ़ाकर बताए गए scenarios बेचते हैं
जिन लोगों ने बड़े पैमाने पर data को भरोसेमंद तरीके से process करने का अनुभव नहीं लिया, वही शायद कहते हैं कि LLM बेकार है। अब translation भी context के साथ कहीं बेहतर तरीके से हो पाता है
भरोसेमंद tech industry figures भी सीधे कहते हैं कि GenAI development productivity में बड़ी मदद करता है। इसका मतलब 5%~100% तक कुछ भी हो सकता है। कम-से-कम इसे एक काफ़ी उपयोगी tool के रूप में स्वीकार करना चाहिए। मुझे नहीं लगता कि इसके लिए code lines, bytes, CPU जैसी specific numbers ज़रूरी हैं
LLM technology का भी शायद सही इस्तेमाल कहीं होगा, लेकिन अब बहुत ज़्यादा लोग इसका misuse कर रहे हैं, इसलिए शायद अब वापसी नहीं है। असंख्य शुरुआती developers जोखिम लेकर नाकाम होंगे, और बहुत-सा investment बर्बाद होगा। कंपनियाँ भी हार नहीं मान सकतीं और सबने पूरी तरह all-in कर दिया है