LLM का उपयोग करके कोडिंग (2025 की गर्मियां)
(antirez.com)- Redis डेवलपर antirez के LLM उपयोग अनुभव का अपडेट
- Gemini 2.5 PRO और Claude Opus 4 जैसे अत्याधुनिक LLM डेवलपर की क्षमताओं को मजबूत करते हैं
- LLM का उपयोग करने पर बग हटाने, आइडिया टेस्ट करने, ज्ञान बढ़ाने जैसे कई तरीकों से काम की दक्षता बढ़ाई जा सकती है
- गैर-विशेषज्ञ क्षेत्रों या नई तकनीकों को LLM की मदद से आसानी से संभालने का अनुभव संभव है
- लेकिन कोड की समग्र गुणवत्ता और प्रबंधन के लिए 'मानव + LLM' सहयोग ही सबसे महत्वपूर्ण है
- LLM का सर्वोत्तम उपयोग करने के लिए पर्याप्त context देना और स्पष्ट communication skill महत्वपूर्ण हैं
LLM का उपयोग करने वाले डेवलपमेंट में बदलाव और मुख्य बिंदु
अत्याधुनिक LLM (Gemini 2.5 PRO, Claude Opus 4 आदि) अपनी व्यापक समझ क्षमता और बड़े पैमाने के कोड को संभालने की योग्यता के आधार पर प्रोग्राम डेवलपर की क्षमता को विस्तारित करने की भूमिका निभाते हैं
- अगर आप समस्या को स्पष्ट रूप से वर्णित कर सकें और दोहराव वाली बातचीत के आदी हों
- रिलीज़ से पहले ही बग हटाने जैसा अनुभव संभव है (उदाहरण: Redis के Vector Sets implementation केस में Gemini/Claude के code review से तुरंत bug removal)
- किसी आइडिया के काम करने या न करने को जल्दी टेस्ट करते हुए experimental code लिखना और performance evaluation करना संभव है
- अनुभव और instinct पर आधारित pair-design संभव है, जिसमें LLM का समृद्ध विशेषज्ञ ज्ञान और मानव intuition मिलते हैं
- LLM को स्पष्ट निर्देश देने पर कोड implementation के कुछ हिस्से तेजी से पूरे किए जा सकते हैं
- अनजान क्षेत्रों में भी (उदाहरण: Amiga के लिए 68000 assembly code) तेज तकनीकी अनुकूलन संभव है
पहले के 'LLMs और 2024 की शुरुआत में प्रोग्रामिंग' लेख में LLM की उपयोगिता का उल्लेख था, लेकिन पिछले 1.5 साल में LLM ने बहुत तेज़ प्रगति की है
LLM का सर्वोत्तम उपयोग करने के लिए मानव और LLM दोनों में कुछ विशेष क्षमताएं और आदतें जरूरी हैं, और इसके लिए सिद्धांत महत्वपूर्ण हैं
Vibe Coding में संयम और मानव+LLM सहयोग के सिद्धांत
फिलहाल LLM डेवलपर क्षमता amplifier के रूप में उत्कृष्ट हैं, लेकिन अभी वे इस स्तर तक नहीं पहुंचे हैं कि पूरी तरह स्वायत्त रूप से अकेले सारा काम संभाल लें
- टेस्ट, छोटे utility आदि जैसे one-off छोटे प्रोजेक्ट्स में LLM-केवल डिजाइन संभव है
- लेकिन बड़े, असामान्य प्रोजेक्ट्स में केवल LLM का उपयोग करने पर जटिलता, अनावश्यक कोड, संरचनात्मक कमजोरी जैसी समस्याएं पैदा होने की संभावना अधिक है
- LLM+मानव सहयोग से सबसे बड़ा productivity gain मिलता है, लेकिन शर्त है effective communication और LLM को manage करने के अनुभव की
- जटिल काम सिर्फ LLM को न सौंपें; हमेशा ऐसी रणनीति जरूरी है जिसमें मानव प्रक्रिया में सक्रिय रूप से शामिल रहे
LLM को पर्याप्त context देने का महत्व
LLM को डेवलपमेंट या समस्या-समाधान की दिशा सही तरह समझाने के लिए व्यापक context जानकारी देना अनिवार्य है
- papers, target codebase (जितना संभव हो पूरा), और काम का इरादा देना बेहतर है
- implementation का उद्देश्य, अनावश्यक या कमजोर approaches, व्यवहार्य मुख्य आइडिया, लक्ष्य, invariants, code style जैसी मुख्य जानकारी शामिल होनी चाहिए
- उदाहरण के लिए, जब LLM किसी नई तकनीक (जैसे Redis vector sets) को नहीं जानता हो, तब README दस्तावेज़ को context में शामिल करने पर विशेषज्ञ-स्तर के उत्तर तुरंत मिल सकते हैं
LLM का चयन और उपयोग का तरीका
सबसे ज़्यादा प्रसिद्ध LLM हमेशा सबसे अच्छे नतीजे नहीं देते
- कोडिंग के लिए Gemini 2.5 PRO और Claude Opus 4 खास तौर पर प्रभावी हैं
- Gemini 2.5 PRO की जटिल bug detection और problem-solving क्षमता उत्कृष्ट है
- Claude Opus 4 नया कोड लिखने में सक्षम है, और user experience भी बेहतर है
- दोनों मॉडल बारी-बारी से इस्तेमाल करने पर जटिल डिजाइन में समझ और बेहतर होती है
- अगर सिर्फ एक चुनना हो, तो Gemini 2.5 PRO की सिफारिश की जाती है
- LLM उपयोग करते समय जिन शर्तों का पालन करना चाहिए
- code agent या IDE में integrated agent के उपयोग से बचें
- LLM को पूरा context (कोड, दस्तावेज़ आदि) सीधे देखने दें ताकि सबसे अच्छे उत्तर मिल सकें
- RAG (ज्ञान निष्कर्षण-आधारित) जैसे फीचर, जो सिर्फ context का एक हिस्सा दिखाते हैं, इस्तेमाल करने पर performance गिर सकती है
- हर चरण में इंसान को manually code copy/paste करते हुए flow को सीधे track करना चाहिए
निष्कर्ष – नियंत्रण बनाए रखना ही कुंजी है
अकेले कोड लिखने वाले agent का आगमन दूर नहीं है, लेकिन इस समय मानव द्वारा LLM के साथ सक्रिय सहयोग ही सबसे धारदार कोड पैदा करता है
- क्या करना है और कैसे करना है, यह तय करने में मानव की भूमिका अब भी केंद्रीय है
- LLM का उपयोग करके मौजूदा ज्ञान की सीमाओं से आगे बढ़ते हुए नई तकनीकें या अवधारणाएं सीखकर विकास किया जा सकता है
- कोड पर सीधे नियंत्रण रखने से डिजाइन और implementation की consistency बनी रहती है, और LLM की गलतियों से आने वाली अनिश्चितता भी कम होती है
- agents की performance में हो रही प्रगति को समय-समय पर जांचना भी एक समझदारी भरी रणनीति है
- इस चरण में LLM के उपयोग से बचना बदलाव से पीछे छूटने जैसा हो सकता है, इसलिए संतुलित उपयोग पद्धति महत्वपूर्ण है
1 टिप्पणियां
Hacker News राय
यह देखकर अफसोस होता है कि Gemini 2.5 PRO या Claude Opus 4 जैसे proprietary LLM मॉडल धीरे-धीरे standard बनते जा रहे हैं। LLM की प्रगति और एक tool के रूप में उनकी ताकत को मैं बहुत सकारात्मक मानता हूँ, लेकिन यह समझना कठिन है कि डेवलपर (चाहे मशहूर हों या नहीं) लगातार यह क्यों स्वीकार कर रहे हैं कि programming करने के लिए किसी third-party paid service पर निर्भर रहना ठीक है। पहले open source और free tools से भी coding संभव थी। मुझे चिंता है कि कुछ वर्षों बाद paid LLM पर निर्भर रहना उतना ही असुविधाजनक न हो जाए जितना आज IDE या vim के बिना coding करना लगता है। "महीने के $200 कोई बड़ी बात नहीं" जैसी बातें मूल समस्या का समाधान नहीं करतीं।
अभी जो open model स्थानीय रूप से चलाए जा सकते हैं, वे quality में कमज़ोर हैं, और सबसे बड़ी बात यह है कि उनका operational cost कहीं ज़्यादा है। जिस दिन Claude 4 स्तर का मॉडल किसी personal computer पर किफायती ढंग से चल सकेगा, उस दिन बहुत लोग उसे आज़माएँगे। अभी की स्थिति में Kimi K2 जैसे मॉडल दो 512GB Mac Studio पर चल सकते हैं, लेकिन सिर्फ hardware की कीमत ही लगभग $20,000 है।
subscription model शुरू में ऐसा महसूस कराते हैं मानो वे price-performance के लिहाज़ से बेहद शानदार हों। लेकिन धीरे-धीरे कीमतें बढ़ती हैं, quality गिरती है, और आखिरकार आप service में बँध जाते हैं। बिल्कुल Black Mirror के "Common People" episode जैसा।
व्यक्तिगत रूप से मुझे नहीं लगता कि ऐसा भविष्य आसानी से आएगा जिसमें हर डेवलपर अनिवार्य रूप से paid LLM का बंधक बन जाए। लंबी अवधि में लोग समझेंगे कि बहुत सारा code पैदा करना ही अपने-आप में समस्या है। Code एक liability है, और अगर unstable या slow code जमा होता जाए तो वह liability भी बढ़ती जाती है। AI गायब नहीं होगा, लेकिन जब यह hype कुछ ठंडा पड़ेगा, तब लोग बेहतर समझेंगे कि इसे कहाँ और कैसे इस्तेमाल करना चाहिए। यह भी सवाल है कि funding सूखने पर क्या होगा। OpenAI और Anthropic profitable नहीं हैं, और मौजूदा स्थिति बनाए रखने के लिए उन्हें लगातार capital चाहिए। अगर LLM का विकास लगभग यहीं तक है और यही उसकी सीमा है, तो investment भी निकल सकती है। फिर या तो उपयोग लागत बढ़ेगी, या सेवाएँ पूरी तरह गायब भी हो सकती हैं।
वास्तविक रूप से देखें तो मुझे यह बहुत बड़ी समस्या नहीं लगती। अगर productivity improvement का ठोस कारण नहीं है, तो कोई महँगी और असुविधाजनक service का दास बना क्यों रहेगा? Open model भी लगातार बेहतर हो रहे हैं, इसलिए अगर open model के साथ अंतर बहुत बड़ा नहीं रहा, तो इन्हें इस्तेमाल करते रहने की ज़रूरत नहीं होगी। और अगर LLM की प्रगति रुकती नहीं बल्कि तेज़ी से चलती रहती है, तो पारंपरिक तरीकों से हमारी प्रतिस्पर्धात्मकता नहीं बचेगी, इसलिए हमें किसी और क्षेत्र में शिफ्ट होना होगा। कुल मिलाकर, मुझे नहीं लगता कि बहुत ज़्यादा चिंता करने की ज़रूरत है। साथ ही, मुझे बड़े model कंपनियों की valuation वास्तविकता से बहुत ज़्यादा बढ़ा-चढ़ाकर आँकी हुई लगती है।
इस बात में मैं जोड़ना चाहूँगा कि open source और free tools से coding करने की बात पूरी कहानी नहीं है। JetBrains मेरे साथियों की कई कंपनियों से पुरानी कंपनी है, और MS का Visual Basic/C++/Studio Windows development को आसान बनाता था, लेकिन ये सब paid थे।
मैं "PhD-level knowledge" जैसी अभिव्यक्ति से सहमत नहीं हूँ। PhD का उद्देश्य मौजूदा ज्ञान अर्जित करना नहीं, बल्कि research करना सीखना होता है। AI चर्चा में यह एक आम गलतफहमी है, और इस वजह से "PhD स्तर के ज्ञान" जैसी बात का अर्थ धुंधला हो जाता है।
PhD सिर्फ research सीखने की प्रक्रिया नहीं है, बल्कि सही सवाल पूछ पाना भी उसका मूल है। LLM किसी "बहुत ज्ञानवान लेकिन आलसी मज़दूर" की तरह है; वह खुद से सवाल उठाकर hypothesis नहीं तलाशता। अपने अनुभव से कहूँ तो, Claude Code(Max Pro) से मैंने test assertions की संख्या comment out करने को कहा था, और उसने मूल योजना के बारे में गलत अनुमान के आधार पर bug पैदा कर दिया। मुझे खुद उसे योजना दोबारा लिखने का निर्देश देना पड़ा, तभी वह कारण ढूँढ़कर ठीक कर पाया। उदाहरण के लिए, ORM object में null value इसलिए थी क्योंकि commit के बाद refresh नहीं हुआ था, और दूसरे DB session से लाया गया object session खत्म होने के बाद भी वैसा ही बना रहा था।
सहमत हूँ। इसमें expert-level knowledge तो है, लेकिन जिन चीज़ों में इंसान अच्छा होता है, उनमें LLM उतना सक्षम नहीं है। उदाहरण के लिए LLM कभी-कभी शुरू से अंत तक एक शानदार program एक ही बार में लिख सकता है, लेकिन iterative improvement उसके लिए कठिन है।
भले ही हम मान लें कि PhD सिर्फ ज्ञान से बढ़कर है, फिर भी उस ज्ञान तक आसानी से पहुँच बन जाना बहुत बड़ी value है। मेरी पिछली कंपनी में ऐसे कठिन सवाल होते थे जिनका जवाब सामान्यतः सिर्फ PhD दे सकता था — मोटे तौर पर जैसे, "अगर दो materials की boundary पर किसी निश्चित दिशा में voltage लगाया जाए तो क्या होगा?" — और LLM कभी-कभी उनका काफ़ी उपयोगी उत्तर दे देता था।
PhD लेने के बाद भी कोई subject पर ज़्यादा ध्यान नहीं देता; अंततः महत्वपूर्ण यह है कि आपने research करना सीखा।
मुझे लगता है कि LLM-आधारित coding पर किसी भी चर्चा में target domain और इस्तेमाल की जा रही programming language का ज़िक्र ज़रूर होना चाहिए। इन दोनों variables का प्रभाव LLM के उपयोग के तरीके से भी कहीं अधिक होता है। अगर कोई LLM coding को पसंद या नापसंद करता है, तो पहले यह पूछना चाहिए कि उसने किस तरह की समस्या पर काम किया। और फिर खुद AI से उसी तरह की समस्या हल करके देखनी चाहिए, तभी उसकी स्थिति ठीक से समझ में आएगी। नहीं तो हर बार वही बेकार बहस निकलती है: "तुमने इसे गलत इस्तेमाल किया", "मैंने कोशिश की थी, पर खास नहीं लगा"।
हाल के महीनों में agentic coding पर गहराई से काम करने के अनुभव के आधार पर, मैं पोस्ट की लगभग हर बात से सहमत हूँ। सबसे आधुनिक LLM फिलहाल सबसे आसान लगते हैं, लेकिन मुझे उम्मीद है कि open model भी जल्दी बराबरी कर लेंगे। आप LLM से नई approach सुझाने या पहले से जानी हुई approach सामने रखने को कह सकते हैं। कभी-कभी LLM चीज़ों को ज़रूरत से ज़्यादा जटिल बना देता है, लेकिन इसे पहले ही पहचानकर या refactoring माँगकर संभाला जा सकता है। नए-नए मॉडल आते रहेंगे तो स्थिति भी बदलती रहेगी। हर काम के लिए cutting-edge model ज़रूरी नहीं है। साधारण feature या bug fix के लिए Copilot भी काफ़ी अच्छा शुरुआती बिंदु है। काश लोग इन नए बदलावों के बीच तरह-तरह के प्रयोग करने और उनसे सीखने की प्रक्रिया का आनंद लें।
मैंने Claude के GitHub action का इस्तेमाल लगभग 10~20 issues implement करने और PR review के लिए किया है, और मेरा अनुभव यह है कि यह सचमुच hit-and-miss है, इसलिए अंधाधुंध automation की बजाय इसे augmentation tool की तरह इस्तेमाल करना ही सही है। छोटे बदलाव, अच्छी test coverage वाले छोटे feature या refactoring लगभग अपने-आप सफल हो जाते हैं। Action के रूप में चलाने का फायदा यह है कि उस दौरान मैं दूसरा काम कर सकता हूँ (और अगर issue भी Claude ही लिख दे तो और सुविधा होती है)। लेकिन मध्यम आकार से ऊपर के कामों में अक्सर ऐसा output आता है जो देखने में सही लगता है, पर वास्तव में काम नहीं करता। हो सकता है यह test coverage की कमी के लिए मेरी ज़िम्मेदारी भी हो, लेकिन ऐसा काफ़ी बार होता है। Issue को और विस्तार से लिखूँ या prompt के कई रूप दूँ, नतीजे फिर भी निराशाजनक रहते हैं। बड़े काम तो कहना ही क्या, वे निश्चित रूप से कठिन हैं। PR review feature छोटे और मध्यम कामों में उपयोगी है, लेकिन उसमें बेकार की जाँचें भी बहुत होती हैं। निष्कर्षतः, मुझे लगता है कि LLM के अपने-आप coding करने में अभी काफी समय है। छोटे कामों में issue लिखवा कर PR आने तक इंतज़ार करना सबसे efficient है। ज़्यादातर कामों (मध्यम आकार के) में मैं मुख्यतः Claude को direction देता हूँ और coding लगभग नहीं करनी पड़ती, इसलिए productivity निश्चित रूप से बढ़ती है। मैंने Gemini भी इस्तेमाल किया है, लेकिन उसे अपने हाल पर छोड़ दें तो code अप्रत्याशित स्तर तक बिखर जाता है। हम कंपनी के अंदर Copilot से PR review भी कराते हैं, पर उसका प्रभाव खास नहीं है। हालाँकि बड़े codebase में Gemini ज़्यादा उपयोगी हो सकता है।
OP से अलग, मैंने इस क्षेत्र में एक महीने तक गहराई से काम किया और पाया कि Gemini 2.5 PRO और Opus 4 abstract discussion, जैसे architecture, में बेहतर परिणाम देते हैं। और individual code implementation Sonnet को सौंपना अधिक efficient रहा। 2.5 PRO और Opus अक्सर सही उत्तर के आसपास घूमते रहते हैं और खुद ही बार-बार सुधार करते रहते हैं, जबकि Sonnet सीधे उत्तर तक पहुँचता है — हालांकि उसे काफ़ी detailed instructions चाहिए होती हैं।
यह पूरी तरह संभव बात है। वास्तव में Sonnet/Opus 4 सबसे अच्छे मामलों में ज़्यादा शक्तिशाली हो सकते हैं, लेकिन कुछ पहलुओं में वे Sonnet 3.5v2 (जिसे 3.6 भी कहते हैं) या यहाँ तक कि 3.7 से consistency या alignment में पीछे भी हो सकते हैं। मॉडल अपने-आप में जटिल object होते हैं, इसलिए domain के अनुसार कोई "कमज़ोर दिखने वाला" मॉडल भी बेहतर काम कर सकता है। इसके अलावा interactive environment और agent-oriented environment में reinforcement learning की तकनीकें अलग होती हैं, इसलिए मॉडल का performance इस बात पर भी निर्भर करता है कि आप उसे किस तरीके से इस्तेमाल कर रहे हैं।
वास्तविक internal statistical data में भी यह सामने आया है कि व्यावहारिक माहौल में Opus और Gemini 2.5 pro का प्रदर्शन Sonnet 4 से कम है संबंधित आँकड़ों का लिंक
मेरा अनुभव भी कुछ ऐसा ही है। Gemini 2.5 Pro को मैं AI Studio में बड़े design ideas को validate/refine करने के लिए इस्तेमाल करता हूँ, और जब requirements को Claude Code में ले जाता हूँ तो वह आम तौर पर साफ-सुथरी coding कर देता है। हाल में मैंने Gemini CLI भी आज़माया, लेकिन Claude Code की तुलना में उसकी coding क्षमता बहुत पीछे लगी। उसमें syntax errors भी ज़्यादा थे, वह loop से बाहर नहीं निकल पाता था, और output इतना verbose व तेज़ था कि उसका पीछा करना मुश्किल हो जाता था। दूसरी ओर Claude Code की debugging क्षमता शानदार है। "बड़ी तस्वीर" वाली problem solving के लिए DeepSeek R1 भी इस्तेमाल किया जा सकता है; वह बहुत धीमा है, लेकिन उसकी accuracy अच्छी है।
AI/LLM कभी-कभी बेहद inefficient code लिखता है — इसका एक व्यावहारिक उदाहरण यहाँ साझा किया गया है संबंधित ब्लॉग लिंक
मेरा अनुभव यह रहा है कि अगर पहले LLM से सिर्फ यह कहलवाया जाए कि वह मनचाहा काम कैसे करेगा, और मैं बीच-बीच में feedback देकर कुछ iterations करूँ, तो उसके बाद निकलने वाले code की quality काफी बेहतर होती है। पहले विस्तृत योजना की पुष्टि करवा लेना प्रभावी रहता है।
मेरे अनुभव में frontend पर वे दोहराए जाने वाले और सरल काम जिन्हें verify करना आसान हो, उन्हें vibe coding के हवाले किया जा सकता है। लेकिन सामान्यतः मैं LLM को अपने code का reviewer और अलग-अलग विकल्पों का मूल्यांकन करने वाले sparring partner की तरह इस्तेमाल करता हूँ। उसकी सिफ़ारिशें कभी-कभी बेतुकी हों या उनमें logical flaws हों, फिर भी वह मुझे यह देखने में मदद करता है कि कहीं मैं कोई बहुत obvious बात तो नहीं छोड़ रहा। यह मुझे जटिल रूप से उलझी हुई समस्याओं पर ज़रूरत से ज़्यादा प्रयास करने की अपनी आदत सुधारने में भी मदद करता है।
मुझे समझ नहीं आ रहा कि OP ठीक किस तरीके की बात कर रहा है। क्या वह सचमुच यह कह रहा है कि redis की C file को हाथ से Gemini Pro के web chat window में paste करो?