मैंने LLM का उपयोग कम करने का फैसला क्यों किया

• 15 साल के अनुभव वाले software engineer Alberto Fortin ने LLM (Large Language Model) अपनाने को लेकर बड़ी उम्मीदें रखी थीं, लेकिन वास्तविक production environment में उन्हें कई सीमाओं का सामना करना पड़ा
• Go और ClickHouse आधारित infrastructure को फिर से बनाने की प्रक्रिया में उन्होंने AI की हकीकत और भ्रम दोनों को महसूस किया, और मॉडल में सुधार के बावजूद मुख्य समस्याओं का पर्याप्त समाधान नहीं देखा
• उन्होंने कहा कि productivity बढ़ने का एक भ्रम मौजूद है, जबकि व्यवहार में bugs और अनपेक्षित समस्याएँ और बढ़ जाती हैं
• उन्होंने इस बात पर ज़ोर दिया कि LLM को assistant की तरह देखना चाहिए, और मुख्य design व decision developers को खुद लेने चाहिए
• "AI क्रांतिकारी है, लेकिन अभी पूर्ण नहीं है, इसलिए संतुलित उपयोग और ठंडी, यथार्थवादी समझ की ज़रूरत है"

---

Alberto Fortin का LLM अनुभव और पुनरावलोकन

• 15 साल के अनुभव वाले software engineer Alberto Fortin ने development work में LLM को सक्रिय रूप से अपनाया और उनसे बड़ी उम्मीदें रखीं
• Go और ClickHouse का उपयोग करके infrastructure को फिर से बनाने की प्रक्रिया में, कई चुनौतियों और सीमाओं से टकराने के बाद उन्होंने AI और वास्तविक development के बीच के अंतर पर एक blog post लिखी
• इसके बाद हाल की अतिरिक्त analysis के जरिए उन्होंने यह जाँचा कि Claude Opus 4 जैसे नए models ने क्या इन समस्याओं को हल किया है

• Alberto का अनुभव उन engineers के लिए व्यावहारिक सबक देता है जो कार्यस्थल में LLM अपनाने पर विचार कर रहे हैं, और यह भी दिखाता है कि tool कहाँ value देता है और उसकी सीमा कहाँ तक है

LLM अनुभव पर Alberto के प्रमुख उद्धरण

> "मुझे सच में हैरानी हुई कि मामला सिर्फ गलत काम करने या feature के काम न करने तक सीमित नहीं था। एक developer के रूप में जिसे अगले कई साल तक इस code को maintain करना है, code का काफी साफ-सुथरा होना ज़रूरी है।"

> "लगता था कि समस्या अभी हल हो जाएगी, लेकिन फिर अगली बार एक नया error सामने आ जाता था, और उसे ठीक करने में फिर लगभग 2 हफ्ते लग जाते थे। यह अनुभव बार-बार दोहराया गया।"

> "जब error output को LLM को देते हैं, तो वह नया answer तो देता है, लेकिन अक्सर कुछ और अनावश्यक रूप से उलझा देता है या किसी दूसरे हिस्से को खराब कर देता है।"

LLM से जुड़ी अत्यधिक उम्मीदों पर समझ

> "जब पहली बार छोटे features जैसे शुरुआती autocomplete का उपयोग किया गया, तो सभी developers हैरान रह गए। ऐसा लगता है जैसे वह मेरे विचार पढ़ रहा हो, और इसी से अपेक्षाएँ बहुत बढ़ जाती हैं।"

> "ऐसा महसूस होने लगता है कि development productivity 10 गुना तक बढ़ सकती है, लेकिन वास्तव में हम इतनी बड़ी उम्मीद बहुत जल्दी पाल लेते हैं।"

भूमिका और अपेक्षाओं की पुनर्परिभाषा

> "सबसे बड़ा अंतर भूमिका की समझ में बदलाव है। मैं architect और senior developer हूँ, और LLM केवल मेरा सहायक है। योजना मैं बनाता हूँ, LLM सहायक की भूमिका निभाता है।"

> "विश्वास खोने के बाद मैं अब उसे महत्वपूर्ण features नहीं सौंपता। मैं उसका उपयोग केवल refactoring जैसे छोटे units में करता हूँ।"

> "मैंने bugs को खुद ठीक करना शुरू किया। जब आप codebase को पूरी तरह समझते हैं, तो समस्या को खुद हल करना काफी ज़्यादा तेज़ और प्रभावी होता है।"

LLM को देखने के नज़रिए में बदलाव और सलाह

> "एक senior developer के रूप में मैंने खुद स्वीकार किया कि LLM को अपनाना मेरे लिए सही फिट नहीं बैठा, और यह मेरी क्षमता की कमी नहीं है। अपने मौजूदा काम करने के तरीके को बनाए रखते हुए AI का सहायक रूप में उपयोग करना ही मुख्य बात है।"

> "तकनीकी प्रगति के ज़रिए एक स्तर की प्रगति ज़रूर हुई है, लेकिन हम अभी अगले स्तर तक नहीं पहुँचे हैं। decision-making और architecture अब भी इंसानों को ही संभालने चाहिए।"

> "AI क्रांति अद्भुत है, लेकिन अभी संतुलित और यथार्थवादी अपेक्षाएँ ज़रूरी हैं।"

[tested]

> https://hi.news.hada.io/topic?id=20955

[GN⁺]

Hacker News राय

• मुझे लगता है कि मैं HN पर बहुत ज़्यादा समय बिता रहा हूँ, क्योंकि लगभग हर पोस्ट और कमेंट में वही बातें बार-बार दिखती हैं। LLM दिलचस्प हैं, लेकिन इनके द्वारा जनरेट किया गया कोड जटिल होता है, उसमें अपना स्वामित्व-भाव नहीं होता, और वह हाथ से लिखे गए कोड की तरह दिमाग में पूरी संरचना के रूप में नहीं बैठता, इसलिए उसे मैनेज करना कठिन हो जाता है। जिन छोटे स्क्रिप्ट्स को लंबे समय तक मेंटेन नहीं करना है, उनके लिए यह उपयोगी हो सकता है, लेकिन बड़े प्रोजेक्ट्स में समस्या बनता है। दूसरी ओर कुछ लोग कई LLM एजेंट लगाकर अलग-अलग काम बाँटने और बाद में उन्हें मर्ज करने वाले वर्कफ़्लो को शानदार बताते हैं, लेकिन वे असली कोड दिखाने के बजाय सिर्फ़ डींगें मारते हुए लगते हैं

  • मुझे लगता है कि इस बात का सार सच में मुद्दे की जड़ पकड़ता है। LLM डेवलपमेंट की गति बहुत बढ़ा देते हैं, लेकिन क्योंकि मैं पूरे कोड को खुद नहीं समझता, इसलिए यह पकड़ना मुश्किल हो जाता है कि कब और कहाँ कोई समस्या आई। आखिरकार ऐसा लगता है जैसे कोई नया डेवलपर अपने ही प्रोजेक्ट में ढलने की कोशिश कर रहा हो। इसलिए मैं कोड बार-बार commit करता हूँ, और समय-समय पर LLM से कोड की व्याख्या फिर से माँगता हूँ। इस प्रक्रिया में कई बार LLM अपने ही bugs भी पकड़ लेता है। मुख्यतः data analysis जैसे सीमित दायरे वाले कामों में इसे पर्याप्त नियंत्रण के साथ तेज़ी से इस्तेमाल किया जा सकता है। इसके उलट, बड़े codebase में LLM को सही तरह इस्तेमाल करने की क्षमता और आदत न हो तो चीज़ें आसानी से बिखर सकती हैं। prompt लिखना, context मैनेज करना, गति नियंत्रित करना, काम को व्यवस्थित करना, और LLM के output को सटीक रूप से review करना — ये सब LLM इस्तेमाल करने की अनिवार्य क्षमताएँ हैं। अभी तक कोई इन्हें औपचारिक रूप से नहीं सिखाता, इसलिए सब लोग trial and error से सीख रहे हैं। फिर भी एक बार इसका स्वाद मिल जाए तो पुराने तरीके पर लौटना मुश्किल लगता है, क्योंकि उबाऊ या दोहराए जाने वाले काम LLM को सौंपे जा सकते हैं। 20 साल से ज़्यादा डेवलपमेंट करते हुए अब मुझमें पहले जैसी धैर्य-शक्ति भी नहीं रही, और जिन ideas को लागू करने का तरीका मैं ठीक से नहीं जानता, उन्हें भी LLM को देकर कहीं अधिक दक्षता से काम किया जा सकता है

  • मुझे programming को 'theory building' की प्रक्रिया के रूप में देखने का विचार पसंद है। Programming as Theory Building देखें। AI के उपयोग से मुझे कोई आपत्ति नहीं है। लेकिन जनरेट किए गए कोड के नतीजों की ज़िम्मेदारी से बचने वाले रवैये का मैं समर्थन नहीं करता। जैसे grep जैसे tools का उपयोग करते समय भी, tool से मिले नतीजों की ज़िम्मेदारी लेकर ही उन्हें संभालना सार्थक होता है। जनरेट किया गया कोड तो और भी ज़्यादा ऐसा है, इसे सिर्फ़ disclaimer देकर छोड़ नहीं सकते

  • AI से जुड़ी पोस्ट्स से थकान महसूस होना समझ में आता है। राय बँटी हुई है, यह सच है। फिर भी, ऐसे उदाहरण हैं जहाँ लोग वास्तव में अपना कोड सार्वजनिक करते हैं। Flask/Jinja2/Sentry के निर्माता Armin Ronacher ने YouTube पर workflow वीडियो और अपनी बनाई AI लाइब्रेरी का परिचय डाला है, और मैं भी अपने open source प्रोजेक्ट्स का लगभग 50%~80% AI से बना रहा हूँ। cijene-api देखें

  • ऐसा लगता है कि users का समूह bell curve की तरह बँटा हुआ है। एक तरफ़ वे लोग हैं जो LLM के बहुत अधिक, अपनी शैली के कोड से overwhelmed हो जाते हैं, इसलिए context उनके दिमाग में नहीं बैठता। दूसरी तरफ़ वे लोग हैं जो अकेले कुछ लागू ही नहीं कर सकते थे, लेकिन LLM की वजह से अब कुछ भी बनाकर देखने का रास्ता खुल गया है। और एक और तरफ़ वे लोग हैं जो खुद धीरे-धीरे implementation कर सकते थे, लेकिन LLM को junior developers की फ़ौज की तरह इस्तेमाल करके सिर्फ़ एल्गोरिद्म के ऊपरी स्तर को याद रखने पर ध्यान देते हैं, और कहीं बड़े प्रोजेक्ट्स को तेज़ी से खड़ा कर लेते हैं

  • मुझे लगता है कि यह 25 से ज़्यादा डेवलपर्स के एक साथ शामिल बड़े codebase में काम करने से बहुत अलग नहीं है। मेरी organization में 160 engineers frontend और mid-tier पर काम करते हैं, और हमें हमेशा ऐसे कोड में खंगालना पड़ता है जिसमें कोई ownership नहीं होती, और git blame में 3 साल पहले के किसी outsourced developer का नाम आना आम बात है। LLM छोटे पैमाने पर ठीक लगते हैं, मध्यम पैमाने पर फिट नहीं बैठते, और बड़े प्रोजेक्ट्स में छोटे modules के रूप में फिर से ठीक लगते हैं

• LLM मेरे लक्ष्यों को हासिल करने में बहुत मदद करते हैं, लेकिन मुझे लगता है कि वे मेरी खुद programming करने की क्षमता को कमज़ोर भी करते हैं। जैसे steroids से मांसपेशियाँ जल्दी बढ़ती हैं, लेकिन side effects बहुत होते हैं, और छोड़ते ही सब अचानक ढह जाता है। कंपनियों को स्वास्थ्य नहीं, सिर्फ़ तेज़ नतीजों की चिंता होती है, इसलिए यह प्रवृत्ति और बढ़ जाती है। अब मैंने इन्हें सीमित और नियंत्रित तरीके से इस्तेमाल करना शुरू किया है

  • steroids वाली तुलना प्रभावशाली लगी। इससे Cal Newport के ब्लॉग की हाल की पोस्ट याद आ गई, जिसमें कहा गया था कि AI हमें आलसी बना सकता है। शोधकर्ता EEG data भी दिखाते हैं कि AI की मदद के बिना काम करने वालों में दिमाग़ी गतिविधि अधिक सक्रिय होती है। फिर भी इसका मतलब यह नहीं कि AI को हर क्षेत्र में प्रतिबंधित कर देना चाहिए। email जैसे गैर-मुख्य कामों में इसका उपयोग ठीक हो सकता है, लेकिन असली core work में इससे बचना बेहतर है। ब्लॉग देखें

• ऐसा लगता है कि LLM की वजह से बहुत से डेवलपर्स "Simple Made Easy" में ज़ोर देकर बताई गई सीख भूल गए हैं। LLM 'Ball of Mud' (ऐसा बेतरतीब कोड जो जटिल हो और जिसे refactor या maintain करना मुश्किल हो) बनाने में बहुत माहिर है। असली ताकत जटिल समस्या को छोटे हिस्सों में तोड़ने, हर छोटे component को सरल ढंग से काम करने देने, और उनके परस्पर interaction से जटिलता लागू करने में है। अगर हर component सरल हो, तो उसे समझना, debug करना और performance का अनुमान लगाना आसान होता है। अगर LLM सच में इस सिद्धांत का अच्छी तरह पालन करने लगें, तब शायद सचमुच डेवलपर्स की ज़रूरत ही न रहे

  • सच तो यह है कि हम LLM को मनचाही दिशा सीधे बता भी सकते हैं। जो लोग LLM को उपयोगी मानते हैं और जो नहीं मानते, उनके बीच का फ़र्क इस बात पर निर्भर करता है कि वे LLM की strengths और weaknesses को कितना समझते हैं, और क्या वे यह अनुमान लगा सकते हैं कि input (prompt) के अनुसार output की quality बदल जाएगी। उदाहरण के लिए, मैं LLM से यह पूछना पसंद करता हूँ कि किसी जटिल समस्या को कैसे तोड़ा जाए, ताकि देख सकूँ कि कहीं मैंने कुछ मिस तो नहीं किया, और उसके बाद ही उसे ठोस implementation सौंपता हूँ। मैं बिना किसी निर्देश के पूरे बड़े प्रोजेक्ट को जनरेट करने के लिए नहीं कहता

  • 'Ball of Mud' की समस्या सिर्फ़ कोड में नहीं होती। मेरे कार्यस्थल पर भी कुछ leaders "AI को आक्रामक रूप से अपनाएँ" जैसी बात करते हैं, और मैंने deployment system तथा जटिल operations तक को AI से चलाने का विचार देखा है। आखिरकार यह जटिल systems के ऊपर एक और जटिल black box बैठाने जैसा है, और तर्क यह बनता है कि "black box को समझने के लिए एक नया black box चाहिए" — मुझे यह बिल्कुल तर्कसंगत नहीं लगता। संगठन के भीतर का दबाव भरा माहौल कभी-कभी मुझे ऐसा महसूस कराता है जैसे शायद मैं ही अजीब सोच रहा हूँ

  • मैं सोचता हूँ कि अगर LLM सच में परफ़ेक्ट हो जाएँ, तो क्या वाकई डेवलपर्स की ज़रूरत खत्म हो जाएगी। मुझे नहीं लगता कि कोई भी 24/7 software को लगातार "उत्पादित करने वाली मशीन" की तरह चलते देखना चाहेगा। अंततः फिर भी ऐसे लोगों की ज़रूरत होगी जो समस्याओं को तोड़ें, और यह पहचानें कि वास्तव में किस software की आवश्यकता है, फिर उसे बनाएँ। आज हम उन्हें software developers कहते हैं

• अंत में मैं भी लगभग इसी निष्कर्ष पर पहुँचा हूँ। LLM पूरे codebase को autocomplete की तरह भरने में खास अच्छे नहीं हैं। समस्या यह है कि दिमाग़ में यह मॉडल ही गायब होने लगता है कि क्या कहाँ क्या कर रहा है। personalized StackOverflow की तरह, मैं LLM का उपयोग सिर्फ़ keywords की व्याख्या, कम परिचित concepts का सार, और दिशा-सुझाव जैसी चीज़ों के लिए करता हूँ, जबकि असली implementation और decision-making खुद संभालता हूँ — यह कहीं अधिक efficient रहा

  • मैं भी इसे इसी तरह इस्तेमाल करता हूँ, लेकिन cursor लगातार कोड बदलने के लिए ज़िद्दी सुझाव देता रहता है। यह जाने बिना कि codebase की सामग्री को छुए, उससे सिर्फ़ introspect कैसे कराया जाए — इसकी कोई तरकीब जानने की उत्सुकता है

  • मेरे मामले में ऐसा नहीं है। अगर मैं LLM द्वारा सुझाए गए कोड को हमेशा ध्यान से review करूँ, तो मुझे काफ़ी स्पष्ट रूप से समझ आ जाता है कि क्या कहाँ है और कैसे interact कर रहा है

• मैं भी उपयोग की आवृत्ति काफ़ी कम कर रहा हूँ। LLM के जवाब अक्सर गलत निकले हैं। इसलिए आजकल मैं उससे सिर्फ़ यह पूछता हूँ कि 'कौन-से manual या document' में देखना चाहिए, और असली सामग्री खुद जाकर जाँचता हूँ। यह तरीका जानकारी कहाँ मिलती है, यह समझने की क्षमता बढ़ाने में मदद करता है, और search engine व LLM पर निर्भरता भी कम करता है। LLM सिर्फ़ एक tool है, और इसकी accuracy भी कमज़ोर हो सकती है

• एक बिंदु ऐसा था जिसका कहीं ज़िक्र नहीं हुआ: LLM कभी-कभी productivity घटा भी सकते हैं। जब वे विश्वसनीय लगने वाले जवाब के साथ गलत दिशा में ले जाते हैं, तो समय की बर्बादी गंभीर हो सकती है। कुल मिलाकर कई मामलों में यह मददगार होता है, लेकिन 'साक्ष्य की जाँच' महत्वपूर्ण है, और वास्तव में कई बार खुद implementation करना ज़्यादा तेज़ होता है

• LLM की सीमाएँ साफ़ हैं। वे बहुत शक्तिशाली हैं, लेकिन इंसानों जैसी रचनात्मक छलाँग लगाना उनके लिए कठिन है। उदाहरण के लिए, "Android पर 1000 से कम port bind नहीं हो रहा, तो web server कैसे चलाएँ?" इस सवाल पर Claude और Gemini दोनों ने केवल ये तीन सामान्य समाधान दिए: 1) reverse proxy 2) rooting 3) port number बढ़ाना। मैं जिस असली समाधान की तलाश में था, वह HTTPS RR record था (संदर्भ)। दोनों इस spec को जानते तो हैं, लेकिन उसे इस स्थिति पर लागू नहीं कर पाए। जवाब तक पहुँचने के लिए मुझे खुद context जोड़ना पड़ा

  • सच कहूँ तो मुझे यह अजीब नहीं लगता कि LLM ने इसकी सिफ़ारिश नहीं की। किसी नए spec की सलाह देने की उम्मीद करना कठिन है, जिसे Chrome में भी औपचारिक समर्थन नहीं मिला है, और शायद मैं भी उतना आगे नहीं सोच पाता

  • मैंने भी यह जानकारी नोट कर ली। हाल में LLM के साथ सचमुच बातचीत करते हुए लगा कि अगर हम उन्हें इंसानों की तरह थोड़ा उदारता से लें, तो stress कम होता है। उदाहरण के लिए, जब मैं cursor से कोड लिखते समय कहता हूँ "यहाँ कुछ छूट गया", तो मुझे लगता है कि वही गलती मैं भी कर सकता था। 'book club' या 'movie club' पार्टनर की तरह LLM से दो फ़िल्मों पर चर्चा करवाई, तो उसने पात्रों की स्थिति ग़लत बताने जैसी errors भी कीं, लेकिन 100% accuracy ज़रूरी नहीं थी; अगर इंसानों की तरह थोड़ी उदारता रखी जाए, तो बातचीत कहीं अधिक लचीली हो जाती है। AI से बात करते समय भी सकारात्मक रवैया रखना अच्छा है

  • SRV record के बारे में सुना था, लेकिन लगा था कि उसका उपयोग बहुत कम होता है। HTTPS RR के बारे में पहली बार सुना। वास्तविक support की स्थिति भी SRV से बेहतर लगती है

  • यह LLM की क्लासिक समस्या है: 'जब तक आप खुद सही उत्तर न बता दें, तब तक वह उसे समाधान की सूची में शामिल नहीं करता'

  • अगर लक्ष्य और constraints को काफ़ी स्पष्ट रूप से बताया जाए, तो ChatGPT o3 यह समाधान सुझा देता है। हालाँकि वह सही तरह से यह भी बताता है कि यह केवल नए browsers में काम करेगा। उदाहरण

• ChatGPT Enterprise version का अक्सर उपयोग करते हुए मैंने समय के साथ कुछ बातें सीखीं। बहुत सारा कोड एक साथ डालने के बजाय, बहुत स्वतंत्र functions या छोटी classes के स्तर पर काम करना अधिक प्रभावी है। कोड generation या completion के मामले में, लगभग 10% चीज़ें अतिरिक्त निर्देश देकर सुधारी जा सकती हैं, लेकिन quality गिर जाती है, और लगभग 25% चीज़ों में चाहे जितना समझाओ quality नहीं बढ़ती। ऐसे में उन्हें नज़रअंदाज़ कर सीधे खुद हल करना बेहतर है। इसके उलट, नए लिखे कोड की review में यह काफ़ी उपयोगी हो सकता है। comments में आधे बेकार होते हैं, कुछ अस्पष्ट होते हैं, लेकिन कभी-कभी यह सच में महत्वपूर्ण bug या issue पकड़ लेता है। एक साथ कई pages डालने के बजाय, उन्हें तोड़कर देना बेहतर है। HLSL shader या SIMD जैसे niche क्षेत्रों में training data की कमी के कारण यह लगभग कुछ नहीं बता पाता। कुल मिलाकर यह code quality सुधारने में मदद करता है। जब कोड को छोटे-छोटे हिस्सों में बाँटकर verify किया जाता है, तो architecture function/class/module जैसी संरचनाओं में विभाजित होता है और समग्र गुणवत्ता बेहतर हो जाती है

  • मैंने code review के लिए AI इस्तेमाल करना शुरू किया है और यह सचमुच सुविधाजनक है। functions जैसे छोटे दायरे वाले हिस्सों में यह बहुत मदद करता है, और खासकर उबाऊ unit tests लिखने में उपयोगी है। पिछले एक साल में AI coding assistants की quality सच में बहुत बढ़ी है, इसलिए जिन लोगों ने बहुत पहले इसे आज़माकर निराशा पाई थी, उन्हें दोबारा कोशिश करनी चाहिए

• लंबे समय के software development में LLM को 'उन्नत boilerplate generator' की तरह इस्तेमाल करना सबसे आकर्षक लगता है। एकबारगी कामों में, जहाँ maintenance की चिंता नहीं करनी, यह पहले से ही अच्छा है; लेकिन लंबे development में भी ऐसा दोहराव वाला कोड, जिसे abstraction में बदलना कठिन हो, जैसे test code, उसमें यह बेहद उपयोगी है। शुरू में मुझे इससे आपत्ति थी, लेकिन अब मैं इससे बहुत संतुष्ट हूँ। उबाऊ और repetitive हिस्से अब 'prompt optimization' नाम के एक दिलचस्प नए खेल में बदल गए हैं, और productivity भी बहुत बढ़ गई है। prompt लिखना और code review करना, साधारण हाथ के काम की तुलना में कहीं तेज़ी से पूरा हो जाता है। इसकी वजह से अब सिर्फ़ वही दिलचस्प हिस्से बचे हैं जहाँ सच में दिमाग़ लगाना पड़ता है

• आखिरकार मुझे एहसास हुआ कि LLM सिर्फ़ coding ही नहीं, कई तरह के कामों में 'trendy diet' जैसी घटना है। हर कोई तेज़ और आसान समाधान चाहता है, लेकिन अंत में कोई शॉर्टकट नहीं होता। सुविधा हमेशा trade-off के साथ आती है, और देर-सबेर सबको इस वास्तविकता को स्वीकार करना पड़ता है