वाह वाह वाह :)

मेरा मानना है कि "X ही भविष्य है" जैसे वाक्य को समझदारी से इस तरह पढ़ना चाहिए कि "मैं चाहता हूँ कि X भविष्य हो।"

सच में कई हिस्सों से रिलेट कर पाया, हाहा। इतनी झुंझलाहट होती है कि बस छोड़ो और जितने पैसे मिलते हैं उतना ही काम करो वाले मोड में चला जाता हूँ, तो उल्टा लोग खुश होते हैं कि काम ज़्यादा smoothly आगे बढ़ रहा है। असल में तो डेवलपमेंट की दिशा में risk दिख रहा होता है, लेकिन अब हालत ऐसी हो गई है कि मुझे उससे कोई मतलब ही नहीं रहा।

https://hi.news.hada.io/topic?id=21170
इस लेख के साथ इसे भी देखना अच्छा रहेगा

> हालांकि permission model लागू नहीं था, इसलिए token permissions को नियंत्रित नहीं किया जा सकता था (अगर मैं गलत हूं तो बताइए)

फ़िलहाल यह समर्थित है।

https://code.visualstudio.com/updates/v1_107/…

1. "रफ्तार ऊर्जा देती है" (सकारात्मक पक्ष)

• रुख: उबाऊ काम AI तेज़ी से निपटा देता है, इसलिए उल्टा ऊर्जा बढ़ती है, और नया tech stack सीखने की लागत भी घटती है, इसलिए इसे सकारात्मक माना जाता है।
• मामला: अनजानी language या framework इस्तेमाल करते समय AI agent की वजह से उबाऊ learning process छोड़कर सीधे implementation पर ध्यान देना संभव हुआ।

2. "vibe coding की परिभाषा पर बहस" (शब्दगत भ्रम)

• बहस: 'vibe coding' का मतलब सिर्फ AI की मदद लेना है, या फिर generated code को review किए बिना सिर्फ result देखना—इसकी परिभाषा पर मतभेद हैं।
• सहमति का बिंदु: मूल रूप से इसका नकारात्मक अर्थ 'code review न करना' था, लेकिन अब इसका अर्थ फैलकर AI-assisted coding के पूरे दायरे तक पहुँच गया है।

3. "सत्यापन के बिना रफ्तार तकनीकी कर्ज है" (सावधान पक्ष)

• आलोचना: code को समझे बिना AI द्वारा बनाए गए output पर भरोसा करना जोखिमभरा है। बाद में आने वाले bug या maintenance cost (technical debt) और बड़े हो सकते हैं।
• उपमा: "जैसे कोई व्यक्ति self-driving car में बैठा हो और उसे पता ही न हो कि वह कहाँ जा रही है"—समझ के बिना implementation आखिरकार problem-solving क्षमता को कम कर देता है।

4. "context switching की थकान" (सहानुभूति रखने वाला पक्ष)

• सहमति: AI के code generate करने के दौरान बार-बार context switching होने से दिमाग पर cognitive load तेज़ी से बढ़ता है।
• लक्षण: AI के output को review और edit करने की प्रक्रिया बार-बार दोहरने से, सीधे coding करने की तुलना में मानसिक थकान अधिक होती है। 4 घंटे का काम भी ऐसे थका देता है जैसे पूरा दिन काम किया हो।

5. "coding का आनंद खो जाना" (dopamine की कमी)

• अनुभव: खुद समस्या हल करने पर मिलने वाली उपलब्धि की भावना (dopamine) गायब हो जाती है। यह वैसा लगता है जैसे LEGO खुद जोड़ने का मज़ा छोड़कर सिर्फ तैयार प्रोडक्ट को देखना।
• नतीजा: प्रक्रिया का आनंद बिना, सिर्फ output जल्दी निकालने वाला काम डेवलपर को थका देता है।

6. "शुरुआती के लिए ज़हर, अनुभवी के लिए दवा" (कौशल-स्तर के अनुसार फर्क)

• विश्लेषण: अनुभवी डेवलपर AI की गलतियाँ जल्दी पकड़कर ठीक कर सकते हैं, इसलिए उनकी productivity बढ़ती है; लेकिन शुरुआती लोग गलत code को वैसे ही इस्तेमाल कर सकते हैं, सीखने के मौके खो सकते हैं, और खराब code बड़ी मात्रा में बना सकते हैं।

7. "manager की भूमिका में जबरन बदलाव" (भूमिका परिवर्तन)

• स्थिति: डेवलपर की भूमिका सीधे code लिखने वाले 'creator' से बदलकर AI द्वारा लगातार निकाले जा रहे code को review और edit करने वाले 'manager/reviewer' में जबरन बदल रही है।
• बोझ: यह ऐसा भारी stress पैदा करता है जैसे एक व्यक्ति को 5 junior developers (AI) के लिखे code का real time में review अकेले करना पड़े।

8. "business logic की समझ का अभाव" (सीमाओं की ओर इशारा)

• समस्या: AI code तो अच्छी तरह लिख सकता है, लेकिन business context या पूरी architecture को नहीं समझता।
• हकीकत: आखिरकार business requirements को code के मुताबिक समायोजित करना और edge cases को संभालना अब भी इंसानों का काम है, और इसी प्रक्रिया में bottleneck पैदा होता है।

9. "आराम और फुर्सत का गायब होना" (machine time)

• उपमा: जैसे पहले कारखाने के मज़दूरों को मशीन की गति के हिसाब से काम करना पड़ता था, वैसे ही अब इंसान AI की तेज़ generation speed के पीछे घिसटते हुए 'machine time' में फँस जाते हैं।
• ज़रूरत: compile होने का इंतज़ार जैसी 'मजबूरन मिलने वाली छुट्टी' गायब हो गई है, इसलिए दिमाग को जानकारी प्रोसेस करने और आराम करने का समय नहीं मिलता। जानबूझकर break लेना ज़रूरी है।

10. "tooling की संक्रमणकालीन समस्या" (भविष्य की दिशा)

• निदान: मौजूदा थकान इसलिए पैदा हो रही है क्योंकि AI की generation speed की तुलना में verification tools (tests, lint आदि) पीछे हैं।
• समाधान: अगर generation speed के बराबर verification को automate करने वाले tools विकसित हो जाएँ, तो थकान की समस्या हल हो सकती है।

1. फ़ॉर्मैट को लेकर पसंद-नापसंद ("क्या यह LinkedIn वाली vibe है?")

• आलोचना हावी: लगभग हर वाक्य के बाद लाइन ब्रेक देने वाले फ़ॉर्मैट को कई लोगों ने "LinkedIn influencer की ऊपर-ऊपर की स्टाइल वाली लिखाई" या "AI द्वारा जनरेट किया गया टेक्स्ट" जैसा कहकर कड़ी आलोचना की। इशारा यह था कि अंदर ठोस बात कम है, पैकेजिंग ज़्यादा शोर मचा रही है।
• कुछ समर्थन: कुछ लोगों का मानना था कि यह आज के लोगों की कम होती attention span को ध्यान में रखकर बनाई गई, पढ़ने में आसान संरचना है, या फिर काव्यात्मक लय को ध्यान में रखकर अपनाई गई शैली है।

2. 'गहरी इच्छा' को व्यवहार में उतारने के अनुभव

• सफल उदाहरण: sculpting, analog circuit design, postcard लिखना जैसी भौतिक और समय लेने वाली hobbies के ज़रिए उदासी से बाहर आने और जीवन को अधिक ठोस व घना महसूस करने के अनुभव साझा किए गए।
• ब्रेड बेकिंग बहस: मूल लेख में दिए गए "अक्षम ब्रेड बेकिंग" के उदाहरण पर engineers ने oven का उपयोग करके "fermentation time optimization" के टिप्स साझा किए, जिससे विडंबनापूर्ण ढंग से एक अलग sub-discussion शुरू हो गई।

3. दार्शनिक और धार्मिक स्रोतों का विश्लेषण

• पुरानी बुद्धि की rebranding: इसे बौद्ध धर्म के 'अतृप्त प्रेत (Hungry Ghosts)' जैसे विचार या पश्चिमी दर्शन के क्लासिक विषयों (Augustine आदि) को आधुनिक शब्दावली (Thin/Thick) में फिर से पैक करके पेश करना भर बताया गया।
• अंतर्दृष्टि की वैधता: यह नया विचार नहीं है, लेकिन आज के समाज के संदर्भ में इसे अच्छी तरह व्यवस्थित की गई अंतर्दृष्टि माना गया।

4. द्वैधवादी तर्क की सीमाएँ

• अवधारणा को ज़्यादा सरल बनाने से सावधानी: "consumption = सतहीपन, creation = गहराई" जैसी रूपरेखा को ख़तरनाक बताया गया। गहन reading (consumption) भी गहरी हो सकती है, और व्यावसायिक creation भी सतही हो सकता है।
• आराम का महत्व: यह भी कहा गया कि खोए-खोए रहना या games खेलना जैसी "ऊपर से सतही दिखने वाली" गतिविधियाँ भी recovery के लिए ज़रूरी आराम हो सकती हैं, लेकिन इस पहलू को नज़रअंदाज़ किया गया।

5. संरचनात्मक और पर्यावरणीय कारणों की ओर इशारा

• यह सिर्फ़ व्यक्ति की गलती नहीं: मूल समस्या वह dopamine reward system है जिसे IT कंपनियों ने जानबूझकर डिज़ाइन किया है।
• व्यावहारिक सीमाएँ: "हम पहले से समृद्ध हैं" जैसी धारणा पर आपत्ति जताई गई। घर के ख़र्च, medical cost और जीविका के ख़तरे (आर्थिक ग़रीबी) के कारण लोग सहजता से "गहरी इच्छा" का पीछा नहीं कर पाते—यह वास्तविकता भी सामने रखी गई।

क्या यह कुछ वैसा ही डिजिटल निरक्षरता वाला मामला नहीं है जैसे "सफेद हिस्सा code है और काला हिस्सा terminal"? जैसे logs पढ़ना नहीं आता या copy-paste के बिना बिल्कुल development नहीं कर पाना।

लगता है इस लेख की Part 1, "why senior engineers leave", और Part 2, "The Economic Intervention That Stops Engineer Attrition" भी हैं.

https://codegood.co/writing/…

कल भी मैंने एक Facebook पोस्ट देखी थी जिसमें कहा गया था कि Mac की पूरी storage खाली करवाना (Claude से कहकर कि वह खुद ही हटा दे) कितना सुविधाजनक है...

क्या इस लेख को executives तक पहुँचने से रोक नहीं सकते..

बहुत बढ़िया है

मैं ऐसी चीज़ें देखते समय बस टूल के system prompt की अहमियत देखता हूँ। अभी Cursor में इस्तेमाल करते समय, मेरी निजी राय में opus >= gpt 5.2 > gemini 3 है। इसके अलावा Sonnet हो या 5.1... मैं व्यक्तिगत रूप से अब उनका इस्तेमाल नहीं करता। हालांकि.. gpt5.2 में effort के हिसाब से फर्क काफी ज़्यादा होता है.. लेकिन हर बार high effort अच्छा ही हो, ऐसा भी नहीं है। इसलिए मैं मुख्य रूप से opus और gemini का इस्तेमाल करने लगा हूँ। कभी-कभी कोई मुश्किल समस्या आ जाए, तो मैं तीनों से coding करवाता हूँ, फिर उनसे एक-दूसरे के code का मूल्यांकन करवाता हूँ, और उसके बाद मैं खुद देखकर लागू करता हूँ।

लगता है बहुत से लोग --dangerously-skip-permissions को sandbox environment के बाहर चला रहे हैं। क्या उन्हें danger का मतलब नहीं पता...

इसमें एक भी गलत बात नहीं है।

हम्म, उल्टा मैंने ऐसे जूनियर भी देखे हैं जो खुद अजीब कोड लिखकर उस पर GPT ने किया था कहकर GPT को ढाल बना लेते हैं, तो मुझे लगता है यह व्यक्ति-व्यक्ति पर निर्भर करता है।

टूल्स का इस्तेमाल करने वाला agent वाकई खतरनाक है। बस इसकी बात ही सुनें।

सही कहा। मैं Windows 11 के बिल्ट-इन Notepad का ज़्यादा इस्तेमाल नहीं करता, इसलिए मुझे पता नहीं था। धन्यवाद।

बस Notepad में F5 दबाना है