- coding LLM का उपयोग करके स्पष्ट मूल्य सृजन करने में कठिनाई महसूस करने वाले डेवलपर्स मौजूद हैं
- कुछ उपयोगकर्ता LLM की output quality से संतुष्ट नहीं हैं
- विशिष्ट requirements या जटिल समस्याओं में LLM अक्सर अपेक्षाओं पर खरा नहीं उतरता
- दूसरी ओर, सरल automation या दोहराए जाने वाले कामों में कुछ हद तक सुविधा महसूस होती है
- डेवलपर्स prompt engineering और workflow सुधारने के तरीकों की तलाश कर रहे हैं
coding LLM के उपयोग की कठिनाइयों और सुधार के तरीकों पर चर्चा
LLM की सीमित उपयोगिता
- हाल के समय में कई डेवलपर्स ChatGPT, GitHub Copilot, Claude जैसे coding LLM को अलग-अलग उद्देश्यों के लिए आज़मा रहे हैं
- लेकिन काफ़ी उपयोगकर्ताओं को उम्मीद के मुताबिक वास्तविक productivity improvement महसूस नहीं हो रहा है
- खासकर जटिल algorithm लिखने, बड़े पैमाने पर code structuring, और project architecture design में LLM द्वारा सुझाया गया code अक्सर खंडित या अक्षम साबित होता है
output quality को लेकर असंतोष
- कुछ डेवलपर्स का कहना है कि LLM द्वारा दिया गया code bugs शामिल करता है, या संदर्भ को ठीक से न समझ पाने के कारण गलत परिणाम देता है
- कई बार explanation या analysis पर्याप्त नहीं होता, या code project की जटिलता और संदर्भ को सही तरह से नहीं दर्शाता
सरल उपयोग क्षेत्रों में मदद
- छोटे code snippets बनाना, दोहराए जाने वाले काम, और साधारण syntax समस्याएँ सुलझाने जैसे basic automation के मामलों में स्पष्ट सुविधा देखी जा सकती है
- unit tests, refactoring, और code style सुधार जैसे routine कामों में इसका उपयोग काफ़ी उपयोगी माना जा रहा है
सुधार के लिए प्रयास
- कुछ डेवलपर्स बेहतर परिणाम पाने के लिए सक्रिय रूप से prompt engineering तकनीकों का उपयोग कर रहे हैं
- वे अपने workflow के अनुरूप LLM इस्तेमाल करने के तरीके और कई open source tools के साथ उसके संयोजन पर प्रयोग कर रहे हैं
निष्कर्ष और सीख
- फिलहाल यह मानना पड़ रहा है कि LLM डेवलपमेंट की हर ज़रूरत के लिए सर्वसमर्थ समाधान नहीं है
- community और डेवलपर्स अपने अनुभव साझा करते हुए प्रभावी उपयोग रणनीतियाँ और सीमाओं से निपटने के तरीकों की तलाश कर रहे हैं
1 टिप्पणियां
Hacker News राय
मुझे लगता है कि डेवलपर्स दो तरह के होते हैं। एक वे जो कहते हैं कि LLM coding में पूरी तरह की superpower है और उनकी productivity 100x बढ़ गई है, और दूसरे वे जो इसे ऐसा काफी पेचीदा tool मानते हैं जिसमें बहुत हाथ पकड़ना पड़ता है और मेहनत करके बस साधारण नतीजे मिलते हैं। लेकिन अगर पहली श्रेणी वाले लोग सच में LLM से इतनी क्रांतिकारी productivity पा रहे हैं, तो क्या उन्हें अब तक बाज़ार पर छा नहीं जाना चाहिए था और competitors को पीछे नहीं छोड़ देना चाहिए था?
Greenfield काम में मुझे सचमुच लगता है कि LLM की वजह से productivity 100x तक बढ़ जाती है। उदाहरण के लिए, React app में कई pages, Redux store, authentication वगैरह जैसी बुनियादी structure को यह कुछ ही मिनटों में खड़ा कर देता है। अगर मैं कहूँ, "अब X जोड़ दो", तो यह ज़्यादातर अच्छे नतीजे देता है। लेकिन existing systems का maintenance, complex features जोड़ना, या जहाँ domain knowledge अहम हो, वहाँ LLM ज़्यादा काम का नहीं होता। Code autocomplete या function पूरा करने के लिए यह अच्छा है, लेकिन पूरी feature implementation में जल्दी इसकी सीमाएँ दिखने लगती हैं। ऐसे मामलों में LLM को निर्देश देने में जितना समय लगता है, लगभग उतने में मैं खुद code लिख लेता हूँ। इसलिए मैं अक्सर पहले अपनी मनचाही structure के हिसाब से stub code लिख देता हूँ और LLM से सिर्फ खाली हिस्से भरवाता हूँ। जो लोग 100x productivity की बात करते हैं, शायद वे अभी तक सिर्फ आसान हिस्सों से गुज़रे हैं या मुश्किल भागों से नहीं टकराए। असल में काम का 90% आसान होता है, और आख़िरी 10% ही सचमुच कठिन होता है, जहाँ LLM ठीक से काम नहीं कर पाता
थोड़ा तंज़ है, लेकिन 100x productivity कहने वाले लोग असल में छोटे नंबर को 100 से गुणा कर रहे होते हैं। Research phase में LLM ज़बरदस्त मदद करता है। हाल में मुझे कुछ domain-specific linear algebra code लिखना था, और मैं LAPACK जैसी libraries इस्तेमाल नहीं कर सकता था, इसलिए मुझे खुद implement करना पड़ा। ऐसे में LLM को reference book की जगह इस्तेमाल करके मैं मनचाही जानकारी एक जगह से पा सका, और सचमुच research time 100x कम हो गया। लेकिन जब actual code implementation LLM से करवाया, तो उसमें ऐसी subtle गलतियाँ थीं जिन्हें domain expert न हो तो पकड़ना मुश्किल था। Junior engineer शायद उन्हें यूँ ही पास कर देता। मैं code review को गंभीरता से लेता हूँ, इसलिए मुझे नहीं लगता कि LLM कितना भी बेहतर हो जाए, actual coding speed बहुत नहीं बढ़ेगी। लेकिन कौन-सा code लिखना है, इसे तय करने वाली exploration और summary stage में LLM सचमुच बहुत speed बढ़ा देता है। आखिरकार innovation और creative ideas ही दुनिया की असली value हैं, और वे अब भी इंसानों का काम हैं। LLM एक महत्वपूर्ण helper है, लेकिन high-value code इंसान को ही लिखना चाहिए
असल में कई लोग इन दोनों में से किसी श्रेणी में नहीं आते। 100x productivity नहीं है, लेकिन इसका इस्तेमाल बहुत कष्टदायक भी नहीं है। मैं 30 साल से ज़्यादा समय से professional coding कर रहा हूँ, और हमेशा कुछ-न-कुछ देखना पड़ता था, खासकर किसी language या syntax की बारीकियाँ अक्सर भूल जाता था। कई jobs में अलग-अलग languages के बीच आते-जाते रहना पड़ता है। पहले reference books, manuals, और कभी-कभी उससे भी कठिन materials खंगालने पड़ते थे। Google जैसे search engines आने पर चीज़ें थोड़ी बेहतर हुईं, और Stack Overflow जैसी platforms ने इसे और efficient बना दिया। अब LLM उसी क्रम में अगला कदम है। Autocomplete suggestions कभी-कभी वही संकेत दे देती हैं जिसकी मुझे तलाश होती है। ज़रूर, जो काम का न हो उसे मैं नज़रअंदाज़ कर देता हूँ, लेकिन chat interface Google या SO search की तुलना में कहीं अधिक conversational तरीके से सवाल पूछने देता है, और यह बड़ी सुविधा है
मैं Math Academy, ChatGPT, और YouTube (खासकर 3Blue1Brown वगैरह) से math पढ़ रहा हूँ। अगर यह combination न होता तो यह सब बहुत कष्टदायक होता, लेकिन अब मज़ेदार है। पहले जब मैंने University of Amsterdam में इसी तरह का course किया था, तब ChatGPT आज जितना smart नहीं था, इसलिए वह अनुभव कहीं ज़्यादा कठिन था। ChatGPT ऐसे सवालों के जवाब भी दे देता है जिनका जवाब देना किसी teacher के लिए आसान नहीं होता, इसलिए मेरे जैसे व्यक्ति के लिए यह बहुत सही है, जिसे math की cultural background समझनी होती है ताकि चीज़ें relatable लगें और creative problem-solving हो सके। जैसे मैंने पूछा कि angles में m क्यों इस्तेमाल होता है, तो इसने बताया कि ऐतिहासिक रूप से यह measure से आया है। इसकी वजह से अब मैं फिर से math के मूल सार पर ध्यान दे पा रहा हूँ। Fast variance calculation formula भी ChatGPT ने बहुत आसानी से समझाया। यह दुनिया पर राज करने का साधन नहीं है, लेकिन मैं वह ज्ञान सीख पा रहा हूँ जो शायद पहले कभी न सीख पाता। बेशक YouTube और Math Academy की भी बड़ी भूमिका है
LLM उन लोगों को superpower देता है जो कई क्षेत्रों में थोड़ा-बहुत काम करते हैं और हर चीज़ में expert नहीं होते। अगर आप सिर्फ एक ही खास domain में गहराई से काम करते हैं और हमेशा वही करते हैं, तो यह इतना उपयोगी नहीं होता। उदाहरण के लिए, अगर deployment expert अलग से न हो और हर project में Dockerfile सिर्फ एक बार चाहिए हो, तो LLM से Dockerfile लिखवाना वाकई शानदार है। छोटी syntax errors या मामूली दिक्कतें Google से भी तेज़ी से हल हो जाती हैं। Architecture trade-offs पर LLM से analysis करवाना भी productivity बढ़ाता है, बशर्ते अंतिम निर्णय आप खुद लें। लेकिन prompts के ज़रिए scope को ठीक से सीमित करना पड़ता है ताकि LLM बेवकूफ़ी न करे, और यह अक्सर मौजूद ही नहीं होने वाले APIs गढ़ देता है, इसलिए बार-बार सुधारना भी पड़ता है। फिर भी iteration के बाद भी speed advantage बना रहता है
मैं भी LLM को कई तरीकों से इस्तेमाल करता हूँ। छोटे debugging issues, shell scripts, coding, questions—कई स्थितियों में मदद लेता हूँ। निजी कामों में Claude, OpenAI के अलावा Google या Perplexity जैसे अलग-अलग tools में से जो सबसे अच्छा result दे, उसे चुनता हूँ। काम में VSCode में Copilot या internal platform के ज़रिए Claude, OpenAI, Google का उपयोग करता हूँ, और Copilot Studio के साथ थोड़ा experiment भी किया है। डेढ़ साल से ज़्यादा समय से मैं इस तरह काम कर रहा हूँ; हर tool को लगातार इस्तेमाल नहीं किया, लेकिन मेरा overall impression यह है। LLM की वजह से productivity निश्चित रूप से बढ़ी है। कई programming languages में experiment करने, अलग-अलग topics को बेहतर समझने, और कुछ कामों को बहुत आसान बनाने में इसका स्पष्ट लाभ हुआ है। लेकिन model और version से परे, जैसे ही काम complex होता है, मेरी अपनी राह पकड़ता है, या simple composition से आगे बढ़ता है, सब कुछ विफल होने लगता है। कभी-कभी LLM के घटिया output को ठीक करने में इतना समय लग जाता है कि शुरुआत में LLM से बचाया गया समय पूरा खत्म हो जाता है। अभी मेरा ईमानदार निष्कर्ष यही है कि LLM छोटे code autocomplete, debugging, और explanations में उपयोगी है, बस उतना ही। यह अभी हमारी jobs के लिए तत्काल ख़तरा नहीं है
नई libraries, APIs, या languages सीखने में LLM बहुत मदद करता है। उदाहरण के लिए, OpenGL में text render कैसे करना है, यह सीधे LLM से पूछना विशाल और उलझे हुए official docs पढ़ने से कहीं तेज़ है। या जब repetitive और उबाऊ boilerplate code लिखना हो और existing codebase में कोई reference न मिले, तब LLM उपयोगी होता है। लेकिन जिस हिस्से को मैं असली "काम" मानता हूँ—मेरी service का unique, domain-specific code—वहाँ "मेरे लिए code लिख दे" वाले अर्थ में LLM बहुत उपयोगी नहीं है। एक senior engineer के रूप में मेरा समय actual coding में लगभग नहीं जाता; महत्वपूर्ण चीज़ें हैं structure design, legacy refactoring, performance issues, और rare bugs की debugging। LLM सिर्फ repetitive code writing को तेज़ करता है, इसलिए अगर आप हर हफ्ते नया project scratch से नहीं बना रहे, तो इसकी उपयोगिता सीमित है। अगर आप अभी भी बहुत boilerplate लिख रहे हैं, तो सिर्फ LLM पर निर्भर रहने के बजाय दूसरी बुनियादी solutions पर भी सोचना चाहिए
उलझे हुए official docs पढ़ने और उन्हें समझाने में LLM सामान्य programmers से कहीं बेहतर है। इस क्षेत्र में यह स्पष्ट रूप से value add करता है। और कुछ languages में boilerplate सचमुच बहुत ज़्यादा होता है
कोई silver bullet नहीं है; conceptualization ही असल में कठिन हिस्सा है। Mythical man-month एक महत्वपूर्ण text है, उसे और पढ़ना चाहिए
कोई silver bullet नहीं है। यह हैरानी की बात है कि हम Fred Brooks की इस सरल सलाह को बार-बार भूल जाते हैं। अगर हम उम्मीदें बहुत न बढ़ाएँ, और यह समझें कि training data में buggy code बहुत है इसलिए LLM भी स्वाभाविक रूप से bugs पैदा करेगा, तो LLM कहीं ज़्यादा उपयोगी बन जाता है। Design को इसके हवाले नहीं करना चाहिए; function splitting जैसी तैयारी मुझे खुद करनी चाहिए, और LLM का उपयोग उबाऊ कामों या अपरिचित क्षेत्रों में झंझट कम करने के लिए करना चाहिए। लेकिन LLM जो code बनाए, उसकी ज़िम्मेदारी लेने के लिए मेरी अपनी knowledge और verification ज़रूरी है। चाहे LLM का code एकदम सही क्यों न लगे, उसमें defects छिपे हो सकते हैं, इसलिए सीखते रहना, skill बढ़ाना, और संदेह बनाए रखना ज़रूरी है। अंधविश्वास कभी नहीं करना चाहिए
जैसे-जैसे problem का scale बढ़ता है, यह साफ़ हो जाता है कि LLM बेकार होने लगता है। Repetitive tasks या complex find & replace में यह शानदार है। API resources में CRUD methods भरना जैसे रोज़मर्रा के, स्पष्ट code के लिए यह बेहद उपयोगी है। हाल में मैंने Claude Opus 4 से अपने patches की review भी करवाई, और इसने कभी-कभी errors पकड़े, साथ ही मुझे यह भी याद दिलाया कि मुझे क्या करना चाहिए। लेकिन एक बार complexity threshold पार होते ही LLM की उपयोगिता तेज़ी से गिरती है। उदाहरण के लिए, अगर कई अपेक्षाकृत बड़ी files में changes चाहिए हों, तो मैं खुद ही स्वाभाविक रूप से समझने लगता हूँ कि किन files को बदलना है। फिर भी LLM को 'rubber duck' की तरह इस्तेमाल करना ठीक है। अगर AI ठीक से कर दे तो बढ़िया, नहीं तो मैं तुरंत खुद आगे बढ़ जाता हूँ। नतीजा यह है कि LLM ने सिर्फ शुरुआत में मदद की, जबकि ज़्यादातर fixing का काम तो वैसे भी मुझे ही करना था। Framework जैसा ढाँचा मोटे तौर पर तैयार मिल जाए और फिर मैं उसे अपनी ज़रूरत के मुताबिक ठीक कर लूँ, तो यह शून्य से सब कुछ लिखने से आसान है। अगर LLM साफ़ तौर पर struggle कर रहा हो, तो मैं उसे ज़बरदस्ती नहीं करवाता। अगर spec अस्पष्ट होने के कारण उसने गलत अनुमान लगाया हो, तो मैं वह बता देता हूँ; फिर भी न कर पाए तो मैं खुद finish कर देता हूँ
मेरा अनुभव भी कुछ ऐसा ही है। मुझे LLM की value इन चीज़ों में मिली है। काफ़ी independent React components या pages, खासकर लोकप्रिय UI libraries के साथ, यह बहुत अच्छे से बना देता है। अच्छी तरह defined pure functions भी यह काफ़ी भरोसेमंद तरीके से बना देता है, और उन्हें verify करना भी आसान होता है। प्रसिद्ध frameworks का boilerplate तो यह सचमुच आसानी से और अच्छे ढंग से तैयार कर देता है। लेकिन मेरे आस-पास के लोग शक्तिशाली end-to-end अनुभवों की शेख़ी बघारते हैं, जबकि मेरे साथ वास्तविकता ऐसी नहीं रही, और यह थोड़ा पागल कर देने वाला लगता है। मैं सामान्यतः बहुत मेहनत करूँ तब भी पूरी feature unit के स्तर पर LLM पूरी तरह बिखर जाता है। aider जैसे tools के साथ Next.js में एक साधारण templated email feature तक नहीं बन पाई। अगर feature को छोटे हिस्सों में बाँटकर एक-एक कराऊँ तो कुछ सुधार होता है, लेकिन धीरे-धीरे existing codebase बिगड़ने लगता है। समस्या समझा भी दूँ, तो prompts बढ़ने के साथ नतीजे और अजीब होते जाते हैं। आखिर में मैंने हाथ से ठीक करने की कोशिश की, लेकिन code पूरी तरह बिखरा हुआ था
मेरे दोस्त vibe coders ने मुझसे कहा है कि "मेरे standards बहुत ऊँचे हैं"। मुझे लगता है कि vibe coders मूल रूप से code को ठीक से review नहीं करते, इसलिए उनके पास quality standards ही नहीं होते। अगर vibe coding सचमुच असरदार होती, तो Google AI जैसी जगहें अपने विशाल GPU, TPU budgets और सबसे नए AI models के साथ इंसानों से कहीं तेज़ी से products को बेहतर बना रही होतीं। अगर सच में ऐसा हो रहा होता, तो हमारे काम आसान होने की बजाय, हमें पहले किसी अप्रत्याशित, विशाल घटना की खबर news में मिलती, और बहुत बाद में पता चलता कि उसके पीछे AI था
LLM one-off code के लिए अच्छा है। Development, maintenance, debugging, fixing—इन सबको यह आसान नहीं बना देता। ज़्यादातर code असल में product नहीं बल्कि 'consumable' code होता है, इसलिए वहाँ यह उपयुक्त है। Fast food, assembly factory, automated production जैसी अवधारणाएँ लागू हों तब भी एक बड़ा फर्क रहता है। Factory में machine से बनी चीज़ 99.99% से अधिक accuracy के साथ बनती है, इसलिए उस पर भरोसा किया जा सकता है। लेकिन LLM में हर step पर मुझे खुद verify करना पड़ता है, और verify न करूँ तो वह बस काम नहीं करता। LLM 24 घंटे बिना निगरानी के अपने-आप सफलतापूर्वक काम नहीं कर सकता। इसलिए यह अभी jobs नहीं छीन रहा
मैं कभी यह नहीं सोचता कि किसी complex problem को पूरा का पूरा LLM के हवाले कर दूँ और result ले लूँ। वह इसकी ताकत नहीं है। LLM की असली value इस बात में है कि वह आगे बढ़ने के लिए 'hints' देता है और उन सरल लेकिन समय लेने वाले हिस्सों को skip करवा देता है। कुछ दिन पहले मुझे log strings बनानी थीं, और LLM ने मेरे सोचे से अधिक सुंदर format में code तुरंत सुझा दिया, जिससे 15 मिनट का काम 30 सेकंड में बहुत अच्छे से हो गया। ऐसी छोटी-छोटी जीतें जुड़कर value बनाती हैं