AI: त्वरित हुई अयोग्यता
(slater.dev)- सॉफ्टवेयर इंजीनियरिंग में LLM पर अत्यधिक निर्भरता से अल्पकालिक गति बढ़ सकती है, लेकिन critical thinking और समस्या-समाधान क्षमता कमजोर हो सकती है
- गलत output से भी बड़ा जोखिम यह है कि त्रुटिपूर्ण prompts को ज्यों का त्यों स्वीकार कर लिया जाए, और उसके परिणामस्वरूप technical debt तथा उपयोगकर्ता क्षमता में गिरावट तेजी से जमा होने लगे
- LLM मौजूदा context window से आगे program theory को याद या आत्मसात नहीं कर सकता, इसलिए design और maintenance के लिए आवश्यक shared mental model मानव इंजीनियरों का क्षेत्र बना रहता है
- जटिलता maintenance की प्रक्रिया में लगातार बढ़ती रहती है, और text-level token predictor होने के कारण LLM अनावश्यक या अजीब बदलावों से program entropy बढ़ा सकता है
- AI को tool की तरह इस्तेमाल किया जा सकता है, लेकिन उस पर बैसाखी की तरह निर्भर नहीं होना चाहिए; 2019 में भी मूल्यवान मानी जाने वाली बुनियादी engineering क्षमता और गहरी सोच में निवेश जारी रहना चाहिए
LLM पर निर्भरता से पैदा होने वाले engineering जोखिम
- LLM को “मित्र” जैसा कहना, वास्तविक साथी से अधिक, उपयोगकर्ता को लाभ देने वाली एक सौम्य अभिव्यक्ति के करीब है
- इस दृष्टिकोण वाले इंजीनियर आम तौर पर गति को प्राथमिकता देते हैं, या उन पर गति को प्राथमिकता देने का दबाव होता है
- LLM बहुत सारा code तेज़ी से बना सकता है, लेकिन उसके उपयोग के साथ लंबे समय तक चलने वाले जोखिम जुड़े रहते हैं
कोड generation में दिखने वाले पाँच जोखिम
-
output जोखिम
- LLM ऐसे परिणाम दे सकता है जो साफ़ तौर पर गलत हों, जैसे compile न होने वाला code
- इससे भी अधिक खतरनाक स्थिति वह है जब परिणाम सूक्ष्म और पकड़ में मुश्किल गलतियाँ हों, जैसे logic bug
- जब prompt लिखने वाले के पास परिणाम का मूल्यांकन करने की योग्यता नहीं होती, तब जोखिम बढ़ जाता है
- उदाहरण के तौर पर project manager द्वारा source code माँगने की स्थिति आती है
-
input जोखिम
- LLM leading questions, गलत assumptions, या अधूरे context वाले prompts पर आपत्ति नहीं करता
- उदाहरण के लिए, “C# में thread-safe list implementation दो” जैसी request पर 200 पंक्तियों का भरोसेमंद दिखने वाला code मिल सकता है, जबकि असली सवाल यह हो सकता है: “इस code को thread-safe कैसे बनाऊँ?”
- इस स्थिति में उत्तर
System.Collections.Concurrentइस्तेमाल करने वाली एक पंक्ति का code हो सकता है - LLM इसे XY Problem का मामला नहीं पहचानता, क्योंकि उससे ऐसा करने को कहा ही नहीं गया
-
भविष्य की गति में गिरावट
- LLM codebase की गुणवत्ता को बहुत तेज़ी से गिरा सकता है
- मजबूत guardrails न हों तो LLM-generated code ऊपर से ठीक दिख सकता है, लेकिन भीतर से अस्वच्छ और गैर-कार्यात्मक जगह जैसा बन सकता है
- इसे सामान्य technical debt चर्चा से भी अधिक तात्कालिक समस्या माना गया है
-
उपयोगकर्ता का शैशवीकरण
- जिन व्यक्तियों और संगठनों में सोच और समस्या-समाधान LLM को सौंप दिया जाता है, वहाँ प्रतिभा घट सकती है
- senior engineers productive struggle के ज़रिए सीखने के अवसर खोते हुए समस्या-समाधान क्षमता और critical thinking को कमजोर कर सकते हैं
- junior engineers शुरुआत से ही ऐसी क्षमताएँ विकसित नहीं कर पाते, और बाद में भविष्य के juniors का mentoring करना भी कठिन हो जाता है
- ThoughtWorks Technology Radar Volume 32 बताता है कि AI-आधारित confidence कभी-कभी critical thinking की कीमत पर आता है
- Coding as Craft: Going Back to the Old Gym coding को craft के रूप में बचाए रखने वाली deliberate AI collaboration पर ज़ोर देता है
- Thoughts on Thinking का मत है कि LLM तैयार विचार दे सकता है, लेकिन स्वयं विकसित होने वाली बौद्धिक वृद्धि नहीं दे सकता
-
आनंद का ह्रास
- कई developers रिपोर्ट करते हैं कि AI का उपयोग flow state और सृजन के आनंद को छीन लेता है
- AI-generated code ऐसा code बन सकता है जिसे पढ़ना और बदलना कष्टदायक हो
- संबंधित लेख के रूप में The Hidden Cost of AI Coding जोड़ा गया है
दो क्षमताएँ जिन्हें LLM प्रतिस्थापित नहीं कर सकता
- कुशल इंजीनियर AI के कारण अनावश्यक हो जाएँगे, इस चिंता के संदर्भ में, LLM द्वारा न दी जा सकने वाली programming क्षमताओं को दो भागों में समेटा गया है
- वे क्षमताएँ हैं program theory और program entropy
Program theory: code ही program नहीं है
- Peter Naur का Programming as Theory Building programming को किसी समस्या के बारे में अंतर्दृष्टि या theory बनाने की गतिविधि मानता है
- Naur के दृष्टिकोण में program source code नहीं, बल्कि एक साझा मानसिक संरचना यानी theory या design है
- code उस design से निकला होता है, लेकिन मूल्यवान output code से अधिक design में होता है
-
दो टीमों का विचार प्रयोग
- समान क्षमता वाली दो टीमें A और B अलग-अलग कमरों में हैं और आपस में संवाद नहीं करतीं
- टीम A terminal-based chess game जैसा program लिखती है, और टीम B इंतज़ार करती है या सचमुच chess खेलती है
- टीम A के काम पूरा करने के बाद source code टीम B को दिया जाता है, और दोनों टीमों को virtual chess player जैसी functionality जोड़नी होती है
- बेहतर समाधान देने वाली टीम A होगी
- टीम A के पास अभी-अभी बनाए गए program का ताज़ा mental model है
- टीम B के पास ऐसा model नहीं है
- program प्रारंभिक generation के बाद लगातार बदला जाता है, इसलिए यदि केवल source code हो और design की आंतरिक समझ न हो, तो बदलाव की लागत बढ़ जाती है
- यह उस अनुभव से जुड़ता है जहाँ किसी बड़े existing codebase में पहली बार आने पर productivity लगभग शून्य के करीब होती है, और program theory दिमाग में बैठने के साथ productivity बढ़ती है
-
LLM और program theory
- मौजूदा LLM context window के आगे याद नहीं रख सकते, इसलिए वे theory, design, या mental construct में निपुण नहीं हो सकते
- program theory को प्राप्त और बनाए रखने वाला अस्तित्व मानव है
Program entropy: जटिलता को घटाने या उसका प्रतिरोध करने की क्षमता
- जटिलता programming के विरुद्ध काम करने वाली मूलभूत शक्ति है, और इसका संबंध entropy से है
- Fred Brooks की The Mythical Man-Month program निर्माण को entropy घटाने की प्रक्रिया और maintenance को entropy बढ़ाने की प्रक्रिया के रूप में देखती है
- Brooks के दृष्टिकोण में शुरुआती निर्माण के बाद program में किए गए बदलाव source code को और जटिल बनाते ही हैं
- हालांकि, design के साथ सामंजस्य रखने वाले बदलाव जटिलता बढ़ने की गति को धीमा कर सकते हैं
-
LLM और program entropy
- LLM एक token predictor है और केवल text स्तर पर काम करता है
- LLM ideas, diagrams, और requirements specification जैसे conceptual स्तर पर तर्क नहीं कर सकता
- जिसने भी LLM में code के बड़े हिस्से डाले हैं, उसने देखा होगा कि LLM अनावश्यक और अजीब बदलाव लागू करने की प्रवृत्ति रखता है
- बातचीत जितनी लंबी होती जाती है, परिणाम उतने अधिक भटक सकते हैं
- code की जटिलता घटाने या जटिलता का प्रतिरोध करने की क्षमता मनुष्यों के पास है
Engineering में AI का उपयोग कैसे करें
- यदि यह उम्मीद थी कि AI engineering career को अगले स्तर पर ले जाएगा, तो यह उल्टा भी काम कर सकता है
- LLM अयोग्यता को तेज़ कर सकता है, लेकिन मानव engineering का स्थान नहीं ले सकता
- AI का व्यावसायिक आकर्षण engineering को commoditize करके लागत घटाने में है
- लेकिन जैसे overseas engineering talent का उपयोग मिश्रित परिणाम देता है, वैसे ही LLM भी सीमाएँ और जोखिम साथ लाता है
- AI hype cycle अंततः अपने शिखर पर पहुँच सकता है
- जो कंपनियाँ अभी AI का अत्यधिक उपयोग कर रही हैं, वे लंबे समय तक चलने वाली लागत का बोझ उठाएँगी, और दिशा बदल सकती हैं या गायब हो सकती हैं
- engineering में मनुष्यों का दीर्घकालिक value proposition नहीं बदलता
- दुनिया को अब भी तकनीकी क्षमता और गहरी सोच की ज़रूरत है
- ऐसे कौशलों के लिए भुगतान किया जाएगा
- AI बना रहेगा, लेकिन इसका उपयोग tool की तरह होना चाहिए, बैसाखी की तरह निर्भरता के रूप में नहीं
- 2019 में मूल्यवान मानी जाने वाली बुनियादी engineering क्षमताओं में निवेश जारी रखना चाहिए
1 टिप्पणियां
Hacker News की रायें
कभी-कभी लगता है कि AI coding पर चर्चा software engineer और data scientist/machine learning engineer के फर्क को दिखाती है
दोनों ही अस्पष्ट requirements और पकड़ में मुश्किल bugs से जूझते हैं, लेकिन आम तौर पर software engineer ऐसा software बनाते हैं जिसे हमेशा एक खास तरीके से काम करना चाहिए, जहाँ reproducibility, tests और mature tools अहम होते हैं
दूसरी ओर machine learning engineer मूल रूप से probabilistic models से निपटते हैं, और testing भी किसी खास output के बजाय “90% मामलों में सही output” जैसे evaluation metrics पर केंद्रित होती है
इसलिए ऐसे AI से निपटने की सोच, जिस पर हमेशा भरोसा नहीं किया जा सकता, machine learning वालों को ज्यादा स्वाभाविक लगती है, और वे coding assistant को इस तरह आँकते हैं: “80% सही है तो मेरी मेहनत कम हो गई, बाकी 20% मैं पकड़ लूँगा”
Amazon में काम करते समय, machine learning-based solutions अक्सर उन real problems में खूब फिट बैठते थे जिनके लिए classical approaches नहीं थीं। उदाहरण के लिए grid map-based motion prediction या image/grid map classification मौजूदा estimation और control pipelines में अच्छी तरह integrate होकर उपयोगी रहे
इसके उलट, एक startup में मुझे एक junior manager लगातार इसलिए डाँटता था कि मैंने समय के साथ किसी stationary plane की orientation estimate करने की problem के लिए learning-based approach पर शक किया था। टीम को mapping या filtering की basics नहीं पता थीं और उसने मान लिया था कि “और data डालो तो हल हो जाएगा,” नतीजतन पूरी vehicle control pipeline flicker करती और उछलती arbitrary rotation estimates खा रही थी
यह gap वाकई बड़ा है, और काश interviews में इसे बेहतर तरीके से छाँटने का तरीका होता
पहले मैंने कंपनी के senior architect को एक meeting के बाद शिकायत करते सुना था कि हमारी कंपनी के products में accuracy और correctness हमेशा बड़े selling points रहे हैं, लेकिन दूसरे office की machine learning team इसे समझती नहीं थी और 80–90% accuracy को customers के लिए काफी मानती थी
यह pandemic disease की 1% fatality rate छोटी है या बड़ी, वाली बहस याद दिलाता है। 1 सबसे छोटा integer है, लेकिन 30 करोड़ लोगों का 1% 30 लाख लोग होते हैं
लेकिन मुझे नहीं लगता कि यह लेख सिर्फ उसी बारे में है। लेख software engineering करने वालों की meta-level चिंताओं और AI उसमें कैसे फिट बैठता है, इस पर है, और “program entropy” की बात करते हुए इसने असली मुद्दा पकड़ा है
software product बनाना काफी हद तक entropy management है। code और लोगों की संख्या बढ़ाते हुए भी सही गति से आगे बढ़ना, और यह सुनिश्चित करना कि हर कोई समझे कि हिस्से कैसे जुड़ते हैं और नए हिस्से कैसे जोड़े जाएँ। शायद किसी दिन AI इसे आसान बना दे, लेकिन अभी तो वह अक्सर entropy को और बिगाड़ देता है
अगर vested interests वाले लोग यह मनवाने की कोशिश न कर रहे होते कि “ऐसा नहीं है, AI हर चीज़ में तुरंत इस्तेमाल किया जा सकता है,” तो यह इतना बड़ा मुद्दा नहीं होता
यह assumption इतना बेतुका है कि logic से इसका खंडन करना भी मुश्किल है, और अब तक यह भारी investment खींचने और profit-focused workforce optimization को पैकेज करने वाली faith-based narrative के रूप में बेहद सफल रहा है
मैं लेख के premise और ज्यादातर ठोस arguments से strongly agree करता हूँ, लेकिन रोजमर्रा में LLM इस्तेमाल करते हुए इसके positive पहलू भी देखता हूँ। संदर्भ के लिए, software industry में करीब 30 साल काम किया है
AI-generated code से निपटने पर आप code पढ़ते हैं। development शुरू से creation की यात्रा कम और code reviews की एक series ज्यादा बन जाता है, और solo developer के लिए इसका फायदा यह है कि वह उन responsibilities की नकल करके सीख सकता है जिन्हें आम तौर पर team में ही सीखना आसान होता है
साथ ही LLM के साथ काम करने पर जल्दी साफ हो जाता है कि developer को problem को साफ और अच्छी तरह structured layers में समझना होगा। अगर आप कोई बड़ा काम एक साथ करा देते हैं तो आम तौर पर खुद ही नुकसान कर बैठते हैं, इसलिए design perspective से approach करना, detailed specs लिखना और parts के हिसाब से implement करना conceptual blocks की boundaries और interfaces तय करने में मदद करता है
LLM को junior developer के senior role में बढ़ने में मदद करने वाला powerful accelerator माना जा सकता है। सही guidance के साथ यह उन lessons की progression दिखा देता है जिन्हें ज्यादा experienced लोगों ने समय लगाकर सीखा। मुझे सब कुछ gloomy नहीं लगता, AI developers को replace भी नहीं करेगा, और अभी यह बहुत disruptive है लेकिन आखिरकार दूसरे tools के बीच कहीं अपनी जगह बना लेगा
LLM की मदद से बने code को review करने पर कहा जा सकता है कि आप ज्यादा bland code पढ़ते हैं, लेकिन फिर भी मुझे लगता है कि सीख होती है। मैंने काफी LLM-generated code पढ़ा है, और अक्सर unfamiliar idioms या ऐसी library calls सीखी हैं जिनके बारे में मुझे नहीं पता था
senior developers के लिए भी LLM और ज्यादा powerful accelerator है। वे जानते हैं कि क्या मौजूद है और क्या try करने की जरूरत नहीं, इसलिए बेहतर prompt कर सकते हैं
हाल की खबरें ही देखें तो Big Tech, mid-sized tech companies और छोटी tech companies में layoffs लगातार जारी हैं
याद है जब कहा जाता था कि 3D printing सारी manufacturing की जगह ले लेगी?
AI, singularity से ज़्यादा इसी भावना के करीब है
इसे ऐसे भी देखा जा सकता है कि LLM ने कुछ बेहतर नहीं किया, बल्कि सिर्फ़ systemic flaws उजागर किए; लेकिन असर तो साफ़ है। दो साल पहले जो दर्जनों lecture flows standard थे, वे अब काम नहीं करते
खासकर पूरी online/remote education इसमें शामिल है, और विडंबना यह है कि कई universities ने Covid के बाद जैसे ही इसमें निवेश शुरू किया, ठीक उसी समय ChatGPT आ गया। यह दुनिया भर की higher और secondary education के पूरे क्षेत्र के पैमाने का असर है
Aerospace इसका अच्छा उदाहरण है। SpaceX और इस क्षेत्र के युवा startups जो बहुत-सा काम कर रहे हैं, वह 3D-printed parts के बिना संभव नहीं होता। Nozzles, combustion chambers, turbopumps जैसे parts अक्सर print किए जाते हैं
फिर भी यह तुलना fair नहीं लगती। mechanical engineering के दिनों में 3D printing ने मुझे ज़्यादा तेज़ और सस्ते prototypes बनाने और गलतियां करने दीं, जिससे मेरी engineering skills उलटे बेहतर हुईं
इसने सारी manufacturing की जगह नहीं ली, लेकिन design में अहम भूमिका निभाई, और users की skills को degrade नहीं किया
LLM code लिखने में कमाल के हैं, लेकिन उस code को own और maintain करने में बेहद खराब हैं
हर वह line जिसे आपने समझे बिना स्वीकार किया है, borrowed understanding है, और maintenance के समय आपको उसका भारी ब्याज चुकाना पड़ता है। यह free speed जैसा महसूस होता है, लेकिन असल में यह लगभग 40% सालाना ब्याज वाले technical debt के करीब है
हमारे समूह को AI से typing automate करने, लेकिन सोच को automate न करने का तरीका खोजना होगा
लेकिन ऐसा नहीं है, और इसके काम करने के तरीके के कारण ऐसा हो भी नहीं सकता
इसलिए LLM की हर वह line जिसे समझे बिना स्वीकार किया गया, असल में ऐसी understanding है जो मौजूद ही नहीं है। वह सिर्फ़ probability model द्वारा निकाली गई code की एक line है, और जब तक कोई ऐसा अस्तित्व उसे न देखे जो codebase के context, system और design को सच में समझ सकता हो, तब तक वह अनसमझी ही रहती है। फिलहाल ऐसा अस्तित्व केवल humans माने जाते हैं
traditional development में मुझे ये दोनों खास पसंद नहीं हैं, लेकिन मौजूदा LLM इन्हें ज़्यादा आसान और उपयोगी बनाते हैं
और “rule of three” components के बीच असल में लागू होना बंद हो जाता है। code impact या तो local होना चाहिए, या फिर किसी बहुत robust foundational library का हिस्सा होना चाहिए। बीच वाले cases refactoring complexity को विस्फोटक बना देते हैं
“LLM प्रेरक prompts पर आपत्ति नहीं करता” वाला input risk अब तक सबसे बड़ा दर्द रहा है
इससे भी ज़्यादा झुंझलाहट वाली बात यह है कि मुझे खुद पता भी नहीं चल सकता कि मैं उसे किसी खास दिशा में ले जा रहा हूँ। LLM कैसे काम करता है, यह सोचें तो बात समझ में आती है, लेकिन अस्पष्ट रूप से लिखा गया सिर्फ एक शब्द भी नतीजे को गलत दिशा में झुका सकता है, और मेरी मंशा के उलट मुझे गलत rabbit hole में पहुँचा सकता है
जब तक एहसास होता है, तब तक मैं किसी तरह चल रहे, जैसे-तैसे जोड़े गए code की कीचड़ में बीचोंबीच खड़ा होता हूँ। इंसानी भाषा बहुत अस्पष्ट और non-specific है, इसलिए यह लगभग वैसा ही है जैसे हमने शुरुआत से ही precision की इजाजत देने वाली नियमबद्ध formal language इसी वजह से बनाई हो
निजी तौर पर AI tools की वजह से मुझे यह भी लगा कि मेरी skill तेजी से घट रही है। एक समय मैं आलसी होकर छोटे-छोटे कामों के लिए AI की तरफ हाथ बढ़ाता था, लेकिन एक कदम पीछे हटकर देखा तो समय भी खास नहीं बचा, बल्कि दर्जनों-सैकड़ों lines का code पढ़ते-पढ़ते, AI कहाँ गलत हुआ यह सोचते और ठीक करते-करते मैं कहीं जल्दी थक गया
मैंने मापा तो नहीं, लेकिन कुल मिलाकर लगता है कि AI tools से जितना समय बचा, उससे कहीं ज्यादा समय बर्बाद हुआ
असली समस्या यह है कि AI कई कामों में सचमुच उपयोगी है, लेकिन उसे इस्तेमाल करने वाले दो तरह के लोग हैं। एक तरफ वे लोग हैं जो इसे ऐसे जटिल कामों में इस्तेमाल करते हैं जहाँ छोटी गलतियाँ तेजी से जमा होती जाती हैं, और दूसरी तरफ मुख्यतः manager type लोग हैं, जो 200 lines का ऐसा code निकलते देख कर जिसे वे समझते नहीं, मुश्किल से चलने वाली TODO app जैसी चीज़ को “MVP” मान लेते हैं और सोचते हैं, “जब यह बना सकता है तो तुम्हारा काम भी आसानी से कर सकता है”
अगर आप यह आम जवाब देना चाहते हैं कि मैंने गलत इस्तेमाल किया या model गलत था, तो इन tools के साथ मेरे अनुभव के context के लिए पहले मेरा पुराना comment https://news.ycombinator.com/item?id=44055448 पढ़ लें
यानी AI मेरा assistant है, लेकिन quality वाली और maintainable output देने की जिम्मेदारी मेरी है
हालांकि आम नजरिये से देखें तो एक साधारण calculator के बारे में सोचिए। Calculator ने लोगों की mental arithmetic ability खराब कर दी। AI writing और communication skills, problem-solving ability आदि के साथ ऐसा ही करेगा
Models prompt flow में कहीं किसी खास keyword से चिपक जाते हैं, traditional logic छोड़ देते हैं, और मूल problem को ठीक से हल भी न करने वाले और संकरे रास्ते पर धकेल देते हैं। अंत में human side पर frustration और misery ही बढ़ती है
skill degradation रोकने के लिए मैं AI को केवल छोटे और स्पष्ट tasks में इस्तेमाल करने की कोशिश कर रहा हूँ, जिन्हें पहले StackOverflow search से हल करता था। “X कैसे करूँ?” search करने के बजाय model से वही सवाल पूछता हूँ, और उसके जवाब को सही उत्तर नहीं बल्कि problem-solving guide की तरह इस्तेमाल करता हूँ
फिर भी आज का AI कुछ चीजें आसान बनाता है। उदाहरण के लिए अगर इस्तेमाल करने लायक example हो, जैसे “इस page जैसा बनाओ, लेकिन y की जगह x data इस्तेमाल करो,” तो अक्सर documentation ढूँढ़ने से तेज होता है। hallucinate कर सकता है, यह caveat है, लेकिन समय के साथ बेहतर होने की संभावना भी बड़ी है
मैं जो सुधार देखना चाहता हूँ, वह कुल मिलाकर ज्यादा accurate होने के साथ-साथ यह है कि हर बार बताए बिना सबसे सरल समाधान ढूँढ़े। ChatGPT, Claude वगैरह को खुला छोड़ने पर सबसे बड़ी कमी यह है कि वे बहुत तेजी से ढेर सारा कचरा बना देते हैं और “यह बाद में handle करने के लिए बहुत complex हो जाएगा” कहकर रुकते नहीं। मूल लेख का दावा है कि पूरे design को समझने वाला human ही entropy का विरोध कर सकता है; यह हिस्सा हमेशा कभी improve नहीं होगा, ऐसा तो नहीं कह सकता, लेकिन अभी यही सबसे बड़ी समस्या लगती है
पहले round में आमतौर पर model जो main assumptions बना रहा होता है वे सामने आ जाते हैं, और वहाँ से narrow down करके स्पष्ट किया जा सकता है
कई कोशिशें की हैं, यह बताने वाला पुराना comment पढ़कर लगा कि आपका LLM experience मुझसे कहीं ज्यादा व्यापक है। लेकिन यह technique वहाँ नहीं दिखी, इसलिए अगर किसी के काम आए तो छोड़ रहा हूँ
“ideas, diagrams, requirements specification से inference नहीं कर सकता”, “complexity घटा सकने वाला सिर्फ human है” जैसी बातें किसी interesting concept के पीछे साफ तौर पर गलत detailed claims जुड़ जाने जैसी लगती हैं
यह बहुत आसानी से किया जा सकता है। बस उससे और सरल code माँगिए। मैं second opinion पाने के लिए इसे अक्सर इस्तेमाल करता हूँ और अच्छे results मिलते हैं
अगर आप model से query नहीं करेंगे, तो complex answer भी नहीं मिलेगा और simple answer भी नहीं। default option के रूप में query करना भी एक choice है; यह LLM की अवधारणा में inherent नहीं है
code और ideas/diagrams को एक-दूसरे में transform करने में भी मैं इसे अच्छे से इस्तेमाल कर रहा हूँ। लोग रोज़ practical use में जिन मजबूत दावों का खंडन कर रहे हैं, वे दावे वे क्यों करते हैं, समझ नहीं आता
लेख ऊपर-ऊपर से सही लगता है, लेकिन बारीकी से देखने पर टिक नहीं पाता, ऐसी अजीब logic भी दोहराता है। Naur वाली बात अब meme बन गई है और reality में insight की तरह दोहराई जाती है, लेकिन software engineering का एक और fundamental और practical rule भूल जाती है। कोई भी non-trivial program जल्द ही उस क्षमता से आगे निकल जाता है जिसमें एक व्यक्ति पूरी theory अपने दिमाग में रख सके
हम शायद ही कभी proper program theory के साथ काम करते हैं। Programming languages, techniques, methodologies, tools—सब इस दिशा में evolve हुए हैं कि लोग code के ज्यादातर हिस्से को समझे बिना भी बेहतर काम कर सकें
इस मामले में humans भी LLM जैसी limitations share करते हैं; फर्क बस इतना है कि हम एक अलग perspective पाने के लिए reasoning loop का एक और turn मिलने तक इंतजार करने को मजबूर नहीं होते, इसलिए इसे बेहतर manage कर लेते हैं
मुझे लगता है कि Google Maps या Apple Maps जैसी map technology पर भी इसी तरह का तर्क लागू किया जा सकता है। दावा यह है कि ऐसे tools इस्तेमाल करने से physical world में navigate करने की क्षमता, दिशा-बोध और भौगोलिक समझ कमज़ोर हो जाती है
सच कहें तो यह पूरी तरह गलत नहीं है। आजकल लोग अक्सर Google Maps जैसे सहारे के बिना रास्ता ढूंढने में मुश्किल महसूस करते हैं, और physical world से हमारा रिश्ता भी कई मायनों में बदल गया है
लेकिन पहले भी बहुत-से लोग रास्ता ढूंढने में खास अच्छे नहीं थे। खासकर अनजान इलाके में point A से point B तक सुरक्षित और भरोसेमंद तरीके से पहुंचने की औसत क्षमता निश्चित रूप से काफी बढ़ी है
और जिन कुछ लोगों में भूगोल और navigation की स्वाभाविक क्षमता थी, उनकी क्षमता Google Maps जैसे tools ने replace नहीं की, बल्कि complement की है
AI भी बड़े पैमाने पर शायद इसी तरह निकलेगा। trade-off जरूर होंगे और कुछ skills व क्षमताएं घटेंगी, लेकिन बहुत अधिक लोग वे काम कर पाएंगे जो पहले नहीं कर सकते थे, और कुछ लोग जो वे करते हैं उसे और बेहतर कर पाएंगे
बेशक हमेशा ऐसा नहीं होता। पूरी दुनिया को map करना अनगिनत exceptions और edge cases वाला बेहद जटिल काम है। लेकिन LLM output से तुलना करें तो फर्क बहुत बड़ा है। temperature को 0 पर रखकर वही prompt कई बार regenerate करने पर भी output काफी बदल जाता है
साथ ही LLM कहीं ज्यादा व्यापक conceptual scope को संभालते हैं, इसलिए लोग बहुत-सी ऐसी स्थितियों में, जहां उन्हें बिल्कुल ऐसा नहीं करना चाहिए, अपने दिमाग की जगह इसका इस्तेमाल करेंगे। maps में भी कुछ लोग Google Maps के रास्ता बताने पर झील में गाड़ी चला देते हैं; LLM output पर अंधविश्वास करके अपनी सोच को replace करने पर क्या होगा, इसकी कल्पना भी नहीं कर सकता
जहां मैं रहता हूं, वहां Google Maps 90% मामलों में taxi driver से बेहतर है
AI उस व्यक्ति से भी बेहतर नहीं है जिसने वह काम बस कुछ दिनों तक किया हो
वास्तविकता में 70% employees काम इतना आधे-अधूरे ढंग से करते हैं कि AI अक्सर उतना या उससे बेहतर कर लेता है
असली कठिनाई यह है कि जो लोग पहले से ही कामचलाऊ थे, वे AI इस्तेमाल करके भी बेकार ही रहते हैं, और बाकी लोग AI के साथ सीखते और बढ़ते हैं
full self-driving भी इसी तरह है। FSD खराब, नशे में या texting कर रहे human drivers से बेहतर है, और सड़कों पर ऐसे drivers बहुत हैं
मुझे जिज्ञासा है कि लेखक को यह एहसास कहां से मिला कि “[AI] conceptual level पर काम नहीं कर सकता”
हाल के LLMs ने बार-बार साबित किया है कि वे साफ तौर पर conceptual level पर काम कर सकते हैं, जैसे context के अनुसार एक भाषा की अवधारणाओं को दूसरी भाषा में सही तरह translate करना
यह कहना अलग बात है कि वे इंसानों की तरह concepts को “समझते” नहीं। चूंकि उसने दर्द का अनुभव नहीं किया, इसलिए वह दर्द को “समझ” नहीं सकता, लेकिन इंसान भी उन चीजों के बारे में लगातार बात करते हैं जिन्हें उन्होंने सीधे अनुभव नहीं किया। यह ठीक है या नहीं, वह अलग विषय है
यह association जैसी concept की कुछ विशेषताओं का कमजोर model है। उदाहरण के लिए “dog” का संबंध “cat” से है। लेकिन यह compositionality, intension, या counterfactual conditionals में terms की भूमिका जैसी चीजों को model नहीं करता
हालांकि अगर सवाल training data से मिलता-जुलता हो, तो सतही conceptual ability brute force करके पाई जा सकती है। अगर किसी ने “अगर कुत्ते Mars पर खेलें तो क्या वे खुश होंगे?” जैसा सवाल, या पर्याप्त रूप से मिलते-जुलते सवालों का समूह पूछा हो, तो “dog” को “literal facts” cluster और पहले से ज्ञात कुछ counterfactuals के cluster के आसपास रखा जा सकता है
इसके और असली मानसिक क्षमता के बीच फर्क देखने के लिए यह देखिए कि मनमानी गहराई वाले concept combinations अनंत हैं, और वे अनंत संख्या के counterfactuals से बने हो सकते हैं। केवल basic building blocks और imagination वाला बच्चा इस अनंत विविधता का मूल्यांकन कर सकता है
इसलिए LLMs सबसे ज्यादा उन संकरे क्षेत्रों में इस्तेमाल होते हैं जहां जरूरी “conceptual work” बहुत अच्छी तरह documented और पर्याप्त स्थिर है, खासकर software engineering में
90s.dev को AI-free community में बदलने का विचार मेरे मन में और मजबूत होता जा रहा है। यह ऐसी जगह हो जहां software अच्छी तरह लिखने की प्राचीन कला पर focus हो, और उस कला को निखारने वाले सभी लोगों का स्वागत हो
शुरू करने के लिए क्या चाहिए होगा? forum? mailing list? hackernoon की तरह कई authors के blogs को aggregate करने का तरीका?
रुचि रखने वालों के लिए अस्थायी mailing list मैंने https://github.com/sdegutis/90s.dev/issues/2 पर बनाई है, और उस विषय के emails पाने के लिए subscribe करें या comment कर दें
forums LLMs और bots की वजह से खराब हो चुके हैं, इसलिए वह विकल्प हट जाता है। ऐसी चीज काम करे तो उसे invite-only होना चाहिए, और हर referrer को अपने invite tree की जिम्मेदारी लेनी चाहिए
community इतनी अच्छी होनी चाहिए कि access खोने का डर अच्छा व्यवहार प्रेरित करे। online की कुछ खास communities में यह तरीका बहुत अच्छी तरह काम करता है