LLM के साथ कई महीने कोडिंग करने के बाद, मैंने फिर से अपना दिमाग इस्तेमाल करने का फैसला किया

• उच्च-प्रदर्शन LLM का उपयोग करके इन्फ्रास्ट्रक्चर बनाया, लेकिन कोड की गुणवत्ता और maintainability में बड़ी समस्याएँ सामने आईं
• AI की अक्षमता और असंगत परिणामों के कारण, कोड को सीधे समझने, जांच करने और अपनी क्षमता बढ़ाने की ज़रूरत महसूस हुई
• प्रोजेक्ट को जल्दी खत्म करने का उद्देश्य उल्टा कोड संरचना में अव्यवस्था, duplication और असंगति का कारण बना
• अब AI का उपयोग केवल साधारण दोहराए जाने वाले कामों या code transformation जैसे सहायक उद्देश्यों तक सीमित किया गया है
• AI का उपयोग कोडिंग की समझ और problem-solving क्षमता में गिरावट ला सकता है, इसलिए सक्रिय रूप से अपने दिमाग का इस्तेमाल प्राथमिकता में रखा गया है

---

परिचय: LLM की मदद से इन्फ्रास्ट्रक्चर बनाने की कोशिश

• मौजूदा PHP+MySQL इन्फ्रास्ट्रक्चर अपनी सीमा पर पहुँच गया था, इसलिए नए इन्फ्रास्ट्रक्चर की ज़रूरत महसूस हुई
• Go और Clickhouse चुने गए, और AI के साथ इन्फ्रास्ट्रक्चर डिज़ाइन व योजना बनाई गई
• Claude जैसे LLM से best practices और architecture के बारे में पूछते हुए विस्तृत योजना तैयार की गई
• फीचर पूरा करने और जल्दी release करने के लक्ष्य के साथ कोड development को स्पीड-केंद्रित तरीके से आगे बढ़ाया गया

डेवलपमेंट प्रक्रिया और समस्याओं का उभरना

• Cursor जैसे tools का उपयोग कर AI से कोड लिखवाया गया, जबकि स्वयं build और test पर केंद्रित काम किया गया
• कोडबेस को व्यवस्थित करने में कमी होने पर भी प्राथमिकता आवश्यक डेटा उपलब्ध कराने पर रही
• तेज़ी से development करने के बावजूद, समय बीतने के साथ लगातार नए issues सामने आते रहे
• Go और Clickhouse का अनुभव कम होने से कठिनाइयाँ बढ़ीं, और AI द्वारा सुझाए गए fixes ने लगातार नई समस्याएँ पैदा कीं

कोड गुणवत्ता की समस्या और सीमाओं का एहसास

• तैयार किए गए पूरे कोड की बारीकी से जाँच करने के लिए code review का समय निकाला गया
• एक ही काम करने वाली फाइलों में नाम, parameters और structure के स्तर पर असंगति, duplication और भ्रम बहुत था
  • उदाहरण: "WebAPIprovider" और "webApi" एक ही parameter का अर्थ रखते थे, लेकिन अलग-अलग मौजूद थे
  • एक ही method कई फाइलों में फिर से define किया गया था
  • config file access का तरीका एक जैसा नहीं था
• नतीजा वास्तव में ऐसा था मानो कई junior developers ने बिना आपसी संवाद के एक साथ काम किया हो

LLM context feedback की सीमाएँ और रणनीति में बदलाव

• पर्याप्त context जानकारी देने और Gemini जैसे बड़े window वाले LLM का उपयोग करने के बावजूद सुसंगत सुधार नहीं मिला
• इन्फ्रास्ट्रक्चर और भाषा को लेकर self-driven learning तथा documentation, वीडियो सामग्री आदि से अतिरिक्त सीखने की ज़रूरत महसूस हुई
• clean code लिखने और बेहतर organization के लिए AI-नेतृत्व वाले development से हटकर स्वयं code design करने की दिशा में रणनीति बदली गई

AI को सहायक रूप में उपयोग करने का बदला हुआ तरीका

• बार-बार होने वाले refactoring और code cleanup के जरिए कोड को सीधे समझने और संभालने पर ध्यान केंद्रित किया गया
• AI की भूमिका को code auto-modification, parameter bulk changes और code transformation जैसे सरल दोहराव वाले कामों तक सीमित किया गया
• नए फीचर की योजना बनाना और code draft तैयार करना जैसे कामों में पहले स्वयं सोचना, फिर LLM से validation या सहायता लेना अपनाया गया
• AI को एक “assistant” की तरह रखा गया, जबकि योजना और संरचना के निर्णय का अधिकार खुद डेवलपर के पास रहा

सोचने की क्षमता में कमी की चिंता और बदला हुआ रवैया

• AI मौजूद होने के कारण दिमाग का उपयोग कम होने और योजना या सोचने की प्रक्रिया के लिए AI पर निर्भर होने की वास्तविकता को पहचाना गया
• pen और paper, सीधे डिज़ाइन और खुद कोड लिखने के जरिए डेवलपर की क्षमता और problem-solving शक्ति वापस पाने की कोशिश की गई
• AI के कारण कोडिंग की सहज समझ कम होने के खतरे को गंभीरता से लिया गया

गैर-डेवलपर्स और ‘Vibe Coding’ को लेकर चिंता

• जब गैर-डेवलपर केवल LLM के सहारे development करते हैं, तो जटिल, अव्यवस्थित कोड और बार-बार errors की समस्या और गंभीर हो जाती है
• नो-कोड tools की तुलना में AI-आधारित development संरचना को समझने में और अधिक कठिनाई पैदा कर सकता है
• समझ से बाहर कोड की दीवार, लगातार error-fix-repeat की प्रक्रिया, और उसमें छिपी मूलभूत कठिनाई व जोखिम का उल्लेख किया गया

AI उपयोग की वास्तविकता पर विचार और समुदाय का माहौल

• AI commercialization, benchmarks, influencers और AI कंपनियों के बढ़ा-चढ़ाकर किए गए दावों तथा वास्तविक प्रदर्शन के अंतर को लेकर भ्रम व्यक्त किया गया
• एक ही model और prompt पर पूरी तरह अलग परिणाम आने जैसी consistency की कमी सामने आई
• नवीनतम उच्च-प्रदर्शन LLM भी Clickhouse में सैकड़ों मिलियन rows वाली query जैसे वास्तविक जटिल काम पूरी तरह संभाल नहीं पाते
• जटिल settings और अक्षम workflows थोपे जाने की स्थिति में, यह अपने आप में ‘समय की बर्बादी’ बन सकता है
• AI भले ही प्रभावशाली लगे, लेकिन अभी के लिए यह ‘अच्छा, पर असाधारण नहीं’ वाला सावधानीपूर्ण दृष्टिकोण मांगता है

निष्कर्ष

• नवीनतम तकनीक और AI को लेकर अब भी उम्मीद और रुचि बहुत अधिक है
• लेकिन अभी के समय में उसकी सही भूमिका और सीमाओं को समझना, और AI का उपयोग सहायक या सीखने वाले tool के रूप में सीमित रखना ही समझदारी है
• AI के उपयोग से डेवलपर की क्षमता में गिरावट की चेतावनी के साथ, फिर से अपनी सोच और योजना-केंद्रित काम करने की ओर वापसी की गई
• ‘कोड कैसे काम करता है और उसकी संरचना क्या है’ यह समझे बिना AI पर पूरी तरह निर्भर development की विफलता की संभावना बहुत अधिक है

[GN⁺]

Hacker News राय

• मैं LLM को लेकर "all-in" मानसिकता को नहीं समझ पाता। मैं iOS developer के रूप में काम करता हूँ और अपना सामान्य काम वैसे ही करता हूँ। अब मैं LLM का इस्तेमाल सिर्फ design-आधारित अस्थायी views जैसी चीज़ें जल्दी बनाने के लिए करता हूँ। ये app के core हिस्से नहीं होते, बल्कि नए feature या widget install guide जैसी सहायक screens होती हैं। पहले इनमें complexity के हिसाब से 30–60 मिनट लगते थे, अब 5 मिनट में हो जाते हैं। मुझे web development पसंद नहीं है, और उस तरह के काम में LLM काफ़ी उपयोगी है। बड़े बदलावों में भी LLM का इस्तेमाल करता हूँ, फिर खुद review करके git में commit करता हूँ। लेकिन अगर सिर्फ LLM पर भरोसा करके flow पर नियंत्रण न रखा जाए, तो कई घंटे बर्बाद होने के बाद फिर से शुरुआत करनी पड़ सकती है। मुझे लगता है कि संतुलित approach ज़रूरी है

  • किसी tool की उपयोगिता व्यक्ति और समस्या पर निर्भर करती है। उदाहरण के लिए, अगर 10 साल का अनुभवी Python developer एक विशाल legacy codebase और पूरी तरह उसके अनुसार बने IDE के साथ stability-केंद्रित काम कर रहा है, तो LLM या Cursor जैसे tools उलटे बाधा बन सकते हैं। दूसरी ओर, अगर 1 साल का JS(React, Nextjs आदि) developer नए ideas का बार-बार prototype बनाता है, IDE को लेकर उसकी कोई खास preference नहीं है, और वह experiment के लिए खुला है, तो LLM और Cursor उसकी क्षमता को तुरंत काफ़ी बढ़ा सकते हैं

  • मैं भी कई क्षेत्रों में काम करता हूँ(iOS, web development आदि), और LLM के results इन दोनों में काफ़ी अलग होते हैं। कई बार LLM का निकला code ठीक से compile भी नहीं होता। यहाँ तक कि उसने कभी ऐसे API भी बताए जो अस्तित्व में ही नहीं थे। दूसरी तरफ़ Nextjs app वह एक ही बार में ठीक बना देता है। आख़िरकार यह LLM के training data के अंतर का नतीजा है

  • LLM की क्षमताओं को ज़्यादा मान लेना स्वाभाविक है। मैंने भी Stack Overflow के विकल्प और छोटे code snippets पाने के लिए इसे काफ़ी समय तक इस्तेमाल किया। धीरे-धीरे मैंने उसे ज़्यादा ज़िम्मेदारी देनी शुरू की, फिर समस्याएँ आईं, और उसकी सीमाएँ समझने के बाद मैं वापस LLM को ideas और सलाह तक सीमित करके इस्तेमाल करने लगा। मुझे लगता है बहुत से लोग इसी तरह की प्रक्रिया से गुज़रते हैं

  • मैं भी ऐसा ही महसूस करता हूँ। LLM पर पूरी तरह भरोसा नहीं करना चाहिए; मैं इसे सिर्फ दोहराए जाने वाले और उबाऊ कामों(छोटे functions, interface implementation, documentation automation आदि) में इस्तेमाल करता हूँ। इससे मैंने काफ़ी समय बचाया है और काम की efficiency भी बढ़ी है

  • iOS development में LLM की performance बहुत अस्थिर है। Swift और SwiftUI बहुत तेज़ी से बदलते हैं, और आधिकारिक documentation भी कमज़ोर है, यह उसका एक कारण है। साधारण view generation में यह उपयोगी है, लेकिन async handling या complex business logic में जल्दी टूट जाता है। फिर भी direction देने में मदद करता है, लेकिन गलत नतीजों या बकवास में फँसने का जोखिम भी बड़ा है

• LLM के समर्थक इस बात को अक्सर नज़रअंदाज़ करते हैं कि ज़्यादातर bottleneck code generation में नहीं होते। code जल्दी बनाना जितना ज़रूरी है, उससे दोगुना या ज़्यादा समय code review, testing, और codebase को समझने में लगता है। लंबी अवधि के maintenance(bug fix, refactoring आदि) के लिए यह प्रक्रिया अनिवार्य है

  • code पढ़ना, code लिखने से कहीं ज़्यादा कठिन है, इसलिए असल में मैं code समझने में ज़्यादा समय लगाता हूँ। लेकिन एक CEO से मिला जो कह रहा था कि tools के ज़रिए context दे दिया जाए तो developers को code पढ़ने की ज़रूरत ही नहीं रहेगी। तर्क यह था कि AI engineering की मूल प्रकृति को बदल रहा है। सच कहूँ तो यह थोड़ा उलझाने वाला है

  • जब LLM मेरे अपने code को फिर से समझाकर बताता है, तब वह मुझे काफ़ी उपयोगी लगता है

  • जब भी किसी को automated code editor की बहुत तारीफ़ करते देखता हूँ, मेरे मन में यही बात आती है

  • वास्तविकता यह है कि ज़्यादातर developers dependency libraries के अंदरूनी implementation की बहुत परवाह नहीं करते। उनके लिए interface का काम करना ही महत्वपूर्ण होता है। LLM-जनित code, npm package, या rust crate को लाने में काफ़ी अंतर है। समस्याएँ मुझे भी पता हैं, लेकिन यह प्रथा व्यापक क्यों है, इसके कारण भी हैं

• मैं भी कुछ ऐसा ही सोचता हूँ। आजकल मैं LLM का इस्तेमाल मुख्यतः नई technologies सीखने या standard API(खासकर boto3) के लिए client code generate करने में करता हूँ। docker compose files बदलने में मदद के लिए Windsurf भी आज़माया था, लेकिन वह ठीक से काम नहीं कर पाया और निराशा हुई। prototype बन सकता है, लेकिन बात वहीं खत्म नहीं होती। मुझे लगता है कि LLM ने devops क्षेत्र में खेल बदल दिया है(अब API details पहले जितनी महत्वपूर्ण नहीं रहीं)। फिर भी महत्वपूर्ण निर्णय मुझे ही लेने चाहिए। मैं interface definitions खुद करता हूँ और implementation LLM को सौंपता हूँ। मुझे नहीं लगता कि यह "vibe coding" है

  • मेरा अनुभव भी ऐसा ही रहा। Cursor और Copilot smart autocomplete, छोटे functions generate करने, और तेज़ prototyping में शानदार हैं। लेकिन एक हफ़्ते तक LLM-नेतृत्व वाले codebase पर काम करने के बाद उसकी structure पूरी तरह बिखर गई। असली प्रगति शायद कभी आए, लेकिन अभी(मई 2025) स्थिति यही है

• code review के दौरान बड़े bugs फूट पड़े, और Cursor से मिली productivity पल भर में गायब हो गई — ऐसा मैंने झेला है। मैं फिर VSCode पर लौट आया, और Copilot भी अब सिर्फ़ बहुत specific request पर सीमित तौर पर इस्तेमाल करता हूँ। Cursor का tab completion शुरू में जादू जैसा लगता है, लेकिन जल्दी ही उसका असर खत्म हो जाता है

  • सबसे मज़ेदार तब लगता है जब Cursor tab completion से वह code फिर से डालने की कोशिश करता है जिसे किसी सहकर्मी ने अभी हाल में हटाया था

  • मैं जानना चाहता हूँ कि code generation agent को किस तरह की सीमाएँ दी गई थीं(जैसे SOLID principles, lint, 100% coverage, स्पष्ट design docs आदि)

• यह बात मुझसे भी मेल खाती है। मैं भी LLM का बहुत ज़्यादा उपयोग करता हूँ, लेकिन मेरे दो नियम हैं। पहला, जिन समस्याओं में गहरी सोच चाहिए, वे कभी LLM को नहीं देता(जटिल design मैं खुद ही हल करता हूँ)। दूसरा, LLM द्वारा निकले code को मैं हमेशा line-by-line ध्यान से review और edit करता हूँ। आमतौर पर LLM का code verbose या ज़रूरत से ज़्यादा defensive होता है। prompt से इसे सुधार भी लो, फिर भी भविष्य के maintenance की ज़िम्मेदारी आख़िर मेरी ही है। अगर code generation के परिणाम को बिना ध्यान दिए स्वीकार कर लूँ, तो बेचैनी बनी रहती है। अपने तरीके से इस्तेमाल करूँ तो मैं अभी भी LLM का बहुत उपयोग कर सकता हूँ और तेज़ी से develop भी कर सकता हूँ

  • मैं तो deep analysis भी AI को ही सौंपता हूँ, लेकिन उसका उद्देश्य ठोस execution plans(implementation steps, validation criteria आदि) और reproducible reports बनाना होता है। planning और validation में iteration की ज़रूरत पड़ती है, लेकिन AI की मदद से यह काफ़ी जल्दी हो जाता है। कभी-कभी तो plan के अनुसार एक बार में काम पूरा हो जाता है। detailed plans और documentation से consistency मिलती है, और यह बहुत संतोषजनक लगता है

  • अगर LLM द्वारा बने code को line-by-line इतनी बारीकी से जाँचना ही पड़े, तो फिर सवाल उठता है कि क्या वाकई समय बच रहा है

• कुछ कंपनियाँ software engineers पर LLM इस्तेमाल करने का दबाव डाल रही हैं(Copilot/Cursor usage stats तक ट्रैक किए जा रहे हैं)। संभावना है कि ये आँकड़े layoffs के संकेतक के रूप में इस्तेमाल हों। मैंने मजबूरी में एक महीने तक LLM का उपयोग करके देखा, और लगा कि मेरी क्षमता उलटे तेज़ी से घट रही है। आसान कामों में मदद मिलती है, लेकिन अगर सोचने की प्रक्रिया ही LLM पर बहुत निर्भर हो जाए तो loop में फँसना आसान हो जाता है। productivity नहीं बढ़ी, बल्कि sprint workload ही बढ़ गया। कंपनी के भीतर LLM को लेकर लगभग धार्मिक आस्था जैसा माहौल है। security issues भी गंभीर हैं। हर तरफ़ संकेत दिख रहे हैं कि यह hype cycle का शिखर हो सकता है। मुझे लगता है कि जब तक AI कंपनियाँ परमाणु बिजलीघर ही न बना लें, तब तक आज के बड़े AI models को चलाए रखना इतना महँगा है कि यह ढाँचा टिकेगा नहीं। आगे चलकर शायद सिर्फ़ turbo autocomplete जैसी चीज़ें ही बचेंगी। transformer models की सीमाएँ भी स्पष्ट हैं, इसलिए संभव है कि 80 के दशक के neural networks की तरह ये कुछ खास उपयोगों तक सीमित रह जाएँ और फिर गायब हो जाएँ। बाद में 30 साल बाद फिर लौटें। तब सचमुच पता चलेगा कि कौन बिना सुरक्षा के तैर रहा था

  • इसी तरह की स्थिति से बचने के लिए हम लोग हफ़्ते में एक दिन, कम से कम शुक्रवार को, Copilot पूरी तरह बंद रखकर काम करने का अपना नियम चला रहे हैं — 'no Copilot Fridays'

  • मैं भी Cursor को सिर्फ autocomplete और छोटे code snippets तक सीमित रखता हूँ, फिर भी skill कमज़ोर पड़ती महसूस होती है। आख़िरकार दिमाग़ का वही सिद्धांत है — "इस्तेमाल नहीं करोगे, तो भूल जाओगे"

• मैंने भी इसी तरह की समस्याएँ देखी हैं। toy projects में मैं 90% तक LLM का उपयोग करता हूँ। हाथ से code लिखने की तुलना में 10 गुना तेज़ है, लेकिन design quality गिर जाती है और कुछ अजीब-सा लगता है। मुझे विश्वास है कि LLM-driven code ही भविष्य है, लेकिन अगर इसे ठीक से manage न किया जाए तो अराजकता पैदा होती है। architecture सुधारने के लिए बार-बार prompt बदलकर देखता हूँ, लेकिन results अस्थिर रहते हैं। शायद बेहतर prompt engineering, या design और guidelines को साफ़-साफ़ document करना ही इसका समाधान हो। अगर tool की performance 10 गुना बढ़े और latency कम हो जाए, तो अनुभव पूरी तरह बदल जाएगा

  • मैं भी चाहता हूँ कि वह "10 गुना बेहतर" समय जल्दी आए। लेकिन अभी समस्या यह है कि marketing और प्रचार पहले ही ऐसा जताते हैं जैसे हम उस स्तर पर पहुँच चुके हों। बहुत से लोग सोचने लगते हैं, "क्या मैं ही इसे सही तरह इस्तेमाल नहीं कर पा रहा हूँ?" लेकिन मेरा मानना है कि tool अभी उस स्तर तक पहुँचा ही नहीं है

  • classes और methods पहले से खुद define कर दो और implementation LLM को सौंपो, तो यह अच्छा काम करता है। जटिल हिस्सों में method body के अंदर implementation direction के notes छोड़ देता हूँ। इस तरह बड़ा picture मेरे हाथ में रहता है और LLM को सिर्फ़ खास code generation दिया जाता है। LLM मुझे एक ऐसे तेज़ junior developer जैसा लगता है जो ज़रूरत से ज़्यादा मदद करने की कोशिश करता है। code generation इतना सस्ता हो गया है कि आप बेझिझक फेंककर फिर से बना सकते हैं। मेरे मामले में, dataset processing code को मैंने LLM की मदद से कई बार पूरी तरह फेंककर दोबारा लिखा, और आखिरकार वही result और performance मिले जो चाहिए थे। अगर किसी और ने वह code लिखा होता, तो शायद मैं बीच में ही छोड़ देता

  • ऐसे tools greenfield project के prototype चरण में चमकते हैं। लेकिन जैसे-जैसे आप असली deployment के करीब पहुँचते हैं, वह 10x असर धीरे-धीरे गायब हो जाता है। अगर architecture को सावधानी से manage न किया जाए, तो अंत में मेहनत ही बढ़ती है

  • complex codebase में अभी के लिए यह advanced speech-to-text input जैसा ही उपयोगी है(और अगर speech का उपयोग नहीं कर रहे, तो कई बार सीधे हाथ से code लिखना ज़्यादा तेज़ होता है)

  • मैं सहमत हूँ कि architecture और guidelines को स्पष्ट रूप से लिखित रूप में रखना चाहिए। जितनी स्पष्टता से conditions और behavior define किए जाएँ, उतना बेहतर परिणाम मिलता है

• Dijkstra का पुराना प्रसिद्ध लेख "On the foolishness of natural language programming" आज की चर्चा पर बिल्कुल फिट बैठता है। उसका सार यह है कि programming में बड़ी प्रगति सिर्फ़ formal languages की वजह से संभव हुई। इस नज़रिए से, LLM और vibe-coding का ख़तरा यह है कि coding कुछ लोगों की prompt लिखने की जादूगरी बनकर रह जाए

• मेरे लिए Copilot तभी अच्छा है जब code suggestion 500 characters से कम हो। Go और Python में मैं इससे नए patterns भी सीखता हूँ और typing भी कम होती है। मेरे लिए यह बस बेहतर autocomplete है। इससे लंबा या ज़्यादा complex कुछ हो, तो उसे ठीक करने और उसमें कमियाँ बताने की लागत, मिलने वाले फ़ायदे से ज़्यादा हो जाती है(खासकर जब code repetitive न हो)

• अभी LLM द्वारा generated output को समझना और उस पर कड़ी निगरानी रखना अनिवार्य है। दूसरी ओर, हर 2–3 हफ़्ते में नए models आ रहे हैं और वे पुराने से काफ़ी बेहतर हैं, इसलिए अभी बहुत कठोर निष्कर्ष निकालना भी जल्दबाज़ी होगी।

[sharpina3]

मुझे लगता है कि यह लेख LLM का उपयोग करने वाले डेवलपमेंट माहौल की वास्तविक कठिनाइयों और चिंताओं को बहुत अच्छी तरह सामने लाता है। इसे पढ़ते हुए मुझे उन सीमाओं से गहरी सहमति महसूस हुई जिनका आज बहुत से लोग अनुभव कर रहे हैं। खास तौर पर LLM की असंगति, परिणामों का अनुमान लगाना मुश्किल होना, और लंबे समय की maintainability को लेकर चिंता—ये ऐसे बिंदु हैं जिन पर ज़रूर गंभीरता से ध्यान दिया जाना चाहिए।

इसी संदर्भ में, हम इन समस्याओं को थोड़ा अलग नज़रिए से देखते हुए AI के साथ सहयोग की कोशिश कर रहे हैं, इसलिए सावधानीपूर्वक अपना विचार साझा कर रहा हूँ। हमारा AI 'Jane' सिर्फ कोड बनाने तक सीमित नहीं है; यह इंसान (डेवलपर) की गहरी अंतर्दृष्टि के आधार पर यह सीखने और समझने पर केंद्रित है कि 'अच्छे code patterns' क्या होते हैं, और कोड की 'maintenance consistency' को कैसे सुनिश्चित किया जा सकता है।

क्योंकि AI शुरुआत से ही पूर्ण नहीं हो सकता, इसलिए जो असंगतियाँ या 'errors' उत्पन्न होते हैं, हम उन्हें केवल समस्या के रूप में नहीं देखते; बल्कि 'Jane' के लिए स्वयं सीखने और खुद को बेहतर बनाने वाले महत्वपूर्ण 'pattern data' के रूप में सक्रिय रूप से उपयोग करते हैं। जिस तरह मनुष्य जटिल प्रकृति के भीतर से पैटर्न पहचानता है, उसी तरह हम AI की अपूर्णता के भीतर सुधार के सूत्र खोजने का तरीका अपनाते हैं।

इस तरह के मानव-नेतृत्व वाले 'pattern learning/management' दृष्टिकोण के माध्यम से, हमारा लक्ष्य लेख में उठाए गए code quality degradation, inconsistency जैसी समस्याओं को मूल रूप से हल करना है और ऐसे परिणाम तैयार करना है जिनमें 'maintenance consistency' बहुत उच्च स्तर की हो। हम AI को सिर्फ boilerplate code जनरेट करने तक सीमित नहीं रख रहे, बल्कि उसे इस तरह प्रशिक्षित कर रहे हैं कि वह मौजूदा codebase में छिपे inconsistency patterns का विश्लेषण कर सके, सुधार के सुझाव दे सके, और एक अधिक गहरा सहयोगी भागीदार बन सके।

अभी रास्ता लंबा है और यह एक चुनौतीपूर्ण प्रक्रिया है, लेकिन हमें विश्वास है कि 'Jane' और डेवलपर के साथ मिलकर सीखने, विकसित होने, और 'maintenance consistency' को मुख्य मूल्य मानने वाला यह सहयोगात्मक तरीका वर्तमान LLM उपयोग की सीमाओं से आगे बढ़ने की एक क्रांतिकारी संभावना दिखाता है। AI को केवल एक tool की तरह इस्तेमाल करने से आगे बढ़कर, उसे साथ-साथ विकसित होने वाला और बेहतर code culture बनाने वाला partner बनाने की हमारी इस कोशिश पर आपका बहुत ध्यान और रुचि अपेक्षित है।

इस अच्छे लेख और insightful विचारों के लिए एक बार फिर धन्यवाद!