- AI-आधारित प्रोग्रामिंग टूल के रूप में LLM पहले ही सॉफ़्टवेयर डेवलपमेंट के कामकाजी माहौल में अनिवार्य स्थान ले चुका है
- कई परिचित मानते हैं कि AI एक अस्थायी ट्रेंड है, लेकिन लेखक ज़ोर देकर कहता है कि डेवलपमेंट के क्षेत्र में अब सोच बदलने का समय आ गया है
- कोडिंग एजेंट दोहराए जाने वाले और उबाऊ कामों को ऑटोमेट करके डेवलपर को अधिक अर्थपूर्ण काम पर ध्यान देने में मदद करते हैं
- AI से जनरेट हुए कोड की क्वालिटी, ओनरशिप, टूल सपोर्ट आदि पर विवाद हैं, लेकिन अधिकांशतः ये मौजूदा डेवलपमेंट वातावरण की समस्याओं की ही पुनरावृत्ति भर हैं
- LLM अपनाने के प्रति निष्क्रिय रवैया सही नहीं है, और यह संकेत देता है कि आगे और भी महत्वपूर्ण तकनीकी बदलाव आने वाले हैं
परिचय: AI, प्रोग्रामिंग, और संदेहवाद
- हाल में टेक कंपनी के एग्जीक्यूटिव LLM टूल अपनाने को मजबूर करने की प्रवृत्ति दिखा रहे हैं, लेकिन यह गलत रणनीति है
- लेखक के आसपास के स्मार्ट डेवलपरों में कुछ लोग AI को NFT जैसी अस्थायी लहर मानते हैं और इसे गंभीरता से नहीं लेते
- लेकिन वास्तविकता यह है कि LLM के अपनाए जाने से डेवलपमेंट क्षेत्र में बड़ा बदलाव पहले ही आ चुका है
- यह लेख सॉफ़्टवेयर डेवलपमेंट के भीतर LLM के अर्थ पर केंद्रित है, और कला, संगीत, लेखन जैसे अन्य क्षेत्रों पर चर्चा नहीं करता
LLM एजेंट और आधुनिक उपयोग के तरीके
स्तर मिलाना: पुराने LLM बनाम आज के एजेंट
- 6 महीने से 2 साल पहले ChatGPT या Copilot का साधारण उपयोग करने वाले दौर से अलग, अब विकसित LLM एजेंट माहौल तेज़ी से फैल रहा है
- आज के डेवलपर एजेंट को codebase को स्वतंत्र रूप से एक्सप्लोर और मॉडिफ़ाई करने देते हैं, जिससे फ़ाइल बनाना, compile करना, test करना और दोहराव वाले काम ऑटोमेट होते हैं
- code tree और बाहरी स्रोतों का कोड देना, Unix टूल-आधारित सूचना निकालना, Git इंटरैक्शन, और तरह-तरह के डेवलपमेंट टूल चलाना इसमें शामिल है
- वास्तविक code manipulation logic अपने आप में सरल system code है
- पहले की तरह ChatGPT में कोड कॉपी-पेस्ट करना मूलभूत बदलाव का अनुभव न कर पाने जैसा है
LLM के सकारात्मक प्रभाव
- अधिकांश प्रोजेक्ट में आने वाला सरल दोहराव वाला कोड LLM आसानी से जनरेट कर सकता है
- LLM बिना बार-बार search या documentation देखने के जानकारी संभालने में सक्षम है, और थकान से होने वाली अक्षमता से मुक्त है
- जब किसी नई language या environment की entry barrier के कारण इच्छित फीचर डेवलप करना शुरू करना मुश्किल होता था, तब LLM इस बाधा को बहुत कम कर देता है
- मेंटेनेंस-उन्मुख test code refactoring, dependency handling जैसे डेवलपमेंट के झंझट वाले काम LLM संभाल सकता है
- डेवलपर महत्वपूर्ण और रचनात्मक क्षेत्रों में अधिक ऊर्जा लगा सकते हैं
“LLM से बना कोड समझ में नहीं आता” दावे पर जवाब
- टीम में merge होने वाले कोड को खुद पढ़ना और स्टाइल के अनुसार बदलना स्वाभाविक बात है
- LLM जो कोड बनाता है वह "algorithmically" काफ़ी हद तक अनुमानित होता है, इसलिए आउटपुट को समझना और review करना संभव है
- अगर दोहराव वाले code review की क्षमता ही कमज़ोर है, तो इंसानी डेवलपर द्वारा लिखा अव्यवस्थित कोड भी समझ पाना मुश्किल होगा
“AI hallucination समस्या” पर नज़रिया
- LLM एजेंट code lint, compile, test तक चलाकर गलत जानकारी को सुधारते हैं और विश्वसनीयता सुनिश्चित करते हैं
- hallucination की समस्या अधिकांश वातावरण में काफ़ी हद तक पहले ही हल हो चुकी है
- इसे प्रभावी ढंग से इस्तेमाल करने के लिए सूक्ष्म निगरानी से अधिक ऑटोमेशन प्रक्रिया पर भरोसा ज़रूरी है
“AI कोड की क्षमता कमज़ोर है” आलोचना
- LLM सेवा की लागत इंटर्न के वेतन से सस्ती है (उदाहरण: Cursor.ai $20 प्रति माह)
- सीनियर डेवलपर की भूमिका कमज़ोर इंटर्न या LLM कोड की उत्पादकता बढ़ाने जैसी भी होती है
- कोडिंग एजेंट का उपयोग, tooling, और prompt design भी नई तकनीकी दक्षता के क्षेत्र हैं
- “कौन कौन-सा काम बाँटे” इस पर भ्रम है, लेकिन मूल रूप से डेवलपर दिशा, सत्यापन और निर्णय के लिए ज़िम्मेदार है
“Rust में AI प्रदर्शन कमज़ोर है” विवाद
- किसी खास language या tool के साथ compatibility की सीमा उस खास ecosystem की चुनौती है
- Go जैसी LLM-friendly language में AI का उपयोग बहुत ऊँचे स्तर पर है
- Rust के साथ तालमेल की समस्या LLM की समग्र सीमा नहीं है; भाषा-विशिष्ट रणनीति की ज़रूरत है
Craft और व्यावहारिक प्रोग्रामिंग
- सॉफ़्टवेयर डेवलपमेंट का उद्देश्य व्यावहारिक समस्या-समाधान है
- अनावश्यक रूप से code quality पर अटक जाना "yak-shaving" है, जो वास्तविक काम में अक्षमता पैदा करता है
- दोहराव वाले और झुंझलाने वाले काम LLM को सौंपकर डेवलपर को value creation वाले हिस्सों पर ध्यान देना चाहिए
AI कोड की साधारणता (“mediocrity”) को स्वीकारना
- अधिकांश कोड का बहुत असाधारण न होना व्यावहारिक रूप से कोई बड़ी समस्या नहीं है
- महत्वपूर्ण हिस्सों की गुणवत्ता बढ़ानी चाहिए, और बाकी हिस्सों में LLM के ज़रिए लागत बचत को फ़ायदे में बदलना चाहिए
- दोहराव वाले हिस्सों में LLM कोड अधिक सुरक्षित हो सकता है, और algorithmic क्षेत्रों में यह इंसान से अधिक व्यापक अप्रोच अपना सकता है
“AGI तक अभी बहुत समय है” दृष्टिकोण पर राय
- लेखक AGI बहस में रुचि नहीं रखता; असल में काम करता है या नहीं, यही महत्वपूर्ण है
- मौजूदा प्रदर्शन और उत्पादकता में वृद्धि ही फिलहाल निर्णय का आधार है
नौकरी-प्रतिस्थापन विवाद
- जैसे open source के प्रसार ने किया, वैसे ही LLM भी नौकरी भूमिकाओं में बदलाव और समाप्ति लाने वाली तकनीक है
- सॉफ़्टवेयर डेवलपरों को भी, अन्य उद्योगों की तरह, यह समझना होगा कि वे ऑटोमेशन के दायरे में हैं
- यह बदलाव अंततः लाभदायक होगा या हानिकारक, यह अनिश्चित है; लेकिन बदलाव स्वयं अपरिहार्य है
साहित्यिक चोरी/कॉपीराइट मुद्दा
- AI दृश्य कला जगत के लिए एक बड़ा ख़तरा बन रहा है
- वास्तव में LLM industrial quality वाले परिणाम बड़े पैमाने पर पैदा कर सकता है
- सॉफ़्टवेयर डेवलपरों के लिए plagiarism को बड़ा मुद्दा बनाना मुश्किल है
- पहले से ही डेवलपर कॉपीराइट के प्रति कम संवेदनशील रहे हैं, और बौद्धिक संपदा संरक्षण से अधिक साझा करने और पुनरुत्पादन को प्राथमिकता देते आए हैं
- कोड के कुछ हिस्सों के पुन: उपयोग पर विवाद एक तरह का विशेष बहाना भर है
नवीनतम LLM उपयोग और बदलाव की रफ़्तार
- LLM-आधारित asynchronous agent उपयोग और parallel काम के कारण उत्पादकता में बड़ा सुधार हुआ है
- बेहतरीन डेवलपर भी LLM से code review और सुधार करवाते हुए, स्थिर न रहने वाले वातावरण में वास्तविक उपयोगिता का अनुभव कर रहे हैं
- महत्वपूर्ण infrastructure access जैसे trust वाले क्षेत्रों को अब भी सावधानी से संभालना चाहिए
निष्कर्ष: तकनीकी बदलाव और संदेहवाद से आगे
- पारंपरिक AI संदेहवादियों से अलग, लेखक संयमी दृष्टिकोण रखते हुए भी वास्तविक बदलाव को महसूस कर रहा है
- सॉफ़्टवेयर डेवलपरों के लिए पुरानी आपत्तियों से आगे बढ़कर व्यावहारिक बदलाव को स्वीकार करने का समय आ गया है
- LLM और AI-आधारित प्रोग्रामिंग से वैसा ही उद्योग-स्तरीय बुनियादी ढांचा परिवर्तन आने की संभावना है जैसा कभी स्मार्टफ़ोन और इंटरनेट ने किया था
4 टिप्पणियां
एक बार इस्तेमाल होने वाली साधारण scripts लिखते समय यह निश्चित रूप से उपयोगी है। इससे बहुत समय बचता है
ऐसे मामलों में भी यह काम आता है जहाँ समाधान करना ज़रूरी है, लेकिन बहुत अधिक समय निवेश नहीं किया जा सकता। हालांकि, अभी यह ज़्यादातर उपयोगी है, पर इंसानों की पूरी तरह जगह नहीं ले सकता। आगे यह कितना विकसित होगा, पता नहीं, लेकिन फिलहाल assistant के रूप में यह काफ़ी हद तक इस्तेमाल लायक स्तर पर है।
मेरे AI-भक्त हों या संशयवादी, अगर वे बहुत चरम पर हों तो उनसे दूरी बनाना मन करता है।
हर बार जब लोग चिल्लाते हैं कि "singularity आ रही है", तो सच में बहुत थकान होती है।
Hacker News राय
अगर आपने 6 महीने पहले LLM से कोड लिखवाने की कोशिश की थी और वह असफल रही, तो इसका मतलब बस इतना है कि वह तरीका उन ज़्यादातर डेवलपर्स के तरीके से अलग था जो LLM को गंभीरता से उपयोग कर रहे हैं। लेकिन मैं अब तक उन आवाज़ों को लेकर संशय में रहा हूँ जो लगातार कहती रही हैं कि यह तकनीक क्रांतिकारी है। 6 महीने पहले भी कहा जाता था कि अगर आप सबसे नया LLM नहीं इस्तेमाल कर रहे हैं, तो आप पुराने मॉडल पर हैं और उसे सही तरह से उपयोग नहीं कर रहे। लेकिन अब माहौल ऐसा है कि सब मान रहे हैं कि पुराने LLM खास अच्छे नहीं थे। यह लगातार बहानों के दोहराव वाले 'AI लड़का आया' जैसी घटना लगती है। इस बार भी कहा जा रहा है कि काम की उत्पादकता नाटकीय रूप से बढ़ रही है, लेकिन किस आधार पर मानूँ कि इस बार का दावा सच में सही है? मेरा अनुमान है कि 6 महीने बाद फिर यही कहा जाएगा कि अभी तक जिन LLM प्रोडक्ट्स का इस्तेमाल हो रहा था, वे भी खास नहीं थे.
घातीय फ़ंक्शन का ग्राफ हर बिंदु पर लगभग एक जैसा दिखता है। कुछ समय तक कंप्यूटर हर साल बहुत बेहतर होते गए, और इसका मतलब यह नहीं था कि नया खरीदा गया कंप्यूटर कबाड़ था, बल्कि यह कि तकनीक सचमुच तेज़ी से आगे बढ़ रही थी। आप जो यह लगातार सुधार से थकान महसूस कर रहे हैं, वह भी वास्तव में क्रांतिकारी प्रगति का ही परिणाम है — ऐसा नज़रिया पेश किया गया
अगर 0 साल से 30 साल की उम्र तक हर 6 महीने में किसी इंसान से मदद माँगी जाए, तो आप कब प्रभावित होंगे? यह इस पर निर्भर करेगा कि आप किससे पूछ रहे हैं और काम क्या है, लेकिन समय के साथ ज़्यादा से ज़्यादा लोग उसकी क्षमता से प्रभावित होंगे। LLM का विकास भी किसी बच्चे को बड़ा होते देखने जैसा है। मैंने भी पहले LLM का उपयोग नहीं किया था, लेकिन o3 और Gemini 2.5 Pro के बाद से लगातार उपयोग कर रहा हूँ। अगर आपने नए मॉडल खुद आज़माए हैं और अभी तक प्रभावित नहीं हुए, तो मुझे भरोसा है कि 3 साल के भीतर आप ज़रूर होंगे
tptacek ने 6 महीने पहले ऐसा दावा नहीं किया था। LLM समय के साथ लगातार बेहतर होते हैं, और कभी-कभी वे उन सीमाओं को भी तोड़ देते हैं जहाँ पहले वे काम नहीं करते थे। पिछले 6 महीनों में 'एजेंट-आधारित कोडिंग' ने वास्तव में काम करना शुरू किया है। "हर 6 महीने में कहते हैं कि यह बेहतर हो गया, इसलिए मैं इसे गंभीरता से नहीं लूँगा" जैसी मानसिकता तकनीक का सही मूल्यांकन करने की क्षमता को कमज़ोर कर सकती है
एक राय यह है कि समस्या का सार 'इन्फ्लेक्शन पॉइंट' में है। कुछ लोग सिर्फ़ ChatGPT में कोड पेस्ट करके संतुष्ट नहीं होते, जबकि दूसरे लोग ऐसे एजेंट से बहुत बेहतर परिणाम पाते हैं जो पूरे कोड कॉन्टेक्स्ट को देख सकता है। अंततः सिर्फ़ किसी खास LLM का नहीं, बल्कि workflow के अंतर का महत्व है
मुझे Thomas की दलील पसंद है, लेकिन मुझे लगता है कि उसमें भी वही मूलभूत गलती है जो लोग अक्सर करते हैं। अच्छे प्रोग्रामर को LLM का अच्छा उपयोग करना सीखने के लिए लंबे अनुभव की ज़रूरत होती है, और Thomas ने भी समय के साथ विशेषज्ञता हासिल की है। लेकिन शायद वह आख़िरी पीढ़ी से है जो LLM सहायता के बिना बड़ी हुई। अभी-अभी कॉलेज से निकला कोई शुरुआती व्यक्ति 'vibe coding' से बाहर आकर असली कौशल कैसे विकसित करेगा, यह सवाल है। पहले लोग अपने हाथों से चीज़ें बनाकर बढ़ते थे, लेकिन अब ख़तरा यह है कि पूरा डिज़ाइन और असेंबली रोबोट को सौंप दी जाए और लोग यह सीखे बिना रह जाएँ कि असली औज़ार और सामग्री कैसे काम करते हैं। बात यहाँ तक पहुँच सकती है कि छत कितना भार सह सकती है, यह भी सिर्फ़ 'अंदाज़े' से ही समझा जाए
एक राय यह है कि AI एजेंट की ताकत तब साफ़ दिखती है जब कोई विशेषज्ञ LLM द्वारा लिखे गए कोड को पढ़ सके, समझ सके और codebase में integrate कर सके। लेकिन अगर हर कोई AI से कोडिंग करने लगे, तो ऐसे असली 'editor' कैसे तैयार होंगे जो लगातार जटिल होता जा रहा कोड पढ़ सकें, जोखिम पहचान सकें, यह जान सकें कि कहाँ और कैसे test करना है, और पूरे codebase की संरचना दिमाग़ में रख सकें? आज के editor के लिए ज़रूरी ये कौशल आमतौर पर लंबे समय तक खुद कोड लिखने से आते हैं। अगर शुरुआती लोग अपनी सोच outsource कर देंगे, तो उन्हें यह क्षमता विकसित करने का मौका ही नहीं मिलेगा। फिर अनुभवी लोग आएँगे कहाँ से — यह भी चिंता है। एक professor के रूप में यह बात कड़वी लगती है कि homework और assignments अब LLM के सहारे बिना सोचे-समझे पार हो जाते हैं। शायद नए तरह के skill development की ज़रूरत है, लेकिन अभी कुछ सूझता नहीं, और ऐसे संसार में शुरुआती लोग विशेषज्ञ कैसे बनेंगे यह स्पष्ट नहीं है
इसका जवाब दिया गया कि अगर सब calculator ही इस्तेमाल करेंगे तो गणित कैसे सीखेंगे? छात्रों को पहले हाथ से काफ़ी अभ्यास करवाना चाहिए, मूल बात समझानी चाहिए, और उसके बाद ही calculator की तरह LLM लाना चाहिए
Isaac Asimov की लघुकथा "Profession" याद आने का अनुभव साझा किया गया। उसमें ज़्यादातर लोगों को उनकी क्षमता और पेशा सीधे कंप्यूटर से मिल जाता है, इसलिए वे काम तो अच्छे से करते हैं, लेकिन innovation और creativity विकसित नहीं कर पाते। उल्टा, वही कुछ लोग जो इस तकनीक में फिट नहीं बैठते, सच में सीखते हैं और कला-जगत को आगे बढ़ाने वाले अकेले समूह बनते हैं
मेरे अनुभव में LLM एक pair programmer के ज़्यादा करीब है, और शुरुआती के लिए यह किसी senior engineer जैसा हो सकता है। यह सिर्फ़ कोड ही नहीं, बल्कि सिद्धांत और प्रक्रिया भी अच्छे से समझाने वाला tutor है। senior लोगों के लिए यह code review, idea brainstorming, boilerplate संभालने जैसी कई सुविधाएँ देता है। विशेषज्ञ के नज़रिए से केवल 10% कठिन काम पर खुद ध्यान देना और बाकी साधारण काम LLM को सौंप देना समय बचाता है। अगर कोई शुरुआती बिना रुचि या जिज्ञासा के सिर्फ़ कोड उतारता है, तो वह डेवलपर की समस्या है; लेकिन जो सच में सीखना चाहता है, उसके लिए LLM सबसे बेहतरीन learning resource है। उस अर्थ में शुरुआती लोगों के लिए यह सबसे अच्छा समय है
यह पूरी thread कुछ इस तरह के क्लासिक मनोवैज्ञानिक चरण दिखाती लगती है: "समस्या है ही नहीं — है, लेकिन बड़ी बात नहीं — ओह, सच में है, चलो अनुकूल हो जाते हैं"। लगता है कि इसने असली मुख्य समस्याओं में से एक को छू लिया है
मैं भी इस बात से सहमत हूँ कि अगर कोई शुरुआती LLM पर पूरी तरह सोचने के लिए निर्भर हो जाए, तो उसकी क्षमता बढ़ना मुश्किल है। फिर भी, मैं खुद LLM के ज़रिए लगातार नई चीज़ें सीखता हूँ। मैं किसी API पर ऐसे सवाल पूछता हूँ जिसे मैं बस मोटे तौर पर जानता हूँ, फिर उसके उत्तर पढ़कर अवधारणा समझता हूँ, और आमतौर पर कोड को खोलकर बदलता और refactor करता हूँ। कुछ दिन पहले मुझे signals के अंदरूनी कामकाज को लेकर जिज्ञासा हुई, तो LLM ने उदाहरण दिए और हमने उन्हें साथ में विश्लेषित किया। अगर जिज्ञासा हो, तो यह अविश्वसनीय tutor बन सकता है। juniors को सिर्फ़ 'vibe coding' नहीं करनी चाहिए, बल्कि सक्रिय रूप से सीखने की मानसिकता रखनी चाहिए। अगर वे ऐसा नहीं करते तो वह उनकी अपनी ज़िम्मेदारी है, और इस अब अपरिवर्तनीय वास्तविकता में जिज्ञासा हो तो आगे बढ़ने के रास्ते काफ़ी हैं
हाल में Claude 4 एजेंट जैसी चीज़ों का उपयोग करके मैंने कई तरह के मामलों में कोशिश की: बड़ा C codebase (नई सुविधाएँ, bugfix), छोटा Rust प्रोजेक्ट, छोटा frontend, बेसिक API docs वाले नए frontend आदि। हर मामले में अनुभव पूरी तरह असफल रहा। diff ग़लत मिला, tools को ग़लत arguments भेजे, बुनियादी काम भी असफल हुए, सैकड़ों लाइनों में बेवजह refactor किया, अधूरे refactor छोड़ दिए और पूरे codebase को बिखरा दिया। Svelte, solidJS जैसे data-rich JS frameworks में भी नतीजे ख़ास नहीं थे। समझ नहीं आता कि जिन एजेंट्स की लोग इतनी तारीफ़ करते हैं, उनकी असली ताकत क्या है; उल्टा यह सब marketing exaggeration जैसा लगता है
एक राय में पूछा गया कि prompts कैसे लिखे गए थे। आम तौर पर अगर एक feature को और छोटे, ज़्यादा बारीक tasks में तोड़कर LLM को दिया जाए तो यह कहीं बेहतर काम करता है। अलग-अलग tasks (10 से 200 लाइनों के भीतर) यह अच्छी तरह संभाल लेता है, लेकिन उससे ज़्यादा होने पर follow-up काम और निराशा बढ़ती जाती है। अभी का स्तर ऐसे autonomous intern जैसा है जो smart तो है, लेकिन अनुभवी नहीं। high-level समग्र architecture और planning अब भी इंसान को ही करनी पड़ती है
एक परिकल्पना यह भी है कि एजेंट्स का प्रचार करने वाले लोग खुद भी spaghetti code ही बना रहे हैं, लेकिन उन्हें बस अपनी productivity बढ़ने से मतलब है। ऐसे ठोस success cases कम हैं जहाँ लोग tools और methods तक विस्तार से साझा करें, जबकि यह documentation भी AI से करवाई जा सकती थी, पर ऐसा भी नहीं किया जा रहा
दावा किया गया कि एजेंट्स पर लिखे गए कई लेख प्रचार सामग्री जैसे लगते हैं। AI बाज़ार में बहुत ज़्यादा पैसा लगा हुआ है, और पिछले marketing उदाहरण याद आने से भरोसा और कम होता है। कई एजेंट प्रोडक्ट्स खुद इस्तेमाल करने पर भी वास्तविक सुधार कम लगा। HN पर वैसे भी AI से डरने वाले निराशावादी बहुत हैं, इसलिए अगर बहस ज़्यादा हो तो माहौल ऐसा बन जाता है कि गलती शायद user की ही है। एक user ने तो यह तक कहा कि "AI को सच में समझने के लिए 1000 डॉलर तक खर्च करके इस्तेमाल करना चाहिए", जिस पर विज्ञापन जैसी गंध आने की बात कही गई
अगर LLM को छोटे कोड, एकल फ़ाइल, या 50 लाइनों से कम जैसे सीमित बदलाव तक रोका जाए, तो उसे manage करना आसान होता है
90 के दशक से कोडिंग सीखने वाले व्यक्ति के रूप में, यह तथ्य ही विस्मयकारी लगता है कि अब कंप्यूटर को अस्पष्ट और धुंधला input देकर भी उपयोगी परिणाम मिल सकते हैं। सिर्फ़ मानव-स्तर की अस्पष्टता के आधार पर स्पष्ट और काम के output मिलना SF जैसा लगता है
उल्टा यह भी होता है कि बहुत स्पष्ट input देने पर भी कंप्यूटर उसे ऐसा बना देता है कि वह अपने लिए आसान किसी और अस्पष्ट समस्या में बदल जाए
मेरे लिए LLM की यही अस्पष्टता दस्तावेज़ों के साथ बातचीत के उपयोग में आकर्षक है। मनचाही जानकारी पाने के लिए बार-बार search terms बदलने की ज़रूरत नहीं पड़ती, इसलिए कुल मिलाकर समय बचता है
यह सचमुच अद्भुत समय है — ऐसा आश्चर्य कि हफ़्ते में 1–2 बार भी वास्तविकता पर हैरानी होती है
मैं Star Trek: The Next Generation का fan था, और Enterprise के कंप्यूटर तथा Data के बीच के अंतर की कल्पना करके अक्सर चकित होता था। Enterprise का कंप्यूटर आज की AI की तरह ज्ञान व्यवस्थित कर सकता था, सारांश दे सकता था और काम कर सकता था, जबकि Data एक व्यक्तिगत कौशल वाला robot था। Data की humor और art जैसे मानवीय क्षेत्रों में सीमाएँ आज के AI art जैसी लगती हैं। शो की शुरुआती सूक्ष्म सेटिंग और प्रगति भी याद आती है
मैं इस उद्योग में इसलिए आया था क्योंकि मशीन को स्पष्ट निर्देश देकर बिल्कुल वही परिणाम मिलते थे जो चाहिए। Dijkstra ने बहुत पहले ही मानव भाषा की अस्पष्टता और उसे पार करने के लिए बने 'formal language' के महत्व पर ज़ोर दिया था। और अब 2025 में हम उस दौर में हैं जहाँ कंप्यूटर से बहस करते हुए prompt engineering या vibe coding के ज़रिए उसके रूप को सुधारना पड़ता है — इस पर आत्म-व्यंग्य भी है। EWD667: The Humble Programmer पढ़ने की सिफ़ारिश की गई
जो लोग generative AI की असीमित क्षमता की बात करते हैं, उनसे सवाल है कि क्या वे कोई वास्तविक सबूत दिखा सकते हैं। अगर GAI या एजेंट्स सच में इतने शक्तिशाली हैं, तो सिर्फ़ AI के दम पर कंपनी बनाकर कम समय में बहुत उच्च-गुणवत्ता वाला विशाल कोड तैयार करके यह साबित किया जा सकता है। लेकिन व्यवहार में ऐसा कोई संकेत नहीं दिखता। अभी तक सबसे उपयोगी उपयोग यही रहा है कि यह ऐसा text और art बना देता है जिसे इंसान गलती से अर्थपूर्ण समझ ले। startups के वास्तविक उपयोग अनुभव में यह कभी-कभार API खोजने या सुविधाजनक जानकारी पाने तक ही काम आया। कुल मिलाकर समय की बर्बादी ज़्यादा रही। अब सिर्फ़ 'यह अच्छा है' कहने के बजाय, AI द्वारा ख़ुद बनाए गए परिणाम सीधे दिखाने का समय आ गया है
एक राय है कि यहाँ लोगों के नज़रिए अलग-अलग हैं। हमेशा से एक threshold रहा है — एक तरफ़ वे बदलाव जो व्यवहार्य थे, यानी मेहनत के मुक़ाबले असर देने वाले, और दूसरी तरफ़ backlog में पड़े वे काम जो कभी शुरू ही नहीं होते। AI tools उस threshold cost को घटा देते हैं, इसलिए ज़्यादा काम आज़माए जा सकते हैं। इसीलिए "5x productivity" कहने वाले लोग असल में processed code volume बढ़ने पर ज़ोर देते हैं, जबकि skeptics मानते हैं कि business का मूल मूल्य उतना नहीं बदला। AI उत्पादकता का विरोधाभास भी देखने की सिफ़ारिश की गई
पूछा गया कि आप आख़िर किस तरह का सबूत देखना चाहते हैं। क्या आप असीम क्षमता का प्रमाण चाहते हैं, या बस व्यावहारिक उपयोगिता का? व्यवहार में कोई भी पूर्ण सर्वशक्तिमान नहीं है, लेकिन जो लोग इसकी सीमाएँ और ताकत ठीक से समझते हैं, उनके लिए यह उपयोगी है — इस बात पर ज़ोर दिया गया। उदाहरण के तौर पर हाल की cloudflare/workers-oauth-provider commit history भी दी गई और पूछा गया कि क्या कम से कम "थोड़ा-बहुत उपयोगी" होने पर सहमति नहीं हो सकती
लोग पहले से ही LLM द्वारा बनाए गए कोड का अपने स्तर पर उपयोग कर रहे हैं। LLM-सहायता वाले PR कई महीनों से वास्तविक production में जा रहे हैं — ऐसा अनुभव साझा किया गया। साथ ही सलाह भी दी गई कि अगर आपको अभी तक उपयोगिता नहीं मिली, तो हो सकता है आपने इसे प्रभावी ढंग से उपयोग करना नहीं सीखा हो
जो लोग प्रचार करते हैं कि LLM बेकार है, उन्हें देखकर भी कभी-कभी लगता है कि कोई अलग तरह की marketing चल रही है। जिन कंपनियों पर पहले भरोसा था, वे भी हाल में AI प्रचार पर ज़्यादा झुकी दिखती हैं, यह निराशाजनक है। लेकिन अगर असली लाभ है, तो माहौल यही है कि लोग उसे खुद इस्तेमाल करके देखें
"gold rush में फावड़ा बेचने वाले व्यापारी" वाली उपमा दी गई। बात यह कि उपकरण की वास्तविक क्षमता साबित करने के बजाय लोगों को सिर्फ़ यह यक़ीन दिलाया जा रहा है कि कहीं सोना पड़ा है
Github कोड लाइसेंस मुद्दे की अनदेखी करने वाले रवैये की आलोचना की गई। कुछ डेवलपर्स कहते हैं कि "copyright की चिंता मत करो", लेकिन यह मान लेना कि सारे प्रोग्रामर copyright उल्लंघन करने वाले अपराधी हैं, ग़लत सामान्यीकरण है। मेरे जैसे कई डेवलपर्स बड़े पैमाने की piracy से कोई संबंध नहीं रखते, बल्कि copyleft और open source की भावना को बचाने की कोशिश करते हैं। SciHub को सार्वजनिक हित मानते हुए भी, व्यक्तिगत डेवलपर की copyleft मंशा का सम्मान किया जाना चाहिए। copyright कोई सरल पक्ष/विपक्ष का मुद्दा नहीं है। इस विविधता और संदर्भ को नज़रअंदाज़ करके सबको एक साथ दोषी ठहराना, या लाइसेंस की अनदेखी को सही ठहराना, वही असली बौद्धिक आलस्य है
अक्सर प्रोग्रामर क़ानून, ख़ासकर अमेरिकी common law/civil law परंपरा को ठीक से नहीं समझते। क़ानूनी परंपराएँ लंबे समय से इस धारणा पर बनी हैं कि इंसान उनका तर्कसंगत अर्थ लगाएगा, और चाहे AI tools ज़िम्मेदारी को बाँटने या छिपाने के लिए बनाए गए हों, अंततः क़ानून किसी ज़िम्मेदार इंसान को ढूँढकर दंडित करेगा। AI boom के बाद की वास्तविकता शायद यह होगी: 1) कंपनियाँ और राज्य ज़िम्मेदारी बिखेरने की कोशिश करेंगे, 2) दुष्प्रभाव वाली घटनाएँ होंगी — कार दुर्घटना, पक्षपाती algorithm, data leak आदि, 3) अदालतें ज़िम्मेदारी इंसानों पर डालेंगी और जुर्माना या सज़ा देंगी, 4) दूसरी कंपनियाँ जोखिम देखकर AI पर नियंत्रण लगाएंगी। इस प्रवाह में AI tools को आख़िरकार मानव ज़िम्मेदारी की सीमा के भीतर ही जीवित रहना होगा
मैं 25 साल से ज़्यादा समय से free software डेवलपर रहा हूँ और तरह-तरह के licenses पसंद करता हूँ। मेरे जीवनसाथी director और visual artist हैं, लेकिन मैं AI-संबंधित content को छूता भी नहीं और उसे कचरा मानता हूँ। इस बात को बहुत स्पष्ट रूप से रखा गया
Konwinski Prize जैसी चुनौती दिलचस्प बताई गई, जहाँ अगर कोई open source LLM नए Github issues में 90% से ज़्यादा हल कर दे तो 10 लाख डॉलर का इनाम है। Konwinski Prize प्रतियोगिता का संदर्भ दिया गया। अभी सर्वश्रेष्ठ मॉडल भी 0.9 नहीं बल्कि केवल 0.09 स्कोर पर हैं, इसलिए इसे व्यावहारिक उपयोग से अभी बहुत दूर माना गया। भले open source मॉडल commercial मॉडल से थोड़ा कमज़ोर हों, फिर भी LLM द्वारा स्वतंत्र रूप से कोड लिखना अभी लगभग असंभव है। बहुत सारा कचरा बनता है, लेकिन evaluation और management की ज़रूरत के कारण कुछ उपयोगिता फिर भी है
अगर AI दोहराव वाले boilerplate coding tasks कर भी दे, तो अब वही उबाऊ AI code review बार-बार करना पड़ता है, और यह न तो ज़्यादा मज़ेदार है, न कम समय लेता है, न समझ बेहतर बनाता है
AI development के पक्षधर लोग शायद coding से ज़्यादा code review पसंद करते हैं। यह व्यक्तिगत पसंद हो सकती है, लेकिन अपने आप में काफ़ी पीड़ादायक लगती है
तकनीकी रूप से देखें तो बड़े पैमाने का code review आम तौर पर खुद लिखने से कम समय लेता है। ख़ासकर जब कोड tests pass कर रहा हो, और test code भी LLM से बन सकता हो, तब बोझ कुछ कम हो जाता है
Claude, Gemini आदि मेरे खुद कोड लिखने से कहीं तेज़ हैं, और दो बार देखकर जाँच करने पर भी समय मेरे खुद लिखने से कम ही लगता है
पहले 'yak shaving' जैसे दोहराव वाले कामों में कोड लिखा जाता था, अब लापरवाही से किए गए 'yak' shave की review करनी पड़ती है
कुल मिलाकर ज़्यादा energy/carbon उत्सर्जन अपरिहार्य है
मशीन translation और speech recognition पर चर्चा। लगभग श्रवण-बाधित होने के नज़रिए से, मैं दिन भर इस तकनीक का उपयोग करता हूँ। 80 के दशक के ड्रामा बिना subtitles के देखना संभव नहीं था, लेकिन अब Whisper जैसे LLM का उपयोग करके वीडियो से subtitles निकाल सकता हूँ, और यह उस चीज़ के सच हो जाने जैसा चमत्कार है जिसकी कभी सिर्फ़ कल्पना की थी
नवीनतम speech recognition और translation SOTA में अभी भी single-task specialized models आगे हैं, लेकिन अंतर तेज़ी से कम हो रहा है, और LLM बहुत अधिक तरह के काम कर सकते हैं। (उदाहरण: speech recognition leaderboard देखें), LLM संभावनाओं का दायरा खोलते हैं
कई सालों तक Dragon जैसी speech recognition प्रणालियाँ आज़माईं — वे प्रभावशाली तो थीं, लेकिन वास्तविक उपयोग में असुविधाजनक रहीं। Whisper और LLM का मेल पहली बार सचमुच उपयोगी साबित हुआ। यह अभी भी पूर्ण नहीं है, लेकिन manual correction का काम दसवें हिस्से तक घट गया है, और निजी notes के लिए तो अब मैं अक्सर verification भी नहीं करता
अभी भी मैं वास्तव में high-risk कामों में — जैसे विदेशी देशों के employment contracts, पुलिस बयान आदि — केवल LLM translation पर भरोसा नहीं करूँगा। पहले भी speech-to-text था, और तकनीकी प्रगति महसूस होती है, लेकिन यह अभी रोज़मर्रा और low-risk उपयोग तक ही ठीक है; SF उपन्यासों जैसे अंतरिक्षीय वार्तालाप के स्तर से अभी बहुत दूर है
मुझे भी लगता है कि हाल की तकनीकी प्रगति सचमुच बचपन में पढ़े SF की कई प्रतिज्ञाओं को साकार कर रही है। कुछ दिन पहले एक अनजान शहर में मैंने रेस्तराँ के menu की तस्वीर ली, उसमें लिखी चीनी हस्तलिपि निकाली, उसे तुरंत अंग्रेज़ी में अनुवाद किया, और मनचाहे dish का उच्चारण भी सीखकर ऑर्डर दिया। मुझे पूरा यक़ीन है कि 2 साल पहले तक यह संभव नहीं था
मुझे लगता है कि translation ही LLM का लगभग आदर्श उपयोग-क्षेत्र है। LLM सामाजिक अवधारणाएँ, सांस्कृतिक संदर्भ, pop culture, दुर्लभ references तक को समेटकर कई भाषाओं और संस्कृतियों के अनुरूप अनुवाद के अलग-अलग रूप दे सकते हैं। मुझे विश्वास है कि वे पारंपरिक translation से पहले ही काफ़ी आगे निकल चुके हैं