लगता है मुझे LLM बर्नआउट हो गया है

(alecscollon.com)

4 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें

काम और निजी प्रोजेक्ट्स में Claude Code, Codex, ChatGPT, Gemini का हर दिन इस्तेमाल करते हुए, कुछ साल पहले की तुलना में AI-जनित टेक्स्ट पढ़ने का समय काफी बढ़ गया है
डेवलपमेंट फ्लो सीधे खुद डिज़ाइन और इम्प्लीमेंट करने के तरीके से बदलकर डिज़ाइन समझाना → LLM code review → खुद संशोधन करना हो गया है, और अनजान क्षेत्रों में भी अब काम करना आसान लगने लगा है
मौजूदा प्रोजेक्ट भी बड़े पैमाने पर unsupervised code generation फ्रेमवर्क और Qwen agent के आउटपुट रिव्यू पर केंद्रित है, इसलिए LLM कंटेंट लगातार पढ़ना पड़ता है
लगभग 1 साल तक इस्तेमाल जारी रहने के बाद, पिछले कुछ महीनों में गलत मान्यताएँ, hallucination, छोटे लेकिन बहुत निश्चित वाक्य, और ज़रूरत से ज़्यादा emoji जैसे दोहराए जाने वाले पैटर्न बोझ की तरह जमा होने लगे हैं
समस्या LLM से ज़्यादा इस बात से है कि वही लेखन शैली और वही तरह की गलतियाँ बार-बार दोहराई जाती हैं; personalization फीचर होने पर भी दूसरे लोगों द्वारा बनाए गए AI कंटेंट की शैली को नियंत्रित करना मुश्किल है

डेवलपमेंट फ्लो में गहराई तक आ चुके LLM

लेखक को लगता है कि आज के डेवलपर मानकों के हिसाब से उनका LLM उपयोग औसत स्तर का है, और इस्तेमाल का तरीका भी अभी काफ़ी शुरुआती है
- एक समय में एक ही काम संभालते हैं; कंपनी में Claude Code का इस्तेमाल करते हैं और घर पर इस समय Codex से बातचीत करते हैं
- जब assistant से code लिखवाते हैं, तब भी आउटपुट को ध्यान से पढ़कर समझते हैं और फिर खुद बदलाव करते हैं
- autonomous agent या agent orchestration का बहुत गहरा इस्तेमाल अभी नहीं करते
काम करने का तरीका code design और लेखन-केंद्रित प्रक्रिया से बदलकर, डिज़ाइन को LLM को समझाना, LLM द्वारा बनाए गए code का review करना, और फिर दोबारा खुद code लिखना हो गया है
- इस प्रक्रिया में ऐसे approaches दिखाई देते हैं जिनके बारे में पहले सोचा नहीं था या जानकारी नहीं थी
- जिन क्षेत्रों में गहरी जानकारी नहीं है, वहाँ भी अब ज़्यादा सहजता से काम कर पाते हैं
मौजूदा मुख्य प्रोजेक्ट codebase के भीतर बड़े पैमाने पर unsupervised code generation के लिए framework बनाना है
- जब Claude से tools नहीं बनवा रहे होते, तब Qwen जैसे unsupervised agent के आउटपुट का review करते हैं
- दोनों ही स्थितियों में LLM द्वारा बनाया गया कंटेंट लगातार पढ़ना पड़ता है
जानकारी खोजते समय भी, अगर किसी खास साइट का पता नहीं होता, तो अक्सर ChatGPT से पूछ लेते हैं या Gemini का overview पढ़ते हैं
- अगर LLM का जवाब गलत निकलता है, तो फिर दोबारा browsing पर लौटना पड़ता है
- जब search results में बेकार AI-जनित लेख बहुत ज़्यादा हों, तब रोज़मर्रा के सवालों के लिए LLM के जवाब काफ़ी ठीक लगते हैं

एक जैसी शैली और एक जैसी गलतियों से जमा होती थकान

इस तरह का उपयोग लगभग 1 साल से जारी है, और इसे अभी रोकने का इरादा नहीं है
- लेखक को लगता है कि LLM इस्तेमाल करने से वे अधिक productive हैं
- LLM को प्रभावी ढंग से इस्तेमाल करना सीखते रहना भी वे मूल्यवान मानते हैं
पिछले कुछ महीनों में LLM आउटपुट पढ़ने का अनुभव बदल गया है
- पढ़ना शुरू करने से पहले ही यह अंदाज़ा हो जाने का एहसास कि किस तरह की शैली और कौन-सी गलतियाँ मिलने वाली हैं, अपने आप में बोझ बन गया है
- बार-बार दिखने वाले तत्व हैं गलत मान्यताएँ, hallucination, छोटे लेकिन बहुत निश्चित वाक्य, और ज़रूरत से ज़्यादा emoji
इनमें से हर असुविधा अलग-अलग देखी जाए तो झेली जा सकती है, लेकिन जब ये सब बार-बार साथ आते हैं, तो LLM लेखन से बहुत जल्दी ऊब होने लगती है
मुख्य बात यह नहीं है कि LLM इंसानों से बदतर हैं, बल्कि समस्या दोहराव की है
- इंसानों पर भी भरोसा करना मुश्किल हो सकता है या वे परेशान कर सकते हैं
- LLM एक ही शैली में लिखते हैं और एक ही तरह की गलतियाँ दोहराते हैं
- अगर interface अनुमति दे, तो personalization फीचर्स का इस्तेमाल किया जा सकता है, लेकिन कुछ खास तरह की शैली फिर भी बनी रहती है
- दूसरे लोगों द्वारा जनरेट किए गए कंटेंट की शैली पर सीधे नियंत्रण नहीं होता
अभी यह स्पष्ट नहीं है कि इस भावना से कैसे निपटा जाए; यह सिर्फ़ अस्थिर tools को लेकर होने वाली निराशा से आगे बढ़कर, लेखन के पैटर्न से लगातार चिढ़ बने रहने की स्थिति है

2 टिप्पणियां

amebahead 2 시간 전

मैं भी LLM के जवाबों में झूठी धारणाओं, hallucination, छोटे और निर्णायक वाक्यों, और जरूरत से ज्यादा emoji वाले पैटर्न से परेशान था,
फिर ELI5 Rule बनाया और लागू किया, जिससे इस परेशानी से छुटकारा मिल गया :)

https://github.com/amebahead/explain-like-iam-five-rules

GN⁺ 4 시간 전

Hacker News की रायें

burnout तक तो नहीं, लेकिन LLM जिस तरह का दबाव पैदा करते हैं उससे सच में थकान होती है। कोई मुझे काम की मात्रा बढ़ाने के लिए धक्का नहीं दे रहा, लेकिन हर पल मेरे “clanker” या किसी और के “clanker” ने कुछ न कुछ बना रखा होता है, और वह मेरी रुकावट खोल देने की स्थिति में होता है
LLM से पहले भी pace बनाए रखना मुश्किल था, लेकिन अब लगता है कि pending काम हमेशा करीब 10 गुना बढ़ गया है, और अगर सब लोग “optimize” करके AI को parallel में और तेज़ी से काम खिलाने लगें तो यह फिर 10 गुना हो सकता है। हर चीज़ की bottleneck बनकर लगातार खड़े रहना थका देने वाला है
छोटे side projects और ideas को साकार करना मज़ेदार है, लेकिन समझ आया कि LLM “आराम करोगे तो समय बर्बाद होगा” वाली unhealthy सोच को और fuel करता है, और लगा कि इसे ठीक करना होगा
लेख की मुख्य शिकायत factory automation के समय भी शायद ऐसी ही रही होगी। जैसे कुशल और विविध हस्तकला assembly line की एक जगह पर दिन भर वही हरकत दोहराने वाले काम में बदल गई, वैसे ही LLM ने creative और varied हिस्सा ले लिया और सिर्फ repetitive QA stamp लगाना छोड़ दिया। उस समय जो mitigation उपाय इस्तेमाल हुए थे, शायद उन्हें अब फिर से देख सकते हैं
- LLM से बने documents review करने के अनुरोध बहुत ज़्यादा आ रहे हैं। जैसे planning documents, end-user documents, project documents, business plan documents वगैरह
  कुछ समय पहले टीम के एक सदस्य ने करीब 30 LLM-generated documents वाला zip file भेजा और तुरंत review करने को कहा, लेकिन उनमें से काफी repetitive थे या बिना संदर्भ की fabricated/hallucinated सामग्री थी। generation की speed review की speed से कहीं ज़्यादा है
  पहले project manager को planning document बनाने में दिन का बड़ा हिस्सा लग जाता था, लेकिन अब वे कुछ मिनटों में बनाकर review के लिए फेंक सकते हैं, इसलिए सच में थकान होती है
- Charlie Chaplin की Modern Times वाली factory scene याद आती है। लेखक जो महसूस कर रहा है, वह आखिरकार इंसान को machine की speed के हिसाब से चलना पड़ना है, न कि उल्टा
  “reverse centaur” कोई नई चीज़ नहीं है। पिछली सदी के labor movement से पूछ लें
- LLM के थका देने की एक वजह यह है कि UI ठीक कराने के लिए हमेशा बस एक prompt और करना पड़ता है। आम तौर पर वह थोड़ा सा गलत होता है, और उसे फिर से ठीक कराने में कभी-कभी 5–10 मिनट लग जाते हैं। नतीजा यह कि बहुत ज़्यादा देर तक काम करना पड़ता है
  शायद इसलिए और भी, क्योंकि मैं ऐसा software engineer हूं जिसे complex software इस्तेमाल करने से ज़्यादा products बनाना पसंद है। कुछ बना पाने का एहसास ही motivation है, और feature को perfect और finished state में लाना चाहता हूं। लेकिन UI work में 95% से 100% तक जाना लंबा समय लेता है
  इसलिए अफसोस की बात है कि अभी मेरे काम के घंटे काफी बढ़ गए हैं
- एहसास कुछ ऐसा है: “सोचा था बर्तन धोने वाली machine आ जाएगी तो creation पर focus कर पाऊंगा, लेकिन असल में मेरे काम करने वाली machine आ गई, और मेरे हिस्से में सिर्फ बर्तन धोना रह गया”
- मैं एक अलग तरह का दबाव झेल रहा हूं। company अब भी सभी से LLM इस्तेमाल करने को कहती है, और token leaderboard, usage time measurement, performance evaluation में शामिल करना—सब कर रही है
  इसलिए productive काम रोककर समय का एक तय हिस्सा अलग निकालना पड़ता है ताकि “token usage दिखाने के लिए AI करना” पड़े। workload वही है या बढ़ा है, लेकिन AI gods को खुश करने में असली काम के लिए समय N% घट जाता है
मेरे अनुभव में burnout की वजहें मोटे तौर पर 3 हैं। पहली और सबसे बड़ी है multitasking। अलग-अलग काम कर रही 3–5 agent windows के बीच बार-बार जाना पड़ता है, और हर round में कुछ मिनट लगें तो यह बेहद थका देता है
coding agent era से पहले ज्यादातर developers को शायद एक चीज़ पर 2 घंटे से ज़्यादा focus करने का मौका मिल जाता था। अब coding agents ने संभाले जा सकने वाले tech stack की breadth तो बढ़ा दी है, लेकिन deep work की bandwidth नहीं बढ़ाई
दूसरा, agents चीज़ों को बिना conflict चलाने में अच्छे हैं, लेकिन सही code बनाएंगे इसकी गारंटी नहीं। यह foundational knowledge वाले human expert से काफी अलग है
तीसरा, AI-generated low-quality PRs के ढेर को review करते समय frustration होती है। concentration एक सीमित resource है। मैं दूसरों के काम पर बहुत ऊर्जा खर्च नहीं करना चाहता, लेकिन अगर और ध्यान न दूं तो human author की careful thinking और design के बिना बना irresponsible AI code पूरे project को तेजी से बिगाड़ देता है। जिन लोगों में सावधानी की कमी है उनके साथ काम करना भी कठिन है, लेकिन coding agent era में वे 10 गुना कचरा बनाते हैं, तो दर्द भी 10 गुना बढ़ जाता है, और यह team culture की समस्या है जिसे आसानी से enforce नहीं किया जा सकता
- सहमत हूं। साथ ही मैं खुद को strongly limit करने की कोशिश कर रहा हूं कि एक समय में सिर्फ 1–2 agent workflows इस्तेमाल करूं। उससे ज़्यादा संभलता नहीं, लेकिन “बस यह छोटा सा fix” करने के लिए agent चलाने के जाल में फंसना बहुत आसान है
Opus का आउटपुट घंटों तक पढ़ते-पढ़ते हल्का-सा शरीर खराब होने जैसा एहसास होने लगा। यह पोस्ट सच में बहुत relatable लगी
मैंने टीम में भी शिकायतें उठानी शुरू कर दी हैं; कम-से-कम agent rules में एक personal style guide डालनी चाहिए ताकि em dash, “X नहीं, Y है” जैसे expression, noun से पहले लंबी-लंबी modifiers की कतार लगाना, “land” को complete होने के अर्थ में इस्तेमाल करना आदि हटें। उम्मीद है यह बस अपरिपक्व LLM का एक चरण हो
- bots सब किसी खास phrase, शब्द और punctuation को जरूरत से ज्यादा इस्तेमाल करने का pattern दिखाते हैं। जैसे इन दिनों gate शब्द का बहुत ज्यादा इस्तेमाल हो रहा है
  इंसान के तौर पर हमें पता है कि gate एक “दरवाजा” है जो खुल या बंद हो सकता है, locked या unlocked हो सकता है, और उसके पार का रास्ता पार किया जा सकता है या नहीं भी। सिर्फ gate के मौजूद होने से यह नहीं पता चलता कि वह खुला है या बंद
  लेकिन bot-style expression में gate का मतलब केवल एक मजबूत, न पार की जा सकने वाली रुकावट होता है। इसे fence या wall, यहां तक कि lava moat जैसी चीज की तरह इस्तेमाल करते हैं
  मगर gate तो मूल रूप से गुजरने के लिए design की गई चीज है, जबकि bot उन obstacles के लिए भी यही शब्द इस्तेमाल करता है जिन्हें पार न किया जा सके, ऐसा बनाया गया हो। असल दुनिया में दशकों तक gates से पाला पड़ने के अनुभव के हिसाब से यह misuse है। आम तौर पर बंद gate मिले तो उसे खोलकर निकल जाते हैं
  bot को उस शब्द के इस्तेमाल से बचने को कहो, तब भी कभी-कभी ignore कर देता है। आज दिमाग में आया problematic शब्द सिर्फ gate है; कल कोई और शब्द था, और कल फिर बिल्कुल कोई अलग शब्द होगा
  पूरा pattern शुरुआत से ही गलत दोहरावदार और चुभने वाला घटिया jargon है
- मेरे साथ भी ऐसा है। ऐसी चीजें बहुत ज्यादा पढ़ो तो लगता है मानसिक नुकसान हो रहा है
  “यह तो बस contract workers की Nigerian English है” वाली व्याख्या के उलट, लगता है models reinforcement learning pressure के तहत अपनी एक ultra-concise और जरूरत से ज्यादा stylized बोली बना रहे हैं। यह धीरे-धीरे code में लिखने जैसा लगने लगा है, लेकिन यहां code से मतलब computer code नहीं है। शब्दों का अर्थ इंसानों के लिए जो होता है, उससे बिल्कुल वही नहीं है
- आज ही मैं इसी एहसास को समझा रहा था। अभी ठीक-ठीक शब्दों में नहीं कह पाया, लेकिन सच में हल्का-सा शरीर खराब होने जैसा लगता है। यह हल्के trypophobia जैसा लगता है
- arc land Phabricator की वजह से दिमाग में छप गया है, इसलिए मुझे पता है कि यह term LLM से पहले से था, फिर भी यह पागल कर देने जितना खटकता है
  इस तरह की linguistic drift को पलटा नहीं जा सकता। भले ही LLM input को 100% filter किया जा सके, लोग खुद “land” ज्यादा बोलने के लिए train हो रहे हैं
- writing में voice सच में बहुत मायने रखती है। अगर हर कोई Opus से लिखे और edit न करे, तो किसने लिखा है इससे फर्क नहीं पड़ता, सब कुछ एक जैसा सुनाई देता है
अभी मैं एक ऐसे व्यक्ति के साथ project कर रहा हूं जो सिर्फ LLM इस्तेमाल करता है, और यह थकाने वाला और mentally draining है
किसी चीज पर feedback दो तो जवाब बस “Claude से पूछता हूं” होता है। वह व्यक्ति समझता ही नहीं कि पूरी चीज कैसे काम करती है, और code का बड़ा हिस्सा भी यही दिखाता है
कुछ दिन पहले उसे local environment set करना और environment variables configure करना भी नहीं आता था, इसलिए उसने demo mode hardcode कर दिया। Claude को वह क्यों नहीं पता था, यह भी उलझन भरा है, पर शायद prompt की problem हो सकती है
मैं LLM usage को सीमित रखने की कोशिश करता हूं, और इस्तेमाल भी करूं तो सिर्फ बेहद specific tasks के लिए। मेरे लिए वही तरीका काम करता है
सच कहूं तो समझ नहीं आता companies AI code generation को इस तरह कैसे push कर सकती हैं। छोटे project में भी project की understanding जल्दी पीछे छूट जाती है
- AI से पहले भी मुझे ऐसे लोगों के साथ काम करने की याद है। चिढ़ होती थी, लेकिन वे जिस चीज पर काम कर रहे थे उसे पर्याप्त समझते नहीं थे, इसलिए अच्छा code efficiently नहीं बना पाते थे, productivity में struggle करते थे, और आम तौर पर problem अपने-आप साफ हो जाती थी
  अब LLM coding जिज्ञासा न रखने वाले व्यक्ति को बढ़ावा देती है और गहराई से सोचने वाले को सजा देती है, इसलिए ऐसे लोग टिक पाते हैं
- मैं भी इसी तरह हूं। सिर्फ बहुत specific tasks के लिए इस्तेमाल करता हूं। अभी-अभी meaning में काफी बदलाव लाने वाली code की 5-line modification करने के लिए Claude Code से 2 घंटे बात की
  दूसरी तरफ मेरा दोस्त कुछ बनाने के लिए agent tokens पर रोज 10,000 डॉलर खर्च कर रहा है। वह बहुत smart है और former developer है, इसलिए यह कोई simple AI psychosis जैसी बात नहीं है
  अभी भी समझने की कोशिश कर रहा हूं। बेशक मेरे पास 10,000 डॉलर नहीं हैं
- LLM-generated code बेवजह कठिन और घना होता है
सच में बहुत थकान है। LLM के साथ काम शुरू करने के बाद एक solo developer के तौर पर मेरा output आसानी से 20 गुना बढ़ गया है। ऐसे customer projects भी खत्म कर रहा हूँ जो पहले अकेले लेने के लिए बहुत ambitious लगते
पुराने codebase में वे features जुड़ रहे हैं जो महीनों तक अटके रहते थे या उससे भी लंबे समय तक planning stage में पड़े रहते थे। कुल quality भी बहुत ऊपर गई है, test coverage भी ज्यादा complete और सच कहूँ तो बेहतर हो गई है
Personal projects भी जबरदस्त speed से बना रहा हूँ। Roles जैसे उलट गए हैं: agent को ऐसे treat करता हूँ जैसे मैं customer हूँ, और agent ऐसे काम करता है जैसे वह मैं हो। बेशक मैं ज्यादा technical customer की तरह architecture direction देता हूँ। Agent ने जो apps और tools बनाए हैं, उन्हें रोज इस्तेमाल कर रहा हूँ, और अपने बनाए tools की वजह से SaaS subscriptions भी cancel कर दिए हैं
Tool calls देखते हुए लगा कि core command-line tools को और अच्छे से जानना चाहिए, इसलिए रोज थोड़ा-थोड़ा catch up करने का learning plan भी बनाया। vim और tmux पहली बार इस्तेमाल करते समय बिना कुछ जाने डाल दी गई पुरानी settings भी फिर से देख रहा हूँ
Theory में productivity को पुराने level पर रखकर ज्यादा किताबें पढ़ सकता हूँ, लेकिन यह संभव नहीं लगता। “काम कम होगा” वाले वादे के उलट, हकीकत में ऐसा लगता है कि हम productivity और expectations बढ़ने वाले एक बहुत बड़े transition में हैं, और Industrial Revolution एक ठीक analogy लगती है
Expectations का बढ़ना छोटे और बड़े दोनों तरीकों से हो रहा है। Agent data presentation को इतना अच्छी तरह polish कर देता है कि जो साफ-सुथरी और visually impactful reports पहले काफी समय लेतीं, उन्हें अब सहज रूप से भेज देता हूँ
लेकिन थकान है। Fable की subscription वाली window API-only में बदलने से पहले जितना हो सके उतना काम निपटाने के लिए full sprint में हूँ। लोग इतने tokens कैसे इस्तेमाल कर लेते हैं, यह भी समझ नहीं आता। लगभग सोता भी नहीं और जितना हो सके उतना code Fable में चलाता हूँ, फिर भी 20x max plan की limit के करीब भी नहीं पहुँचता
खुद से कहता आया था कि नीचे आते ही speed कम कर दूँगा, लेकिन अब यह 12 तारीख तक बढ़ गया है और window भी reset हो गई है, इसलिए backlog साफ करने के लिए कुछ दिन और मिल गए। लगता है robots को पूरी रात busy चलाना चाहिए ताकि सुबह उठते ही review कर सकूँ। Phone से agent को instructions देना भी खुद को अजीब लगता है
- Industrial Revolution ने बड़े पैमाने पर जीवन बेहतर बनाया, लेकिन घर पर हाथ से काम करने वाले vertical weavers के लिए नहीं, जिन्हें factory में जाकर ज्यादा output देते हुए पूरे दिन कड़ी मेहनत करनी पड़ी
  बाहर से देखें तो यह मेरे पिता जैसा लगता है, जो mill में mechanic के तौर पर काम करते थे। उनका काम ज्यादातर मशीनों को काम करते देखना और खराब होने पर उन्हें ठीक करना था, और 90% समय सब ठीक चलता था
  हाथ से काम करने से मशीनों को देखते रहने में बदलना सचमुच boring लग सकता है, और उस नजरिये से यहाँ AI के खिलाफ नाराजगी समझ आती है
- मेरा एक दोस्त है जो खुद को LLM addict कहता है, और उसने लगभग यही सारी बातें कही हैं। जो सवाल पूछना चाहता हूँ लेकिन सीधे पूछ नहीं पाया, वह यह है: अगर इतना burnout हो रहा है, तो इतनी सारी personal projects लगातार निकालते रहने की जरूरत क्यों महसूस होती है?
  काम में AI-generated code की ढेर सारी review करना थकाऊ है, इस पर हम सब सहमत हो सकते हैं, लेकिन जिज्ञासा है कि उस unpleasant situation को पूरे दिन तक क्यों फैलाते हैं
- यह classic addiction signal है
- अगर विकल्प यही है तो अजीब है। ऐसी productivity की हर बूंद निचोड़ना जिसके अस्तित्व का पहले पता भी नहीं था, शायद उतने ही पैसे में ज्यादा जल्दी burnout होना, और coding की खुशी के बिना एक बेवकूफ मशीन से बहस करनी पड़ना जो न थकती है न frustrate होती है। ऊपर से वह मशीन हमेशा target से थोड़ा कम रह जाती है
  या फिर बस हाथ से coding करो, चीजें complex हों तो whiteboard के सामने सोचो, और पिछले 50+ सालों से software engineering जैसे करती आई है वैसे ज्यादा मानवीय pace पर धीरे-धीरे burnout हो जाओ
  समझ नहीं आता कि यह विकल्प क्यों है। Seriously पूछूँ तो, क्या थोड़ी self-respect है? अंदाजा है कि “लेकिन boss AI इस्तेमाल करने की उम्मीद करता है” वाला excuse आएगा। ज्यादातर लोगों ने शायद असली burnout झेला ही नहीं है। जब आएगा तो जबरदस्त दर्द देगा। खुद को मशीन मत बनाओ। इंसान मशीन नहीं होते
Burnout नहीं है, लेकिन लेखक जैसा ही काम कर रहा हूँ। LLM-generated code को review करने का ऐसा workflow अब तक नहीं बना पाया जो खुद लिखने से तेज हो
इस dilemma से निकलने के असल में केवल दो रास्ते हैं। Generated चीजों पर आँख बंद करके भरोसा करो, या हर possible scenario verify करने के लिए असामान्य रूप से बड़ा unit tests का bundle बनाओ
इसलिए business logic खुद लिखता हूँ, और बाकी बहुत-सी चीजें LLM पर छोड़ देता हूँ। Boilerplate भी दूसरे category में आता है
- ठीक वही चाहना चाहिए। हर level पर ऐसे tests चाहिए जो इंसानों के बनाने या maintain करने के हिसाब से अव्यावहारिक रूप से कहीं ज्यादा comprehensive हों। Unit, functional, पूरे end-to-end tests और उससे आगे तक शामिल हैं
  Adversarial testing AI को track पर रखने और पढ़ने वाले changes को साफ और आसान बनाने का सबसे अच्छा तरीका है। TDD style में “इस bug को दिखाने वाला test लिखो” हो या बाद में “नए test से साबित करो कि यह patch गलत है”, दोनों शामिल हैं
  बेहतर तरीका है ज्यादा strong typed language इस्तेमाल करके चीजों को कसकर lock करना, लेकिन tests किसी भी language में लिखे जा सकते हैं। TDD और “सारे tests लिखो” वाली background AI के साथ काम करते समय secret sauce जैसी लगती है
- Code को बस सावधानी से पढ़ रहा हूँ। Speed बढ़ाने के लिए output को जैसे का तैसा accept करने की तरफ फिसलना आसान है, लेकिन code reading important है
  Tests, templates, कुछ UI, सजावटी elements जैसी चीजों को skim करके समय बचाता हूँ। लेकिन backend systems में जाने वाला ज्यादातर code पढ़ना ही पड़ता है
- अगर code को खुद लिखने से ज्यादा तेज review नहीं कर सकते, तो खुद लिखना ही सही है
- ऐसे feelings रखने वालों को लग सकता है कि उनमें कोई mental defect है, इसलिए वे मीठा Kool-Aid पीकर बस generated garbage इस्तेमाल नहीं कर पाते। जैसे वह twisted trait क्या है जो उन्हें सबकी मौज खराब करने वाला जिद्दी बना देता है
  निजी तौर पर, LLM magic को लेकर सबसे ज्यादा excited वे लोग हैं जिन्हें code लिखना नहीं आता था। क्योंकि अब वे best code न सही, लेकिन चलने वाली कोई चीज लेकर आ सकते हैं। उन्हें लगता है कि working code बना पाने से वे सबको बेहतर बना देंगे, लेकिन उन्हें यह भी पता नहीं होता कि वह garbage maintainable है या पहले से ही garbage है
मुझे LLM burnout इसलिए महसूस हो रहा है क्योंकि मुझे top models के साफ़ तौर पर कमज़ोर किए जाने और अपारदर्शी तरीके से downgrade किए जाने से जूझना पड़ रहा है
पिछले 12 महीनों तक AI कंपनियाँ औसत models से भी सबसे अच्छे नतीजे निचोड़ने में लगी हुई थीं
लेकिन जैसे-जैसे top models आगे बढ़े, वही कंपनियाँ अब computation, यानी एक result बनाने की लागत, को जितना हो सके घटाने की कोशिश में लग गई हैं—बस इतना कि बहुत ज़्यादा साफ़ न दिखे
पिछले 36 महीनों में result quality की ढलान exponential तरीके से ऊपर गई थी, लेकिन अब लगभग flat हो गई है
मेरी राय में results के रुक जाने की वजह यह नहीं है कि model एक साल पहले की तुलना में बहुत कम सक्षम है. वजह यह है कि अत्यधिक भीड़ वाले user base की भारी processing cost बचाना, user के स्पष्ट निर्देशों का पालन करने और best result देने के लक्ष्य से ऊपर रखा जा रहा है. खासकर तब, जब उन निर्देशों का पालन करने में processing cost ज़्यादा आती हो
- आजकल consumer AI tools को लेकर मुझे भी बिल्कुल यही लगता है. Gemini और ChatGPT हाल में बहुत खराब रहे हैं. अब कई turns तक चलने वाली search और reasoning उन पर भरोसे से नहीं छोड़ी जा सकती
  पहले वे 7 मिनट से ज़्यादा thinking mode में रह सकते थे. जैसे, “इस दावे का source ढूँढ दो” कहने पर वे search करते, analysis करते और queries को खुद adjust करते थे. आजकल “Pro” mode में भी कितना भी push करो, उन्हें 30 सेकंड से ज़्यादा काम नहीं कराया जा सकता, और वे बस generic जवाब दे देते हैं
- क्या सच में ऐसा है? हो सकता है शुरुआती “वाह, कमाल है” वाला phase गुजर गया हो और expectations reality से टकरा गई हों
- यह तो हद से ज़्यादा मज़ेदार तरह का extreme इतिहास संशोधन लगता है
  Opus 4.5 moment भी पिछले नवंबर में था, और उसी समय agentic coding और ज़्यादातर coding CLI tools सच में first-class विकल्प बन गए थे. यह बहुत बड़ा paradigm shift है. GPT-5 भी तब तक आया नहीं था, और ज़्यादातर लोग 4o इस्तेमाल कर रहे थे. आज जो चीज़ें उपलब्ध हैं, वे coding में 4o से कहीं बेहतर हैं
- मैं सहमत नहीं हूँ. हो सकता है मेरी expectations बढ़ गई हों, लेकिन 1 साल पहले agents से जो बनाता था और आज जो बनाता हूँ, उनकी तुलना करूँ तो यह पूरी तरह अलग दुनिया है
ऐसा लगता है जैसे मैं ऐसे सहकर्मियों के साथ फँसकर काम कर रहा हूँ जो खुलकर hostile तो नहीं हैं, लेकिन रोज़ वही गलतियाँ दोहराते हैं, लगातार हाथ पकड़कर मदद करनी पड़ती है, और सच में माफ़ी भी नहीं महसूस कर सकते
सिर्फ़ इसलिए कि हम computers के साथ काम करते हैं, इसका मतलब यह नहीं कि हमें social harm नहीं होता. इस मामले में शायद यह parasocial harm के ज़्यादा करीब है
सच में यही वजह है कि मैं programming छोड़ने के बारे में सोच रहा हूँ
मैंने programming इसलिए शुरू की थी क्योंकि programming problems दिलचस्प लगती थीं. लेकिन अगर समस्या “France में calculator 1 से अलग क्यों है यह पता लगाना” से बदलकर “इस LLM को cute emojis की बौछार करने से रोकना” हो जाए, तो शायद career बदलने का समय आ गया है
- दूसरी तरफ़ की बात भी कहूँ तो, काम पर ज़्यादा output देने का pressure असली है, लेकिन काम के बाहर यह सच में बहुत अच्छा है. personal projects शुरू करते समय research और time हमेशा barrier होते थे, वे कम हो गए हैं, इसलिए मैं पहले से कहीं ज़्यादा projects कर पा रहा हूँ
  हाल में मुझे sparkling water का शौक लगा है, इसलिए मैं खुद continuous carbonator बना रहा हूँ. water source से tap तक ESP32 से control होने वाले pumps, pressure, water level, cooling fans—पूरा build शामिल है
  इसने shopping cart में मेरी कई गलतियाँ पकड़ीं. जैसे homebrew side में 8mm line पसंद की जाती है, लेकिन water filtration systems 9.5mm इस्तेमाल करते हैं. मैंने एक simple on/off pump और float switch से लेकर लगभग full PLC system जैसी version तक optimize किया. “ज़्यादा अनुभवी व्यक्ति” से बात करने जैसा करके कई iterations मिले. parts आते ही मैं इसे एक घंटे के अंदर assemble करके software भी चला सकता हूँ
  इससे पैसा नहीं बनता, लेकिन मज़ा बहुत आता है
- मैंने तो बस कुछ बनाने के लिए programming शुरू की थी. coding सिर्फ़ लक्ष्य तक पहुँचने का साधन है. “कैसे” पर बहुत अटकने के बजाय क्यों और क्या बनाना है इस पर ज़्यादा सोचना बेहतर है
- अगर आप LLM इस्तेमाल करने वाला product बना रहे हैं, तो annoying हिस्सा यह है कि किसी point पर problem ठीक करने के लिए आपके पास खींचने लायक levers खत्म हो जाते हैं
  unwanted output रोकने के लिए hack पर hack चढ़ाना ही best होता है, लेकिन आखिर में अगर LLM तय कर ले कि वह निर्देश follow नहीं करना चाहता, तो *IMPORTANT* जोड़ने और अगले model से उम्मीद करने के अलावा ज़्यादा कुछ नहीं कर सकते
  यह experience एक ऐसे external API के साथ काम करने जैसा कहीं ज़्यादा है जिसे आप control नहीं कर सकते और जो documentation के मुताबिक behave भी नहीं करता. ऐसी चीज़ें पहले भी programming के सबसे frustrating हिस्सों में थीं, लेकिन कम से कम पहले actual implementation को reverse-engineer करके bug के आसपास रास्ता निकाला जा सकता था. अब वह “boundary” रोज़ randomly बदलती है, इसलिए वह भी असंभव है
- सच कहूँ तो कड़वाहट होती है कि वे लोग, जो कहते थे “मुझे इस बात में दिलचस्पी नहीं कि France में calculator क्यों नहीं चल रहा, पैसे मिलते हैं इसलिए ठीक कर रहा हूँ”, अब technical progress से सही साबित होते लगते हैं
- accounting तो legal और compliance की वजह से ज़रूरी है, इसलिए accountants की सख्त जरूरत है. आज ही join कर सकते हो
CLAUDE.md या AGENTS.md में एक simple style guide डालने, या बस “emoji forbidden” लिखने में 5 सेकंड लगते हैं, और इससे LLM output कहीं ज़्यादा tolerable हो जाता है. banned words और phrases वाली simple style guide भी मदद करती है
बेशक गलत assumptions इससे solve नहीं होते. उन्हें पुराने तरीके से ध्यान से पढ़कर और critical thinking से ही पकड़ना होगा
- बिल्कुल सही! क्या मैं वे markdown files तुम्हारी तरफ़ से लिख दूँ?
- संदर्भ के लिए, जब मैंने ChatGPT को pair programmer की तरह treat करते हुए design ideas पर चर्चा की, implementation code माँगा, और refactoring suggest करने को कहा, तो उसने emojis बिल्कुल नहीं इस्तेमाल किए
  लेकिन जब data analysis या modeling के लिए कहो, तो emojis हर तरफ़ निकल आते हैं
  पिछले लगभग 1 साल में GitHub पर जो देखा है उसे देखते हुए, मैं LLM को project README या documentation बिना supervision के लिखने देने का विचार कभी नहीं करूँगा