AI थकान वास्तव में मौजूद है, लेकिन कोई इसके बारे में बात नहीं करता

 (siddhantkhare.com)
17 पॉइंट द्वारा GN⁺ 2026-02-09 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • AI अपनाने के बाद उत्पादकता बढ़ी है, लेकिन थकान भी गहरी हुई है — यह प्रवृत्ति इंजीनियरों के बीच फैल रही है
  • काम की रफ्तार तेज हुई है, लेकिन काम का बोझ और अपेक्षाएँ साथ-साथ बढ़ी हैं, जिससे इंसानों पर समन्वय और समीक्षा का भार बढ़ गया है
  • AI कोड की समीक्षा और निर्णय की प्रक्रिया बार-बार दोहराए जाने से निर्णय थकान और संज्ञानात्मक क्षय जमा होता जाता है
  • लगातार नई तकनीकों के पीछे भागना, टूल बदलने की थकान, और non-deterministic AI output चिंता और burnout को बढ़ाते हैं
  • AI का टिकाऊ उपयोग करने के लिए सीमाएँ तय करना, समय प्रबंधन, और पूर्णतावाद को ढीला करना अनिवार्य है

AI उत्पादकता और थकान का विरोधाभास

  • AI अलग-अलग कामों की गति बढ़ाता है, लेकिन कुल काम और अपेक्षाएँ भी साथ-साथ बढ़ जाती हैं
    • जिस दौर में एक काम पर पूरा दिन लगता था, अब कई समस्याओं को एक साथ संभालना पड़ता है, इसलिए context switching cost बढ़ जाती है
  • उत्पादन लागत घटी है, लेकिन समन्वय, समीक्षा और निर्णय की लागत बढ़ी है, और यह बोझ पूरी तरह इंसानों पर डाल दिया गया है
  • AI तेज़ी से कोड बना दे, तब भी मानव की संज्ञानात्मक थकान उल्टा बढ़ने वाली संरचना बन जाती है

सृजनकर्ता से समीक्षक तक का बदलाव

  • AI आने के बाद इंजीनियर की भूमिका सृजनकर्ता से मूल्यांकनकर्ता की ओर खिसक गई है
    • prompt लिखना, परिणाम की समीक्षा करना, और accuracy तथा safety परखना जैसी दोहराव वाली मूल्यांकन-आधारित गतिविधियाँ केंद्र में आ गई हैं
  • generative काम immersion पैदा करता है, जबकि evaluative काम थकान पैदा करता है
  • AI कोड की विश्वसनीयता कम होने के कारण हर लाइन की समीक्षा करनी पड़ने का बोझ बढ़ गया है
  • इसके चलते security और permission management system का महत्व बढ़ता है, और दिशा ऐसी होनी चाहिए जो इंसानी संज्ञानात्मक बोझ घटाए

non-determinism की समस्या

  • AI एक non-deterministic system है जो एक ही input पर अलग output दे सकता है, और यह इंजीनियरों की सोच से टकराता है
  • एक ही prompt से अलग परिणाम निकलते हैं, जिससे debug न की जा सकने वाली अस्थिरता पैदा होती है
  • इसे कम करने के लिए deterministic context refinement tool Distill विकसित किया गया, ताकि input की consistency बनी रहे
  • कुछ इंजीनियर AI output को ‘अपूर्ण ड्राफ्ट’ की तरह देखते हैं और editing के समय को पहले से budget में शामिल करते हैं

FOMO(छूट जाने का डर) और टूल थकान

  • पिछले कुछ महीनों में अनगिनत AI agent, framework, और SDK तेज़ी से सामने आए हैं
  • नए टूल्स के साथ कदम मिलाने की कोशिश लगातार सीखने और बार-बार बदलने के दुष्चक्र को जन्म देती है
  • ज्ञान का जल्दी अप्रासंगिक हो जाना और दोहराव वाला काम होता है, और कई बार शुरुआती अपनाने वालों से ज़्यादा इंतज़ार करने वाले लोग अधिक कुशल साबित होते हैं
  • लेखक ने infrastructure layer (permissions, context, security) पर ध्यान केंद्रित करने वाला ऐसा तरीका अपनाया है जो टूल बदलावों से कम डगमगाता है

‘बस एक बार और prompt’ का जाल

  • AI output के परफेक्ट न होने की वजह से prompt को बार-बार सुधारते रहने का चक्र शुरू हो जाता है
  • बार-बार कोशिश करना उत्पादक लग सकता है, लेकिन असल समस्या हल करने के बजाय prompt tuning में समय बर्बाद होता है
  • तीन कोशिशों के बाद भी अगर 70% से ज़्यादा उपयोगी न हो, तो सीधे खुद लिखने का ‘3 बार का नियम’ लागू किया जाता है

पूर्णतावाद और probabilistic output की टक्कर

  • AI output हमेशा ‘लगभग सही’ स्तर का होता है, जो पूर्णतावादी इंजीनियरों के लिए बड़ा तनाव बनता है
  • छोटे-छोटे सुधारों की पुनरावृत्ति भावनात्मक थकान और समय की बर्बादी में बदल जाती है
  • AI के परिणाम को ‘ड्राफ्ट’ मानकर तेज़ी से परिष्कृत करना अधिक प्रभावी रवैया है

सोचने की क्षमता का कमजोर होना

  • AI पर निर्भरता के कारण समस्या-समाधान की सोच और design ability में गिरावट आती है
  • खुद न सोचने की आदत ‘सोच की मांसपेशियों’ के सिकुड़ने तक ले जाती है
  • इसे रोकने के लिए हर दिन कुछ समय AI के बिना सोचना और design practice करना ज़रूरी है

तुलना का जाल

  • SNS पर सिर्फ AI की मदद से तेज़ सफलता पाने के उदाहरण साझा होते हैं, इसलिए किसी व्यक्ति की असफलता या थकान सामने नहीं आती
  • AI से मिली उपलब्धियों की reproducibility कम होती है, इसलिए तुलना करना ही निरर्थक है
  • बेहतर है कि सूचना-उपभोग कम किया जाए और वास्तविक निर्माण व संचालन पर केंद्रित भरोसेमंद स्रोतों पर ध्यान दिया जाए

टिकाऊ AI उपयोग की रणनीतियाँ

  • AI session के समय की सीमा तय करना, ताकि अत्यधिक दोहराव रुके
  • सोचने के समय और AI उपयोग के समय को अलग रखना, ताकि संज्ञानात्मक संतुलन बना रहे
  • 70% पूर्णता को स्वीकार करना, यानी पूर्णतावाद को ढीला करना
  • नई तकनीक अपनाने में देरी करना, और अधिकतर validated tools का उपयोग करना
  • AI efficiency log रखना, ताकि वास्तविक उपयोगिता और सीमाएँ समझी जा सकें
  • review scope छोटा रखना, और केवल core area पर ध्यान देना

टिकाऊपन और burnout

  • AI काम की रफ्तार की सीमाएँ हटा देता है, जिससे overwork और तेज़ हो जाता है
  • इंसान की संज्ञानात्मक सीमाएँ पार होने पर burnout होता है, और यह किसी एक व्यक्ति की नहीं बल्कि systemic problem बन जाती है
  • उबरने की कुंजी AI की मात्रा कम करना नहीं, बल्कि इसके उपयोग के तरीके को फिर से डिजाइन करना है
  • इसी थकान के बीच Distill, agentic-authz, AgentTrace जैसे वास्तविक समस्याएँ हल करने वाले टूल पैदा हुए

असली क्षमता: रुकना कब है, यह जानना

  • AI युग की सबसे अहम क्षमता यह समझना है कि कब रुकना चाहिए
  • पर्याप्त अच्छे output पर रुक जाना, खुद लिखना कब है, और आराम कब करना है — यह पहचानने की क्षमता
  • मानव मस्तिष्क को सीमित संसाधन मानकर उसकी रक्षा करना ही सच्ची engineering है
  • AI शक्तिशाली है, लेकिन संज्ञानात्मक रूप से सबसे अधिक थकाने वाले टूल्स में से एक है; समझदारी से उपयोग ही टिकाऊपन की कुंजी है
  • टिकाऊ output ही असली मूल्य है, और यही AI उपयोग का अंतिम लक्ष्य है

संबंधित पढ़ाई

5 टिप्पणियां

 
fantajeon 2026-02-09

मुझे नहीं पता कि अब यह अभिव्यक्ति कितनी सटीक है, लेकिन ऐसा लगता है कि डेवलपर धीरे-धीरे "tech leader" बनता जा रहा है.

अगर AI "code writing" अपने हाथ में ले लेता है, तो आखिर में बचता क्या है:

  • समस्या हल करना (stress)
  • नतीजों की समीक्षा करना (stress)
  • ज़िम्मेदारी (stress)

बस यही.

यानी डेवलपर अब "producer" कम और

  • "decision maker"
  • "reviewer"
  • "person in charge"

ज़्यादा बनता जा रहा है.

इस वजह से काम से जुड़ी एक नई तरह की थकान पैदा हो रही है,
और मैं खुद से पूछने लगता हूँ कि क्या यह दिशा सच में उस डेवलपर की भूमिका और योग्यता से मेल खाती है, जिसे मैं अपनाना चाहता था.
 
roxie 2026-02-24

आखिरी पंक्ति दिल को छूती है। लगता है, मैं जो करना चाहता था, वह शायद यह नहीं था।
 
dolsangodkimchi 2026-02-26

जब मैं छोटा था, मैं एक band club में था, और वहाँ एक लड़का था जो दोस्तों को समझाता था कि हमें अपने original songs बनाने चाहिए। वह कहता था कि सिर्फ़ performance skills निखारने से ज़्यादा ज़रूरी यह सोचना है कि हम क्या गाना चाहते हैं। बेशक, जहाँ तक मुझे याद है, मशहूर गानों की copy करके band करने वाले बच्चों की राय ज़्यादा भारी थी।
लेकिन आजकल मुझे उस दोस्त की याद अक्सर आती है।
यह एक ऐसा सवाल है जिसे मैं ज़िंदगी की भागदौड़ में नज़रअंदाज़ करता रहा, लेकिन AI के विकास के साथ, developer बनने के बाद अब मुझे सोचना पड़ रहा है कि क्या मुझे code लिखने की क्रिया सच में पसंद है, या मुझे value creation पसंद है और code लिखना सिर्फ़ उसका एक साधन है।
अगर अब तक ये दोनों तरह की प्रवृत्तियाँ आपस में उलझी हुई थीं, तो अब लगता है कि बहुत जल्द वह समय आने वाला है जब मुझे साफ़-साफ़ तय करना होगा कि मैं किस तरफ़ हूँ।
 
pencil6962 2026-02-26

ग्राहक की ज़रूरतों के मुताबिक अच्छी तरह काम करने वाला प्रोग्राम, और बिना खराबी के चलने वाला प्रोग्राम बनाने की ज़िम्मेदारी अब भी डेवलपर की ही है, इसलिए कोड लिखने की क्रिया को छोड़ने की ज़रूरत नहीं है। मेरा मानना है कि सिर्फ़ typing ही AI कर रहा है, मूल बात वही रहती है।
 
GN⁺ 2026-02-09
Hacker News की राय

  • मेरे लिए थकान थोड़ी अलग है। काम करते समय, code review करते समय, हर बार जब LLM output generate करता है तो रुककर इंतज़ार करना ही असली समस्या है
    इंतज़ार कितना लंबा होगा, यह अनुमान लगाना मुश्किल होता है, इसलिए समझ नहीं आता कि रुकूँ या कोई दूसरा काम शुरू कर दूँ
    नतीजा यह होता है कि बस समय काटने के लिए कुछ और करने लगता हूँ
    आखिरकार flow state में जा ही नहीं पाता, और background task कब खत्म होगा इस पर नज़र रखते-रखते थक जाता हूँ
    productivity बढ़ने से ज़्यादा, ऐसा लगता है जैसे बच्चों को चोट न लगे इस पर नज़र रखने वाला कोई आलसी babysitter बन गया हूँ

    • यह शायद गैर-जिम्मेदार सलाह हो, लेकिन मैं Claude Code को जब भी लंबा request भेजता हूँ, तो बस थोड़ा ब्रेक लेकर game खेलता हूँ
      छोटा शुरू करके कभी भी रोका जा सकने वाला open source game Endless Sky recommend करूँगा
      पहले programming मज़ेदार नहीं लग रही थी, लेकिन Claude Code की वजह से फिर से मज़ा आने लगा है। पहले जैसा तो नहीं, लेकिन मेरी ज़िंदगी के इस चरण में इतना काफ़ी है
    • ऐसी थकान कोई नई चीज़ नहीं है। बस agent-style AI coding tools आने के बाद context switching की थकान 10 गुना बढ़ गई है
      जैसा कि मैंने review fatigue पर अपने लेख में भी लिखा है, इसका असर सिर्फ developers पर नहीं बल्कि organizations पर भी पड़ता है
      AI workflow productivity maximize करने पर इतना केंद्रित है कि आखिर में इंसानों को ही थका देता है
      समाधान पुराना ही है — बार-बार ब्रेक लो, और human developer खुद भी थोड़ा-बहुत code लिखे। इससे रफ़्तार थोड़ी कम होगी, लेकिन flow और recovery बने रहेंगे
    • productivity से ज़्यादा महत्वपूर्ण चीज़ flow थी। एक cup coffee, noise-cancelling headphones, और 2 घंटे का focused session programming के सबसे प्यारे पल हुआ करते थे
    • मैं आजकल इसे “Claude Code workout routine” कहता हूँ
      जब LLM काम कर रहा होता है, तब मैं squat या push-up करता हूँ या घर में इधर-उधर चलते हुए stretching करता हूँ। पूरे दिन keyboard के सामने बैठे रहने से यह कहीं ज़्यादा अच्छा है
      शरीर हिलाने से सोच भी साफ़ होती है, लेकिन फिर भी मानसिक थकान बनी रहती है
    • पहले मैं घंटों तक डूबकर काम करता था, लेकिन अब लगातार बाधा पड़ती रहती है
      prompt भेजकर इंतज़ार करते समय web surfing करने लगता हूँ। SelfControl app से block न करूँ तो खुद को रोकना मुश्किल है
      LLM की वजह से productivity तो बढ़ी है, लेकिन दिन के अंत में मैं कहीं ज़्यादा थका हुआ और guilty महसूस करता हूँ

  • लेख का idea अच्छा है, लेकिन पढ़ते-पढ़ते AI द्वारा लिखी गई थकान महसूस होती है
    जिन बातों को एक-दो वाक्यों में खत्म किया जा सकता था, उन्हें बहुत लंबा खींचा गया है, और बेकार के examples भी बहुत हैं
    “HN main page उलझन भरा हो गया है” वाला दावा भी ग़लत है। जिन posts का ज़िक्र किया गया, उन्हें 5 upvotes भी नहीं मिले, और HN main की quality अब भी ठीक है
    और “इस बारे में कोई बात नहीं करता” यह भी ग़लत है। AI fatigue पर चर्चा तो काफ़ी पहले से होती रही है

    • “HN main page अब भी ठीक है” इस बात से मैं सहमत हूँ, लेकिन सच में अजीब चीज़ें तो ये पंक्तियाँ हैं
      “धन्यवाद OpenClaw, धन्यवाद AGI—मेरे लिए यह पहले ही आ चुका है”
      “अगर आपने आज प्रति human engineer कम से कम $1,000 के tokens खर्च नहीं किए, तो आपकी software factory में सुधार की गुंजाइश है”
      “code को humans द्वारा review नहीं किया जाना चाहिए”
      “जो C ने assembler के साथ किया, जो Java ने C के साथ किया, वही अब LLM सभी भाषाओं के साथ कर रहा है”
      ये पंक्तियाँ सचमुच main page पर चढ़ी posts से उद्धृत हैं
    • “You’re not imagining it.” यह वाक्य देखते ही मेरी तुरंत प्रतिक्रिया हुई। सच में बिल्कुल ऐसा ही लगता है
    • शायद लेखक ने LLM से कहा होगा, “मैं थका हुआ हूँ, मेरी हाल की sessions देखकर बताओ क्यों, और उस पर blog लिखो”
      या फिर शायद उसने AI से लिखी चीज़ें इतनी ज़्यादा पढ़ ली हैं कि उसकी writing style ही AI जैसी हो गई है
    • हो सकता है वह बस लिखना पसंद करने वाला इंसान हो
      मैंने भी हाल ही में blogging शुरू की है, और हैरानी की बात है कि storytelling-केंद्रित writing मज़ेदार लगती है
      हर व्यक्ति की शैली अलग होती है, इसमें अपने-आप में कोई समस्या नहीं
    • मैं भी “AI द्वारा लिखी गई थकान” वाली बात से सहमत हूँ
      लेख को कुछ paragraphs में समेटा जा सकता था, लेकिन अनावश्यक विशेषण बहुत ज़्यादा हैं
      आगे चलकर शायद content पर भी “human producer label” लगे — जैसे “freelancer-produced”, “suburban resident-produced” वगैरह

  • “तेज़ी से ship करने पर expectations बढ़ जाती हैं” इस बात से मैं सहमत हूँ
    यह बहुत पुरानी समस्या है। लगभग 100 साल पहले Helen Keller ने भी कुछ ऐसा ही कहा था
    “labour-saving machines का सच में labour बचाने के लिए इस्तेमाल करो” — यह बात The Atlantic के लेख में है

  • एक दिन में कई projects आगे बढ़ा सकता हूँ, लेकिन पूरी तरह चूर हो जाता हूँ
    “बस एक और prompt भेजकर देखते हैं” वाले लालच की वजह से बहुत लोग सो भी नहीं पाते
    लंबे समय में बना sustainable work rhythm टूट गया है, और नया संतुलन ढूँढने में समय लगेगा

    • पहले जब किसी idea पर काम शुरू करता था, तो जल्दी समझ आ जाता था कि उसमें value नहीं है या वह ठीक से नहीं चलेगा
      लेकिन अब शुरुआत में सब इतना अच्छा चलता है कि आगे बढ़ते रहते हैं, और फिर अचानक दीवार आ जाती है
    • मैं भी freelancer हूँ, और AI की मदद से एक invoicing system एक ही दिन में बना लिया
      लेकिन वहीं रुक नहीं पाया और accounting, tax, CRM, warehouse, project management तक बढ़ाता चला गया
      आखिर में एक ऐसा SaaS बना डाला जिसकी ज़रूरत ही नहीं थी, और अब सोच रहा हूँ कि इसे open source कर दूँ
    • “बस एक बार और इसे perfect बना लें” यही सोच सारा समय खा जाती है
      फिर भी अब mobile browser से agent session आगे भी देख सकता हूँ, इसलिए बिस्तर पर लेटे-लेटे भी चेक कर लेता हूँ (आधा मज़ाक, आधा सच)
    • AI ने coding में friction को बहुत कम कर दिया है
      अब असली bottleneck coding नहीं, बल्कि requirements इकट्ठा करना और decision-making है
    • अगर productivity 10 गुना बढ़ गई है, तो ब्रेक का समय भी दोगुना नहीं होना चाहिए?
      लोग फिर भी लगातार काम क्यों करते रहते हैं, यह मेरी समझ से बाहर है

  • मैं ही लेखक हूँ। यह anti-AI लेख नहीं, बल्कि cognitive cost की बात है
    काम तेज़ होने पर काम की मात्रा भी बढ़ती है, और AI के outputs review करते-करते decision fatigue जमा होती जाती है
    tools का ecosystem भी हर हफ़्ते बदल रहा है। मैंने वे तरीके साझा किए जो वास्तव में मददगार रहे, और जानना चाहता हूँ कि क्या दूसरे लोग भी ऐसी ही दीवार से टकरा रहे हैं

    • यह जानने की जिज्ञासा है कि blog और post की पंक्तियों को LLM से edit क्यों कराया गया
      किसी गैर-मानवीय इकाई से बात करने जैसा एहसास इस थकान को और बढ़ा देता है
    • लेख की image देखकर AI-generated error controversy image याद आ गई
    • लेख अच्छा था। मैंने भी AI की वजह से और ज़्यादा करने की pressure महसूस की है
      लेकिन realistic expectations तय करने और हर “AI magic post” से प्रभावित न होने की कोशिश करने के बाद anxiety कम हुई है
    • यह irony मज़ेदार है कि AI fatigue पर लिखा लेख खुद AI से बना हुआ लगता है

  • technology का उद्देश्य कभी भी workers को आराम देना नहीं रहा
    इसका मकसद हमेशा productivity और competitiveness बढ़ाना रहा है
    घोड़े से कार तक, telephone से smartphone तक बदलाव आया, लेकिन खाली समय नहीं बढ़ा। हम बस और ज़्यादा mobile और connected इंसान बन गए हैं

    • लेकिन efficiency का इस्तेमाल कैसे करना है, यह चुनाव का मामला है
      अगर कोई पुराने ढंग की life quality स्वीकार कर ले, तो कम काम करके भी ठीक-ठाक जिया जा सकता है

  • इन दिनों जो महसूस हो रहा है, वह executive functioning fatigue है
    AI के साथ काम करते समय साधारण implementation से ज़्यादा high-level decision-making लगातार करनी पड़ती है
    ब्रेक लगभग नहीं मिलते, और ऐसा लगता है जैसे prefrontal cortex ज़्यादा गरम हो गया हो
    अगर यह स्थिति लंबे समय तक रही, तो शायद इंसानों की executive function और मज़बूत हो जाए

  • मुझे पता नहीं था कि दस genius लेकिन unstable engineers की team manage करना इतना थका देने वाला होगा

    • उसे managing नहीं, micromanaging कहना चाहिए

  • मेरे हिसाब से AI fatigue की वजह programming के तीन चरणों का संतुलन बिगड़ जाना है
    problem solving → code लिखना → result verify करना, ये तीनों चरण पहले संतुलित हुआ करते थे
    coding दोहराव वाली ज़रूर थी, लेकिन ध्यानमग्न और स्थिर करने वाली प्रक्रिया भी थी। problem solving तीव्र था, और result verification dopamine reward जैसा
    लेकिन LLM ने coding अपने हाथ में ले ली, और अब हमारे पास सिर्फ ज़्यादा stress वाले problem solving और review वाले चरण बचे हैं
    बीच का buffer zone गायब हो गया, इसलिए थकान कहीं ज़्यादा होती है
    पुरानी coding को याद करने की वजह वही ध्यानमग्न flow के खो जाने में है
    मैं भी AI के साथ pair programming करते हुए खुद code टाइप करना पसंद करता हूँ। मुझे यह लंबे समय में ज़्यादा sustainable लगता है
    लेकिन कई agents को एक साथ संभालने वाली productivity का लालच भी सचमुच बहुत शक्तिशाली है

  • “non-deterministic system से जूझने वाला हिस्सा” मुझे खास तौर पर असरदार लगा
    LLM मूल रूप से इंसानों की लगातार दखलअंदाज़ी चाहता है। खासकर अगर company उसके output की पूरी ज़िम्मेदारी लेने को तैयार नहीं है

    • लेकिन ‘बेवकूफ़ मशीन’ को ज़िम्मेदार ठहराना नामुमकिन है
      न उसका voltage घटाकर सज़ा दी जा सकती है, और जैसे पासे से जवाबदेही नहीं माँगते, वैसे ही यह भी बेमानी है
    • और human developers भी पूरी तरह deterministic नहीं होते। मैंने ऐसा कोई इंसान नहीं देखा