सोच से भी तेज़ AI की रफ़्तार से पैदा होने वाली डेवलपरों की 'vibe coding' थकान का विश्लेषण
(tabulamag.com)मुख्य बिंदु:
- AI टूल्स (Claude Code, Cursor) के उपयोग से डेवलपमेंट की गति बढ़ी है, लेकिन काम की तेज़ रफ़्तार दिमाग की प्रोसेसिंग सीमा से आगे निकलकर थकान पैदा करती है
- बार-बार context switching, डोपामिन की अधिकता, और मैनेजर जैसी भूमिका में बदलाव cognitive load को और बढ़ाते हैं
- AI की रफ़्तार के पीछे इंसान के घसीटे जाने वाली 'machine time' की स्थिति बन रही है, जिससे गति पर सक्रिय नियंत्रण की ज़रूरत उभरती है
परिचय
- AI टूल्स की उपयोगिता और दुष्प्रभाव: 40 साल के अनुभव वाले एक डेवलपर ने Claude Code और Cursor का उपयोग करके पैकेज मैनेजर (Marvai) विकसित किया और productivity में बढ़ोतरी का अनुभव किया, लेकिन साथ ही पहले कभी न महसूस हुई थकान भी महसूस की।
- समस्या का उठान: फीचर इम्प्लीमेंटेशन और bug fixing की गति तेज़ हुई, लेकिन AI की रफ़्तार के साथ दिमाग तालमेल नहीं बैठा पाया, जिससे कम समय (करीब 1 घंटे) काम करने के बाद भी पूरी तरह थक जाने जैसी स्थिति पैदा हुई।
मुख्य भाग
1. cognitive load में तेज़ बढ़ोतरी और 'machine time' का दबाव
- cognitive load theory का अनुप्रयोग: Team Topologies सिद्धांत के अनुसार अत्यधिक जिम्मेदारियाँ और विषयों के बीच बार-बार बदलाव cognitive load बढ़ाते हैं। AI coding इस बोझ को लगभग सीमा तक धकेल देती है।
- मशीन-चालित रिद्म: जैसे पहले फैक्ट्री के मज़दूरों को मशीन की रफ़्तार के अनुसार चलना पड़ता था, वैसे ही AI-चालित तेज़ coding गति के पीछे भागने का अनुभव डेवलपरों को होता है; इसे 'machine time' कहा जा सकता है।
- सोचने की प्रक्रिया का गायब होना: पारंपरिक coding में काम की गति और सोच की गति लगभग एक जैसी रहती थी, जिससे दिमाग को प्रोसेस करने का समय (Baking time) मिलता था। लेकिन AI coding जटिल architecture और decision process को पल भर में निपटा देती है, जिससे दिमाग का synchronization बाधित होता है।
2. डोपामिन की अधिकता और stress hormones का साथ-साथ असर
- डोपामिन लूप का तेज़ होना: 'coding-error-solution-success' वाला डोपामिन reward cycle AI की वजह से बेहद तेज़ हो गया है।
- भावनात्मक थकावट: बार-बार डोपामिन रिलीज़ और रफ़्तार से पैदा होने वाले stress hormones साथ मिलकर coding के आनंद की जगह थकान और overwhelm की भावना पैदा करते हैं।
3. context switching की लागत में बढ़ोतरी
- दिमागी cache पर अधिक दबाव: context switching दिमाग की cache को खाली करके फिर से भरने जैसा high-energy काम है।
- micro-context switching: AI एक साथ कई modules बदल सकती है, या साधारण tab completion (
Tabkey) के उपयोग के दौरान भी 'लेखन मोड' से 'रिव्यू मोड' में बार-बार छोटे-छोटे बदलाव थोपती है, जिससे दिमागी ऊर्जा तेज़ी से खत्म होती है।
4. डेवलपर की भूमिका में मूलभूत बदलाव
- लेखक से मैनेजर तक: आवश्यकताओं को code में बदलने वाली भूमिका से हटकर, डेवलपर अब AI जैसे 'तेज़ टीम सदस्य' के आउटपुट को संभालने और रिव्यू करने वाले 'टीम लीडर' या 'ट्रैफिक कंट्रोलर' की भूमिका में आ गया है।
- जिम्मेदारी की असमानता: AI जहाँ पाँच लोगों के बराबर काम उगल सकती है, वहीं code quality की अंतिम जिम्मेदारी अब भी डेवलपर पर ही रहती है, जिससे प्रबंधन का बोझ और बढ़ता है।
निष्कर्ष
सस्टेनेबल AI coding के लिए सुझाव
- जानबूझकर गति नियंत्रण (Pacing): AI की रफ़्तार में बहने के बजाय डेवलपर को खुद काम की गति नियंत्रित करनी चाहिए।
- नए retrospective तरीकों की शुरुआत: AI और दिमाग के बीच sync बनाए रखने के लिए daily retrospective जैसी नई work routines की ज़रूरत है।
- भूमिका की समझ में बदलाव: AI output को सूक्ष्म स्तर पर नियंत्रित करने वाली micromanaging कम करनी होगी और AI पर अधिक भरोसा करने वाले कार्य-शैली परिवर्तन की ज़रूरत होगी।
- भविष्य की दिशा: coding का भविष्य केवल बिना शर्त गति बढ़ाना नहीं, बल्कि इंसानी cognitive limits को ध्यान में रखते हुए 'जानबूझकर धीमापन' और नई सीमाओं का निर्माण हो सकता है।
14 टिप्पणियां
मेरा भी ऐसा ही अनुभव रहा है, इसलिए मैं इस तरह करता हूँ.
उदाहरण के लिए, अगर refactoring करनी हो,
'मौजूदा कोड का विश्लेषण करने के बाद विकल्प सुझाने का निर्देश'
'विकल्प और मौजूदा कोड के अंतर, फायदे-नुकसान का संक्षेप में वर्णन करने का निर्देश'
'यह सत्यापित करने का तरीका सुझाने का निर्देश कि क्या विकल्प वास्तव में बेहतर है'
'विकल्प का सीधे सत्यापन'
'विकल्प लागू करने और documentation, test लिखने का निर्देश'
समस्या यह है कि token usage बहुत बढ़ जाता है, इसलिए लागत भी काफी बढ़ जाती है...
सिर्फ साधारण मेहनत वाला काम हो तब भी, उसकी जगह macro बना लेना ही मुझे ज़्यादा सुकून देता है...
लोगों के बीच भी ऐसा ही होता है.
लोगों के बीच भी ऐसी समस्या अक्सर होती है.
अगर सोचने में धीमा व्यक्ति manager हो,
तो वह कहता है,
“काम बहुत तेज़ी से चल रहा है, इसलिए थकाने वाला है और साथ काम करना मुश्किल है,”
और अगर वही व्यक्ति subordinate हो,
तो वह कहता है,
“बात ठीक से समझ में नहीं आती, इसलिए साथ काम करना मुश्किल है.”
आखिरकार, साथ काम करने के लिए आपसी chemistry का मेल होना ज़रूरी है.
कोडिंग छिन जाने के बाद सिर्फ code review और testing ही करते रहने की पीड़ा...
मैं निजी प्रोजेक्ट्स को छोड़कर vibe coding का इस्तेमाल सीमित तौर पर करता हूँ। Cursor autocomplete में बस ideation और एक जैसे pattern को दोहराने वाली coding जैसी चीज़ों के लिए ही इसका उपयोग करता हूँ। लंबे समय तक चलने वाले प्रोजेक्ट में vibe coding से हर चीज़ हल करने की कोशिश करना, मेरे हिसाब से एक developer के तौर पर गैर-जिम्मेदाराना व्यवहार है।
ऐसा लगता है कि जो लोग सिर्फ़ prompt लिखकर नतीजे निकालने वालों की तुलना में, तैयार हुए नतीजों के code को समझते हैं और उसकी जाँच/समीक्षा करते हैं, वे ज़्यादा fatigue महसूस करते हैं।
मूल लेख में भी यही बात आई है.
मैंने तो कभी इस तरह की थकान महसूस ही नहीं की, क्योंकि मेरे मन में बस यही आता है कि 'AI की वजह से मेरा काम कम हो गया, यह अच्छी बात है।' मैं zed + claude इस्तेमाल करता हूँ, और कभी-कभी बीच में context बदल जाने से यह अजीब तरह से काम करने लगता है, लेकिन ऐसे समय में मैं git में जाकर code वापस कर देता हूँ और कहता हूँ, 'ऊपर की बातों को समेटकर फिर से लिखो,' तो यह उसे और साफ-सुथरा बना देता है। बात बस इतनी है कि मैं खुद टाइप करके code नहीं लिख रहा; दिमाग में जो सोच थी उसे code में बदलने की प्रक्रिया ही बदली है, है ना? उल्टा, prompt लिखते समय कई बार सोच और व्यवस्थित भी हो जाती है।
क्या कोड बनाने की प्रक्रिया एक ब्लैक बॉक्स बन जाने से कोड और दिमाग में चल रहे विचारों को sync करने के लिए समय चाहिए नहीं होता?
पारंपरिक code writing में यह गारंटी होती है कि कोड और दिमाग में मौजूद विचार एक जैसे हैं, लेकिन LLM के ज़रिए coding में इसकी गारंटी नहीं होती।
दिमाग में सिर्फ लॉजिक हो और AI ने जो कोड लिखा है वह सही बना है या नहीं बस वही चेक करना हो, तो क्या दिमाग में खुद कोड लिखने की ज़रूरत है? अब तो बस यह सोचना होता है कि prompt में कितना सटीक data देना है, इसलिए उल्टा काम की रफ्तार काफी तेज़ हो गई है।
यह इस बात पर निर्भर कर सकता है कि आप prompt कितनी बारीकी से लिखते हैं। अगर आप इसे pseudocode स्तर पर LLM को दे रहे हैं, तो आपकी बात समझ में आती है।
पहले पूरे दिन कोड लिखने के बाद काम खत्म होने पर एक संतुष्टि महसूस होती थी, लेकिन अब दिन भर का ज़्यादातर काम बातचीत से ही निपट जाता है और कई दिनों तक मैं खुद एक लाइन कोड भी नहीं लिखता, फिर भी बर्नआउट आ गया है.. पूरी तरह सहमत हूँ
मेरे साथ भी ठीक इसी वजह से थकान बढ़ी है। मुझे पहले से अंदाज़ा था कि ऐसा होगा, इसलिए सिर्फ़ थका होना अपने-आप में ठीक है, लेकिन उससे भी बड़ी बात यह है कि बाहर से देखने पर, क्योंकि कोडिंग करते समय कीबोर्ड पर लगातार टाइप करते रहने वाला समय अब नहीं दिखता, शायद लोगों को लगता है कि मैं बहुत आराम से काम कर रहा हूँ। अगर मैं कहूँ कि मैं पहले से ज़्यादा थक जाता हूँ, तो लोग उसे अच्छी तरह समझ नहीं पाते....
आह, ऐसा लग रहा है जैसे किसी ने मेरी थकान की वजह को मेरे लिए बिल्कुल साफ़ शब्दों में समझा दिया हो।
1. "रफ्तार ऊर्जा देती है" (सकारात्मक पक्ष)
2. "vibe coding की परिभाषा पर बहस" (शब्दगत भ्रम)
3. "सत्यापन के बिना रफ्तार तकनीकी कर्ज है" (सावधान पक्ष)
4. "context switching की थकान" (सहानुभूति रखने वाला पक्ष)
5. "coding का आनंद खो जाना" (dopamine की कमी)
6. "शुरुआती के लिए ज़हर, अनुभवी के लिए दवा" (कौशल-स्तर के अनुसार फर्क)
7. "manager की भूमिका में जबरन बदलाव" (भूमिका परिवर्तन)
8. "business logic की समझ का अभाव" (सीमाओं की ओर इशारा)
9. "आराम और फुर्सत का गायब होना" (machine time)
10. "tooling की संक्रमणकालीन समस्या" (भविष्य की दिशा)