लूप के भीतर का इंसान थक चुका है

• LLM प्रोग्रामिंग उत्पादकता बढ़ाती है, लेकिन साथ ही डेवलपर को इरादे और गुणवत्ता पर लगातार नियंत्रण रखना पड़ता है, जिससे निगरानी थकान बढ़ती है और संतुष्टि व टिकाऊपन दोनों डगमगाते हैं
• मॉडल जल्दी से भरोसेमंद दिखने वाला कोड बना लेते हैं, लेकिन जटिल बदलावों के पीछे के सुसंगत इरादे को चूक सकते हैं, इसलिए इंसान बढ़े हुए आउटपुट की समीक्षा और सुधार करने वाला quality gate बन जाता है
• शुरू किए जा सकने वाले काम तेज़ी से बढ़ते हैं, लेकिन उन्हें सावधानी से पूरा करने की क्षमता अभी भी मानव मस्तिष्क और ध्यान से बंधी है; coding के छोटे-छोटे rewards घटते हैं और review का cognitive load बढ़ता है
• जिन क्षेत्रों की गहरी समझ हो, वहाँ LLM को प्रभावी ढंग से निर्देशित किया जा सकता है; लेकिन जहाँ विशेषज्ञता सतही हो, वहाँ सटीकता से ज़्यादा भरोसेमंद दिखने पर ज़ोर होता है, इसलिए taste और architecture judgment और अधिक महत्वपूर्ण हो जाते हैं
• software engineering गायब होने के बजाय सिकुड़ और पुनर्गठित हो सकती है; असली scarce resource कोड लिखना नहीं, बल्कि मानव ध्यान, engineering judgment, और system की सुसंगत vision बनाए रखने की क्षमता है

---

उपयोगी लेकिन अस्थिर LLM प्रोग्रामिंग

• LLM प्रोग्रामिंग वास्तव में उपयोगी होने के साथ-साथ अस्थिर भी है, और अगर इस अस्थिरता को नज़रअंदाज़ किया जाए तो डेवलपर burnout का शिकार हो सकता है
• Pydantic टीम भी data validation, AI agent बनाना, और production observability tools तैयार करते समय इसी तरह की उलझन झेल रही है
• असली सवाल यह नहीं है कि AI प्रोग्रामर की जगह लेगा या नहीं, बल्कि यह है कि मौजूदा development experience कैसे बदल गया है और इसे किस तरह बेहतर बनाया जा सकता है

हाथ से सीधे बनाने का एहसास

• प्रोग्रामिंग लंबे समय से सिर्फ़ logic के सहारे कुछ बनाने और abstraction की गहरी परतों को सीधे संभालने का रचनात्मक एहसास देती रही है
• औपचारिक computer science शिक्षा के बजाय trial and error से software engineering सीखने के अनुभव में architecture और code quality के सिद्धांत textbook rules से ज़्यादा, समय के साथ जमा हुए घावों जैसे लगते हैं
• 2010 के दशक के low-code·no-code tools और Dreamweaver जैसे products ने भी बिना कोड के कुछ बनाने का वादा किया था, लेकिन अंदर spaghetti code बनाकर वे उम्मीदों पर पूरी तरह खरे नहीं उतरे
• मौजूदा AI tools अतीत से अलग, वादे और वास्तविकता के बीच की दूरी को एक मायने रखने वाले स्तर तक कम कर चुके हैं, और यही बात उन्हें और अस्थिर महसूस कराती है

“कोड खुद लिखता है” का वास्तविक अनुभव

• कोड कुछ हद तक खुद लिख जाता है, लेकिन उसे review करने, निर्देश देने और दिशा सुधारने वाले इंसान का अनुभव उल्टा और खराब हो सकता है
• Pydantic AI के maintainer Douwe हर सुबह दूसरों की AI द्वारा रात भर में बनाए गए लगभग 30 PRs की समीक्षा करते थे और हर एक पर तुरंत फैसला करना पड़ता था
  • review भी AI से करवाने का प्रलोभन बहुत बड़ा है, लेकिन तब सवाल बचता है कि इंसान आखिर कर क्या रहा है
• भले ही LLM के लिए execution plan लगभग दो दिन तक लिखकर और बार-बार स्पष्ट किया जाए, मॉडल React hook को Storybook story file में ले जा सकता है या गलत plan पढ़कर ऐसा component बना सकता है जो मौजूद ही नहीं है
• ऐसी विफलताएँ सिर्फ़ क्षमता की कमी से ज़्यादा सुसंगतता की कमी जैसी लगती हैं
  • मॉडल इतना स्मार्ट होता है कि भरोसेमंद दिखने वाला कोड बना दे, लेकिन पूरे जटिल बदलाव में एक ही इरादे को कायम नहीं रख पाता
• इंसान को अपने दिमाग में इरादा सँभाले रखते हुए बड़ी मात्रा में ‘ज़्यादातर सही’ आउटपुट पर लगातार निर्णय लेना पड़ता है, और इसी प्रक्रिया में निगरानी थकान का एक नया रूप पैदा होता है
• open source में असली लोगों के साथ features बनाना और दूसरे की क्षमता बढ़ाने में मदद करने वाला reward भी कम हो जाता है
  • जब काम AI के black box में चला जाता है, तो दूसरी तरफ़ सीखने वाला कोई नहीं बचता, इसलिए सहयोग की संतुष्टि गायब हो जाती है

काम की तीव्रता बढ़ाने वाला जाल

• Simon Willison द्वारा साझा किया गया Berkeley Haas research कहता है कि AI का उपयोग workload घटाने के बजाय काम की तीव्रता बढ़ाता है
  • दिन के अंत में बस एक और prompt डालने या एक और feature पूरा करने का दबाव बना रहता है
  • plan लगभग पूरा हो गया है, इस एहसास की वजह से रात 2 बजे तक prompt लिखते रहने जैसी स्थिति भी बन सकती है
• Pydantic के Marcelo मज़ाक में कहते हैं कि अगर Claude Code session रुक जाए तो 5 session खोल लो
  • मतलब यह कि अगर आप दूसरे sessions को feedback देने में व्यस्त हैं, तो एक session रुक गया यह बात भी शायद पता न चले
• parallel काम से शुरू किए जा सकने वाले कार्य बहुत बढ़ जाते हैं, लेकिन उन्हें सोच-समझकर पूरा कर पाने वाले कामों की संख्या नहीं बदलती
  • completion के लिए मानव मस्तिष्क जैसा ऐसा resource चाहिए जिसे parallel नहीं किया जा सकता

मानव reward function की खराबी

• जैसे machine learning में reward function agent के लिए अच्छे नतीजों को परिभाषित करता है, वैसे ही manual coding में भी problem solving, complex logic को समझना, compile का सफल होना, और control का एहसास जैसे छोटे rewards हुआ करते थे
• LLM-सहायित प्रोग्रामिंग उन कामों को automate कर देती है जो पहले dopamine reward देते थे, और उनकी जगह review व supervision का cognitive load ले लेता है
  • संतोष देने वाले हिस्से कम हो जाते हैं
  • थका देने वाले हिस्से बढ़ जाते हैं
  • और इस खाली जगह को भरने वाला नया reward अभी तक नहीं है
• उत्पादकता बढ़ने के साथ संतुष्टि का गिरना किसी व्यक्ति की कमी नहीं, बल्कि feedback loop की खराबी है, और इसे अलग engineering problem की तरह देखना चाहिए

एकाकीपन और variable rewards

• LLM प्रोग्रामिंग इंसान और मशीन के बीच prompt, correction और review के दोहराव वाली एक बेहद अकेली गतिविधि बन सकती है
• teammate से सवाल पूछना, साथ में समस्या पर बात करके उसे सुलझाना, और समाधान की छोटी खुशी साझा करना—इन सबकी जगह एक और prompt ले लेता है
• जिन टीमों में पहले से collaboration culture कमज़ोर है, वहाँ लोगों के बीच communication और भी सिमट सकता है, और यह समझना मुश्किल हो जाता है कि दूसरे लोग भी संघर्ष कर रहे हैं
• कभी नतीजा शानदार होता है, कभी कचरा, और पहले से पता नहीं चलता—यह Skinner Box जैसी variable reward structure बनाता है
• ज़रूरत पड़े तो आप खुद भी कोड लिख सकते हैं, लेकिन LLM-assisted workflow और manual coding की सोच बहुत अलग होती है, इसलिए इनके बीच switching असहज लगती है
  • दोनों तरीकों के बीच आने-जाने की खुद को अनुमति देने के लिए परिपक्वता और आत्मविश्वास चाहिए

responsive design transition से समानता

• लगभग 2009 के आसपास जब web fixed-width pixel-based layout से fluid responsive design की ओर गया, तब designers ने भी control खोने का अनुभव किया था
• जिन लोगों ने precise layout और perfect grid पर अपनी पहचान और विशेषज्ञता बनाई थी, उनके लिए arbitrary screen widths और devices के हिसाब से design का बहना एक बुनियादी बदलाव था
• इस transition के साथ ढलने वाले designers ने अपनी पुरानी skills को फेंका नहीं, बल्कि फिर से व्यवस्थित किया
  • proportions की समझ और hierarchy की समझ महत्वपूर्ण बनी रही
  • pixel-level control के प्रति जुनून कम महत्वपूर्ण हो गया
  • systems, adaptability, और uncertainty के लिए design करना ज़्यादा महत्वपूर्ण हो गया
• मौजूदा AI transition responsive design से कहीं तेज़ है और stakes भी अलग हैं
  • responsive design का बदलाव कई सालों में हुआ था, लेकिन मौजूदा बदलाव कुछ महीनों के पैमाने पर हो रहा है
  • तब भी agencies ग्राहक खो रही थीं और designers काम, लेकिन इसके साथ आज जैसी अस्तित्वगत बेचैनी नहीं जुड़ी थी
• फिर भी यह पैटर्न कि तकनीक गायब होने के बजाय विकसित होती है और core skills और महत्वपूर्ण बनते हैं, LLM-आधारित coding पर भी लागू होता है
• हर कोड खुद न लिखने का मतलब यह नहीं कि engineer की value घट जाती है, लेकिन जब वह बहुत अधिक output का quality gate बन जाता है, तो अच्छे नतीजों को पहचानने की क्षमता और ज़रूरी हो जाती है

टिकने वाली विशेषज्ञता और काम के नए तरीके

• ऐसी दुनिया में जहाँ कोई भी भरोसेमंद दिखने वाला UI और compile होने वाला कोड बना सकता है, वहाँ taste और nuance, परिपक्व architecture judgment, और वास्तविक विशेषज्ञता पर आधारित mainstream से हटकर लिए गए फैसले ही फर्क पैदा करते हैं
• जिन domains में कोड, decisions, और trade-offs की गहरी समझ होती है, वहाँ LLM को सफलतापूर्वक guide किया जा सकता है
• जैसे-जैसे आप उथली विशेषज्ञता वाले क्षेत्रों में जाते हैं, output production-ready स्तर से दूर होता जाता है और वास्तव में सही होने से ज़्यादा प्रभावशाली दिखने के करीब होता है
  • मॉडल को यह पता नहीं होता कि वह क्या नहीं जानता, फिर भी वह gaps को आत्मविश्वास से भर देता है; यह वही failure mode है जो इंसानों में भी दिखता है
• जटिल plans के लिए pre-mortem का उपयोग किया जा सकता है
  • एक नए LLM session से यह मानने को कहें कि plan बुरी तरह विफल हो गया, फिर उससे कारणों का diagnosis करने को कहें
  • इससे उस spec की खामियाँ ढूँढने में मदद मिलती है, जिन्हें दो दिन तक details में उलझा व्यक्ति भी चूक सकता है
• Pydantic के एक engineer ने पुराने code review comments के हज़ारों उदाहरणों से rules निकालकर AGENTS.md file के शुरुआती निर्देश बनाने वाला tool विकसित किया
  • यह कई वर्षों में चुपचाप जमा हुए engineering judgment को ऐसे निर्देशों में बदलना है जिनका LLM पालन कर सके—यानी विशेषज्ञता का आसवन
• जो लोग इस बदलाव के साथ ढलते हैं, उनके पास वास्तविक काम से निकले मजबूत judgment standards होते हैं, और वे अब भी वैध सिद्धांतों व केवल पुराने bandwidth constraints से पैदा हुई आदतों के बीच फर्क कर पाते हैं
• वे अपने standards छोड़े बिना workflow बदलने की इच्छा रखते हैं

लूप के भीतर उजागर हुआ दुर्लभ संसाधन

• AI की मौजूदा लहर software engineering profession को खत्म नहीं करेगी, लेकिन यह उद्योग में गंभीर संकुचन और बुनियादी पुनर्गठन ला सकती है
• बाहर हो जाने, skills के क्षरण, और पर्याप्त तेज़ी से न चलने पर पीछे छूट जाने का डर जायज़ है
  • आख़िरी चिंता कभी-कभी बढ़ा-चढ़ाकर कही जाती है, लेकिन पूरी तरह बेबुनियाद नहीं है
• असली bottleneck कोड नहीं, बल्कि मानव ध्यान, engineering judgment, और system के बारे में सुसंगत vision बनाए रखने की क्षमता थी
• पहले कोड लिखना ही कठिन हिस्सा लगता था, इसलिए यह bottleneck साफ़ नहीं दिखता था; लेकिन जैसे ही writing process automate होती है, यह स्पष्ट हो जाता है कि इंसानी क्षमता ही असली scarce resource है
• डेवलपर अधिक उत्पादक होते हुए भी कम खुश और अधिक अस्थिर हो सकते हैं, और tools बनाने वाली टीमें भी उसी समस्या से जूझते हुए real time में reward function समायोजित कर रही हैं
• कोड और development का तरीका बदल रहा है, लेकिन इंसान अब भी loop के भीतर है, और इस समय की केंद्रीय स्थिति है मानव प्रतिभागी की थकान

[GN⁺]

Hacker News की राय

• मैनुअल कोडिंग जितनी कठिन होती थी, समस्या हल करने, logic समझने, compile सफल होने और control महसूस करने जैसे छोटे rewards उतने ही बड़े लगते थे। इसके उलट agent coding feature के आकार से अलग, लगातार वैसी ही निगरानी मांगती है; शुरुआत में productivity की लहर पर सवार होने जैसा उत्साह होता है, लेकिन संतोष देने वाले हिस्से घटते जाते हैं और review का cognitive load बढ़कर जल्दी थका देता है

  • नौकरी खोने से ज़्यादा डर इस बात का है कि कहीं जल्द ही काम से ही नफ़रत न होने लगे। जिन कामों में LLM को निर्देश देने से ज़्यादा समय नहीं बचता, वे खुद करता हूँ, और output structure को इंसान के लिए समझने लायक फिर से सँवारते हुए control का एहसास बनाए रखता हूँ
  • मेरी प्रेरणा इस बात में ज़्यादा है कि बनाए गए product को कितने लोग उपयोगी पाते हैं, न कि code कैसे बनाया गया। users को पहले रखकर ज़रूरत पड़ने पर shortcuts लिए हैं, और maintainable code व release speed का संतुलन LLM इस्तेमाल करके भी बनाया जा सकता है
  • development, knowledge-based profession से कम वेतन वाले factory labor जैसा बन सकता है। खुद code लिखने की तुलना में LLM को guide करने के लिए ज़रूरी knowledge और experience बहुत कम है, और LinkedIn पर लगभग बिना experience या junior level वाले लोग भी AI engineer के रूप में hire हो रहे हैं
  • जब AI अपने output को खुद test करने वाला loop बनाता है, तब dopamine महसूस होता है। Codex को किसी खास laptop और Linux kernel पर hibernate mode चलाने के लिए network-USB-C keyboard dongle, Fingerbot और webcam तक जोड़कर remote control कराने जैसी Rube Goldberg-style automation जितनी ज़्यादा थी, उतना ही ज़्यादा संतोष मिला
  • personal projects में features बनाना आसान होने के साथ-साथ result ज़्यादा polished और consistent होता है, इसलिए satisfaction उल्टा बढ़ता है। किसी project पर एक महीने focus करें तो काफ़ी अच्छा result मिलता है, और rewriting व structure cleanup सस्ते हो जाने से design space को असल में ज़्यादा व्यापक रूप से explore किया जा सकता है। हालांकि कई बार frustration भी होती है; आधी वजह मेरी context देने की समस्या है, आधी model की inherent limits

• Claude को काम और personal projects में खुशी से इस्तेमाल कर रहा हूँ, और असल बात है agent के लालच से बचकर उसे code generator की तरह treat करना। सिर्फ़ एक session खोलकर plan को अच्छी तरह refine करने के बाद step-by-step execution देखते रहें, और हर step खत्म होने पर review व direction correction करें, तो आखिर में भी code की स्थिति अच्छी तरह समझ में रहती है
  one-shot के क़रीब इस्तेमाल करना हो तो planning stage में architecture ही नहीं, बल्कि major decisions को प्रभावित करने वाला actual code भी concretize करना पड़ता है। refactoring cost पहले से कहीं कम है, इसलिए जो हिस्से समझने में मुश्किल हों उन्हें तुरंत LLM के साथ ठीक करें, लेकिन एक समय में एक LLM सिर्फ़ एक काम करे और आप लगातार process में शामिल रहें

  • Claude के साथ कई महीनों तक काम करने के बाद मैंने यह flow सीखा कि शुरुआत में details पर पर्याप्त discussion किया जाए और ज़रूरत हो तो skeleton तक बनाकर फिर execution कराया जाए; इसे https://github.com/ctomkow/claude/blob/main/README.md में संक्षेप में लिखा है। लंबे समय से टाले गए legacy code को नई architecture में सफलतापूर्वक refactor कर रहा हूँ
    Claude को पूरा अधिकार दे देने पर अनिवार्य रूप से पैदा होने वाली गड़बड़ी और रुकावटें इंसान को थका देती हैं। जब चाहें खुद coding करें और थकने पर Claude को सौंप दें, तो codebase पर control का एहसास भी बना रहता है
  • editor से पूरी तरह अलग conversation में सिर्फ़ ज़रूरी code snippets paste करके constraints और ideas पर चर्चा करता हूँ; संतुष्ट होने पर editor में ले जाकर names और implementation को और refine करता हूँ। जो काम clear या मज़ेदार हों वे खुद करने चाहिए और architecture decisions में भी शामिल रहना चाहिए, तभी project से जुड़ाव महसूस होता है और गहरी समझ बनती है
  • vibe coding में कई agent loops इस्तेमाल करने पर भी, output को करीब से देखने वाले assistant-tool approach की तुलना में जल्दी burnout हो सकता है
  • incremental तरीके से काम करने पर भी जब कोई दूसरा review करता है, तो उसे पूरे result को पहली बार देखने वाली नज़र से एक साथ देखना पड़ता है, इसलिए review burden कम नहीं होता
  • workflow में अधिकतम दो streams के बीच आ-जा सकते हैं, लेकिन उससे ज़्यादा होने पर context switching से दिमाग पूरी तरह थक जाता है

• किसी सहकर्मी या subordinate के code की review करते समय feedback की technical validity के साथ-साथ ego, architecture perspectives का फर्क, polite tone, extra workload और team dynamics तक सोचना पड़ता है, जिससे अधिकांश mental energy खर्च होती है। इसके उलट LLM के emotional impact की चिंता नहीं करनी पड़ती, इसलिए review और direction correction कहीं आसान हो जाते हैं

  • अगर पता हो कि सहकर्मी मेरा feedback फिर AI को दे देगा, तो मैं इंसान के बजाय AI को target करके लिखने लगता हूँ, और सुधारों की list बहुत छोटी व direct तरीके से दे देता हूँ
  • tech lead के तौर पर हर PR में “इतना काफी है” जैसी pushback झेलता आया हूँ, लेकिन LLM से बिना pushback के सही तरीके से फिर से करो कह पाना सुविधाजनक है

• workplace में human in the loop के बजाय इसे Human on the hook कहना शुरू कर दिया है। यह उस structure को ज़्यादा सही तरह से बताता है जिसमें काम अच्छा हो तो credit नहीं मिलता, लेकिन गलत हो तो जिम्मेदार वही इंसान होता है—यानी समस्या आने पर ही इंसान महत्वपूर्ण बनता है

• code लिखना अपने-आप में मेरे लिए कभी मुश्किल हिस्सा नहीं रहा। तेज़ typing, Vim modal editing, Unix commands, scripts और shortcuts, Git, IDE refactoring, Java—इन सबमें दक्ष होकर जब पता होता है कि क्या बनाना है, तो सोचने की speed से काम करता हूँ
  रुकने का पल typing या syntax की वजह से नहीं आता, बल्कि code का shape और सही change सोचते समय आता है; मुश्किल बढ़े तो बेहतर abstraction या IDE tools, sed सहित Unix pipelines बनाता हूँ। इसलिए bottleneck code लिखना नहीं, सोच और judgement था
  AI coding इतनी बड़ी छलांग जैसी इसलिए लग सकती है क्योंकि उम्मीद से ज़्यादा developers ने बेहतरीन tools देखे या master नहीं किए हैं। अगर आज मैं 20s में होता तो शायद इन skills को सीखने में कम समय लगाता, लेकिन मेरे लिए software engineering आकर्षक तब हुई जब समझ आया कि इनमें से कुछ भी magic नहीं है

  • “AI उन चीज़ों में अच्छा दिखता है जिनमें आप खुद अच्छे नहीं हैं” — यह बात सही बैठती है। programming में कमज़ोर हों तो AI output तेज़ और शानदार लगता है, लेकिन experienced developer के लिए निर्देश देना, इंतज़ार करना, मनवाना, सुधारना और refactor करना जोड़ें तो यह खुद करने से तेज़ न हो सकता है
    जैसे मैं drawing में कमज़ोर हूँ तो AI-generated art अद्भुत लगता है, AI programming का मूल्यांकन भी इसी principle से हो सकता है

• कई लोगों की थकान तेज़ momentum और बड़ी chaos के संयोजन से पैदा होने वाले control loss से आती है। LLM किसी genius और toddler के बीच कहीं है, इसलिए पीछे की सीट से देखते रहना रोमांचक भी है और डरावना भी
  कुछ समय तेज़ दौड़ने के बाद शायद यह एहसास होगा कि पैदल चलना भी बुरा नहीं था, और उससे मनचाही मंज़िल तक पहुँचने की संभावना उल्टा ज़्यादा थी

• LLM कोडिंग ऐसा लगता है जैसे slot machine का handle खींचकर कोई रस्म निभा रहे हों, और हर बार उम्मीद कर रहे हों कि इस बार चल जाए। सामान्य programming में errors की वजहें consistent होती हैं, और उसे इस तरह design किया जाता है कि वजह समझकर संभव हो तो उसे हमेशा के लिए हटा दिया जाए। अनुभवी developer random कोशिश करके सफल होने पर उसे “कारण पता नहीं” वाली बात मानकर नहीं छोड़ता
  अगर आप पहले से ही कई stakeholders से निपटते-निपटते थक चुके हैं, जो इस बात पर भी सहमत नहीं हो पाते कि system आखिर है क्या, तो शायद आपको पहले से पता था कि असली bottleneck इंसानी ध्यान और engineering judgment ही थे

  • जब पहली बार coding सीखकर web app बना रहा था, तो “क्या यह करके देखूं?” कहते हुए अंधाधुंध guess करके run करता रहता था और देर रात तक computer से चिपका रहता था। Skill बढ़ने पर typed languages, compiler, LSP इस्तेमाल करते हुए समझ आने लगा कि क्या काम करेगा, और addictive guessing की जगह संतोषजनक flow state में जा पाता था
    Claude coding मुझे उसी guessing वाले चरण में वापस लौटने जैसा लगता है, इसलिए मैं उसे नहीं चाहता। हालांकि complex APIs और कई components को जोड़ने वाले DevOps-type काम जैसे क्षेत्रों में, जहां मूल रूप से अंधी guessing ज्यादा होती है, LLM बातचीत सबसे उपयोगी होती है
  • अब stakeholders सहमति बनाने के बजाय LLM से अधपके plans और quarterly goals बनवाते हैं, और design, stories, technical details, implementation, code review तक सब कुछ LLM पर छोड़ देते हैं। पूरी प्रक्रिया में critical thinking और validation गायब हो जाते हैं, और unclear purpose वाले design docs और code ही जमा होते जाते हैं, जिन्हें follow करना भी मुश्किल हो जाता है
    Plans कभी भी बदल सकते हैं, और impulsively सब कुछ फिर से लिखे जाने की संभावना भी और बढ़ जाती है

• लेख के core point से सहमत हूं, लेकिन जगह-जगह Claude-typical writing style झलकती है, इसलिए AI से लिखे गए लेख को पढ़ना और भी थकाऊ लगता है

  • संभावना है कि इसे AI ने सीधे नहीं लिखा, बल्कि corporate style में fit करने के लिए editing और review से गुजारा गया है। LLM खुद भी इसी तरह की writing style पर trained है
  • अधिकतर हिस्सा AI ने लिखा है, लेकिन सामान्य AI लेखों की तुलना में इसमें इंसानी दखल काफी ज्यादा है, इसलिए यह usual जितना खटकता नहीं
  • “It’s not” की repetition और dash के इस्तेमाल जैसे style fingerprints देखें तो इसे AI-written माना जा सकता है
  • अगर किसी ने खुद लिखने की मेहनत नहीं की, तो मैं भी पढ़ने की मेहनत नहीं करना चाहता

• 2021 का लेख The Animal is Tired याद आता है: https://www.robinhobb.com/blog/archives/2021-05

  • Original site IP block करती है, इसलिए कम restrictive mirror https://archive.is/RWxXP पर देखा जा सकता है। अपने decline को महसूस करना शायद सबसे बड़ा दुख हो सकता है, और यह हर किसी के साथ होता है
    शरीर का और ज्यादा ख्याल रखा होता तब भी आखिरकार शायद उसी जगह पहुंचते, और कीमती यादें छूट गई होतीं। शरीर का ध्यान रखें, लेकिन उसे game की potion की तरह न बरतें जिसे अगले battle में जरूरत पड़ सकती है इसलिए अंत तक इस्तेमाल ही न कर पाएं। हमारे शरीर का हर हिस्सा किसी बड़े उद्देश्य के लिए एक बार बलिदान हो सकता है, या बिल्कुल भी नहीं हो सकता—बस इतना ही
    सिर्फ इन बातों को सोचकर रो पड़ने जितना मैं अब भी emotional crisis में हूं

• AI के इस्तेमाल से काम की intensity बढ़ती है—Berkeley Haas की यह research publicity प्रभावशाली है, लेकिन HBR article https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... और publicity material https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... आने के 5 महीने से ज्यादा बाद भी actual paper या preprint नहीं मिल रहा
  अभी तक जो पता है, वह एक single industry की एक company में किए गए लगभग 40 qualitative interviews भर हैं, इसलिए research method देखे बिना results की reliability आंकना मुश्किल है

  • Automation को broader तौर पर कवर करने वाला Ironies of Automation https://static1.squarespace.com/static/644321e78cd2dd37613af... भी पढ़ने लायक है, और मुझे लगता है कि वही principle AI automation पर भी लागू किया जा सकता है