AI ने coding को आसान बनाया। लेकिन engineering और कठिन हो गई

• AI tools के प्रसार से code लिखना आसान हुआ है, लेकिन software engineers के काम की तीव्रता और जटिलता उलटे बढ़ गई है
• AI ने productivity बढ़ाई तो organizations की expectations और workload baseline भी ऊपर चली गई, और engineers पर अब ज़्यादा काम कम समय में करने का दबाव है
• code writing-केंद्रित पहचान कमजोर पड़ने के साथ engineers को review, design, product thinking जैसे non-development काम भी संभालने पड़ रहे हैं
• AI द्वारा बनाए गए code को review और debug करने में ज़्यादा समय लग रहा है, जिससे quality control का बोझ और cognitive load बढ़ रहा है
• टिकाऊ engineering culture के लिए leadership की सहानुभूति, role boundaries तय करना, junior talent को विकसित करना, और नए evaluation metrics अनिवार्य हैं

---

baseline का खिसकना और अदृश्य बोझ

• AI अपनाने के बाद engineers से अपेक्षित output तेज़ी से बढ़ा है, और बिना स्पष्ट निर्देश के भी उनसे अधिक काम की उम्मीद की जा रही है
  • Harvard Business Review के शोध के अनुसार, AI का उपयोग करने वाले कर्मचारी जल्दी घर नहीं जाते, बल्कि और अधिक काम करते हैं
  • 83% ने कहा कि AI की वजह से उनका workload बढ़ा, और burnout rate practitioners में 60% से अधिक था, जबकि management में यह 38% था
• जहाँ leadership को लगता है कि “AI काम को आसान बनाता है”, वहीं मैदान में काम कर रहे engineers जटिलता और थकान महसूस कर रहे हैं
• 600 से अधिक लोगों पर किए गए एक अलग सर्वे में भी दो-तिहाई ने burnout का अनुभव बताया, और 43% ने कहा कि leadership को ज़मीनी हक़ीक़त का पता नहीं है

engineer identity का संकट

• कई engineers ने अपने पेशेवर संतोष का स्रोत खुद code लिखने की रचनात्मक प्रक्रिया को माना है
• लेकिन AI आने के बाद “खुद code मत लिखो, उसे manage करो” जैसा एक मौन संदेश फैल गया है
  • implementation अब AI कर देता है, और engineer की भूमिका supervisor और reviewer की ओर खिसकती है
• यह सिर्फ़ एक साधारण बदलाव नहीं, बल्कि पेशेवर पहचान का बुनियादी परिवर्तन है, जिससे कुशल तकनीकी लोगों का गर्व कमज़ोर पड़ता है
• “builder से inspector बन गए” जैसी भावना के साथ output बढ़ा है, लेकिन craftsmanship और immersion कम हुए हैं

role expansion और scope creep

• AI की वजह से implementation तेज़ हुई तो bottleneck requirements, architecture, testing, deployment जैसे आसपास के कामों में चला गया
• organizations इन कामों को engineers में बाँट रही हैं, और अब उन्हें product planning, risk assessment, operations management भी संभालना पड़ रहा है
  • Harvard Business Review के शोध में भी role boundaries धुंधली होने और PM, researcher, engineer के कामों के आपस में मिलने की बात सामने आई
• engineering roles में से 45% को multi-disciplinary capabilities चाहिए, लेकिन इसके साथ compensation या authority में बढ़ोतरी नहीं होती
• नतीजतन काम का दायरा बढ़ता है और गहराई घटती है, जिससे burnout और तेज़ होता है

supervision का paradox: AI code review की कठिनाई

• एक paradox पैदा हुआ है कि AI-generated code को review करना, खुद code लिखने से भी कठिन हो सकता है
  • जो व्यक्ति code लिखता है, उसे context पता होता है, लेकिन AI code में decision-making का आधार साफ़ नहीं होता, इसलिए review का बोझ बढ़ जाता है
• Harness के सर्वे में 67% ने debugging time बढ़ने और 68% ने review time बढ़ने की बात कही
• management speed improvement की उम्मीद करता है, लेकिन व्यवहार में quality assurance और context understanding का बोझ बढ़ जाता है
• production bottleneck writing stage से understanding stage में चला जाता है, और इसे automation से हल नहीं किया जा सकता

acceleration का जाल और sustainability

• AI ने speed बढ़ाई तो workload के अपने-आप बढ़ते जाने वाला self-reinforcing loop बन गया
  • Harvard के शोध ने इसे “workload creep” कहा, जहाँ लोगों को पता भी नहीं चलता और overwork जमा होता जाता है
• पहले इंसानी सोचने और typing की speed एक स्वाभाविक सीमा थी, लेकिन AI ने वह सीमा हटा दी
• नतीजतन productivity metrics ऊपर जाते हैं लेकिन quality गिरती है, और technical debt व थकान बढ़ती जाती है
• ऊपर से यह productivity gain जैसा दिखता है, लेकिन अंदर ही अंदर exhaustion और quality decline चल रहा होता है

junior engineers की learning में टूटन

• AI साधारण काम संभालने लगी है, जिससे entry-level engineers के hands-on practice के मौके तेज़ी से घट रहे हैं
  • 2023~2024 में बड़ी tech companies में entry-level hiring 25% घटी, और HackerRank की report ने भी experienced hires पर ज़ोर की पुष्टि की
• अगर learning के लिए आसान tasks ही गायब हो जाएँ, तो भविष्य के senior talent को तैयार करने का रास्ता टूट जाएगा
• “जिस system को आपने खुद कभी बनाया ही नहीं, उसकी निगरानी नहीं कर सकते” जैसी चेतावनी के साथ बुनियादी क्षमता में टूटन को लंबे समय का ख़तरा बताया गया है

leadership को क्या करना चाहिए

• बदलाव की कठिनाई को सहानुभूति के साथ समझना और खुलकर स्वीकारना भरोसा बनाए रखने की शुरुआत है
• व्यावहारिक reskilling देना ज़रूरी है: system design, security, product thinking, AI code evaluation जैसी advanced skills को मज़बूत करना
• role scope को स्पष्ट करना और compensation समायोजित करना, ताकि अनंत विस्तार को रोका जा सके
• performance metrics को फिर से परिभाषित करना: speed और lines of code से ज़्यादा quality, stability और team health को महत्व देना
• junior hiring बनाए रखना लंबे समय के talent ecosystem को बचाने के लिए आवश्यक है

engineers अपने स्तर पर क्या रणनीति अपनाएँ

• बुनियादी technical skills को बनाए रखें: architecture, debugging, performance और security की समझ अब और भी महत्वपूर्ण है
• acceleration trap से सावधान रहें: AI जितनी अधिकतम speed दे सकता है, उसे हर हाल में पाने की कोशिश न करें; एक sustainable rhythm रखें
• विस्तारित roles में जिन क्षेत्रों में रुचि हो उन्हें अपनाएँ, और उन्हें career growth के अवसर की तरह इस्तेमाल करें
• burnout और अलगाव की भावना साझा करें, ताकि साथियों के साथ बातचीत से वास्तविक स्थिति की समझ बढ़े
• तकनीकी बदलाव बार-बार आते रहे हैं, और AI भी मूलभूत technical talent की ज़रूरत को समाप्त नहीं कर सकता

हमारे सामने खड़ा paradox

• AI ने coding को आसान बनाया है, लेकिन engineering को कठिन बनाया है — यह वास्तविकता एक साथ मौजूद है
• expectations में वृद्धि, roles का विस्तार, और support की कमी मिलकर एक अस्थिर और टिकाऊ न रहने वाली culture बनाते हैं
• अगर इस paradox को स्वीकार नहीं किया गया, तो trust और talent retention दोनों असंभव हो जाएँगे
• हमें यह नहीं भूलना चाहिए कि products tools नहीं, लोग बनाते हैं, और
  AI युग में असली प्रतिस्पर्धात्मक क्षमता उसी organization से आएगी जो इंसानी सीमाओं को समझे और उनकी रक्षा करे

[tested]

संज्ञानात्मक कर्ज़: जब गति समझ से आगे निकल जाती है

[GN⁺]

Hacker News की राय

• यह निबंध आंशिक रूप से AI-generated लगता है, या कम से कम LLM से काफ़ी भारी संपादन किया गया दिखता है
  “It’s not X, it’s Y” जैसी वाक्य संरचना बार-बार दोहराई गई है, और 2015~2025 के बीच लगभग निष्क्रिय रहे ब्लॉग का अचानक बहुत तेज़ी से पोस्ट करना शुरू कर देना भी संदिग्ध लगता है

  • अब LLM पर लिखी जाने वाली लगभग सारी पोस्टें या तो सीधे LLM से लिखी हुई लगती हैं या उसकी मदद से
    यह लेखन शैली बहुत से लोगों को उबा देती है, लेकिन इंडस्ट्री में सफल होना चाहने वाले लोगों को शायद इससे फ़र्क नहीं पड़ता
  • मैंने भी LLM की मदद से निजी लेखन करने के अनुभव से देखा है कि यह लेख कुछ bullet points से जनरेट किया हुआ लगता है
    इसका दोहराव वाला रिद्म और स्टाइल एक सामान्य LLM आउटपुट जैसा है। इसमें मानवीय भावना कम है और सामग्री खोखली लगती है
  • टिप्पणियों में भी AI के निशान दिखते हैं। मैं ठोस संकेत नहीं बताऊँगा, लेकिन HN धीरे-धीरे पढ़ने में मुश्किल जगह बनता जा रहा है
    अब समय है कि अभी तक AI से कम प्रभावित छोटी लेकिन उच्च-गुणवत्ता वाली communities को संजोकर रखा जाए
  • शीर्षक से ही LinkedIn-स्टाइल सनसनीखेज़ लाइन की गंध आ रही है
  • मैंने भी कुछ पैराग्राफ पढ़कर दिलचस्पी में इसे सहकर्मी के साथ साझा करने का सोचा था, लेकिन जल्द ही यह इतना साफ़ हो गया कि इसे AI ने लिखा है कि मैं इसे गंभीरता से नहीं ले सका

• “The job changed. The expectations changed. And nobody sent a memo.” जैसी पंक्ति सच में AI द्वारा लिखी हुई लगती है

  • लेख बहुत ज़्यादा शब्दाडंबर वाला था, जबकि उसका सार कुछ bullet points में समेटा जा सकता था। बीच में बोर होकर पढ़ना छोड़ दिया
  • समझ नहीं आता AI इतना खराब लिखता क्यों है। इसकी शैली किसी clickbait न्यूज़ आर्टिकल जैसी लगती है
  • Pangram के अनुसार यह लेख 100% AI-generated है
  • कुल मिलाकर इसमें AI की विशिष्ट लेखन शैली साफ़ महसूस होती है

• मैंने जो असली समस्याओं में से एक देखी है, वह AI deployment की गलती है। ‘Vibe Coders’ जैसे लोगों को IT/Dev mentor की ज़रूरत है
  उदाहरण के लिए, एक सर्जन ने Claude से ऑपरेशन रिकॉर्ड के लिए एक web app बनवाया, और सुरक्षा को लेकर चिंतित होकर मुझसे उसकी समीक्षा करने को कहा
  कोड और DB तो ठीक थे, लेकिन उसने पूरे प्रोजेक्ट को zip में पैक करके web root पर डाल दिया था और index फ़ाइल नहीं थी
  इसलिए कोई भी बैकअप फ़ाइल डाउनलोड कर सकता था, और उसके अंदर DB, API keys, AWS keys समेत सारे secrets मौजूद थे
  उसे यह तक नहीं पता था कि index फ़ाइल क्यों होती है, और आखिर में उसने कहा कि वह Claude से ही पूछेगा कि इसे सुरक्षित कैसे बनाया जाए

  • लगता है ऐसी कमजोरियाँ जल्द ही इतनी आम हो जाएँगी कि nation-state attackers भी इन्हें ऑटोमेट करके exploit कर सकेंगे
    कुछ महीनों में script kiddies भी इसे बड़े पैमाने पर इस्तेमाल करेंगे, और कोई इसका उपयोग करके swatting की कोशिश कर सकता है जिससे जान-माल का नुकसान हो सकता है
    तब ज़िम्मेदारी पर बहस कैसी होगी, यह सोचने वाली बात है
  • Claude कोडिंग में वाकई बहुत अच्छा है, लेकिन ‘जो नहीं जानते कि वे क्या नहीं जानते’ ऐसे लोगों का हाथ पकड़कर नहीं चलाता

• “ज़्यादातर engineers को code लिखना पसंद है” — यह बात मुझ पर लागू नहीं होती
  मुझे code लिखने से ज़्यादा कुछ डिज़ाइन करना और बनाना दिलचस्प लगता है
  AI के पक्ष या विपक्ष में होना आख़िरकार शायद इस फ़र्क पर आ टिकता है कि “क्या तुम्हें coding पसंद है, या दुनिया के लिए products बनाना पसंद है”

  • मैं यह काम high-quality software बनाने के लिए करता हूँ
    लेकिन AI अभी उस स्तर तक नहीं पहुँचा है। वह अक्सर ऐसा code देता है जो compile भी नहीं होता, और अगर वह ठीक से चलता ही नहीं तो optimization का कोई मतलब नहीं

• बहुत-सी टिप्पणियाँ इस लेख को AI-लिखित कहकर आलोचना कर रही हैं, लेकिन 30 साल से ज़्यादा programming और 20 साल टीम lead करने के अनुभव से मुझे इसमें गहरी insight महसूस हुई
  लेखक कोई भी हो, मुझे इसकी बातों में मूल्य दिखा। इसका flag होना उल्टा आश्चर्यजनक लगा

  • मुझे AI-generated लेखन से अपने आप में आपत्ति नहीं है। लेकिन लेखन प्रक्रिया में transparency ज़रूरी है
    उदाहरण के लिए, “मैंने fintech टीम चलाते हुए यह महसूस किया” जैसी बात अगर असली अनुभव पर आधारित नहीं है, तो उसका महत्व खत्म हो जाता है
    लेकिन अगर वास्तविक अनुभव को AI से polish किया गया हो, तो उसमें कोई समस्या नहीं
  • अच्छा होता अगर लेख बनाने वाला prompt सार्वजनिक करता। जैसे executable से ज़्यादा source code देखना चाहें
  • आख़िरकार flag हट गया, लेकिन ऐसा ‘AI slop’ बना रहे और आलोचनात्मक पोस्टों को राजनीतिक कहकर रोका जाए, तो यह HN की priorities की समस्या लगती है
    “AI से बचा नहीं जा सकता” जैसी घिसी-पिटी पंक्तियों में अब कोई बुद्धिमत्ता नहीं बची

• AI के दौर में engineering mindset बदल रहा है
  पहले समस्या में गहराई तक उतरने वाली vertical सोच ज़रूरी थी, अब horizontal और meta-level thinking की ज़रूरत है
  उदाहरण के लिए, Claude environment को optimize करने के लिए मैं documentation पढ़ रहा था, लेकिन फिर मैंने बस Claude को project context दिया और optimization के लिए कहा
  उसने ज़रूरी plugins और agents अपने आप सुझा दिए और बना भी दिए
  आख़िर में महत्वपूर्ण चीज़ implementation details नहीं, बल्कि project की संरचना परिभाषित करने की क्षमता है

• लेख का मूल बिंदु सही है। automation आसान कामों को हटा देती है और हमें मुश्किल समस्याओं पर ध्यान लगाने को मजबूर करती है
  calculator का उदाहरण लें, तो पहले अंकों को जोड़ने में माहिर accountant को अब उससे ऊँचे स्तर की समस्याएँ संभालनी पड़ती हैं

  • असली बात यह है कि “आसान हिस्सा गायब हो गया।” कठिन काम अभी भी कठिन है, और वही असल काम है
  • मुझे coding से ज़्यादा system design दिलचस्प लगता है। अगर AI या junior developer implementation संभालें और मैं design पर ध्यान दूँ, तो वह आदर्श स्थिति होगी
    लेकिन beginners के लिए coding का गायब हो जाना शायद एक दुःस्वप्न हो सकता है
  • उल्टा AI कठिन हिस्से नहीं हटाता, बल्कि low-quality content की बाढ़ ला देता है
    साहित्य में कहें तो AI नया Terry Pratchett जल्दी नहीं बनाता, बल्कि यह सुनिश्चित करता है कि वह दब जाए
    अगर आप AI blog post को पहचान नहीं सकते, तो शायद खराब code भी नहीं पहचान पाएँगे
  • Pangram के अनुसार यह लेख भी 100% AI-generated है
  • असल में बड़ी समस्या यह है कि नौकरी ढूँढ़ना कठिन होता जा रहा है, और entry-level developers अंदर घुस ही नहीं पा रहे

• मैं हमेशा नहीं पहचान पाता कि कोई लेख LLM ने लिखा है या नहीं, लेकिन आजकल ऐसी चीज़ें पढ़ते हुए मानसिक थकान बहुत होती है
  शब्द बहुत ज़्यादा होते हैं, और ADHD प्रवृत्ति वाले लोगों के लिए इसे पढ़ना खास तौर पर मुश्किल है

• Pangram रिकॉर्ड के अनुसार यह लेख 100% AI द्वारा लिखा गया है

  • लेकिन ज़्यादातर AI लेखन पहचानने वाले tools accurate नहीं होते
  • यही बात इसे और भी विडंबनापूर्ण बना देती है

• कुछ शोध यह भी कहते हैं कि LLM का उपयोग productivity बढ़ाने में नहीं बदलता
  ऐसे लेख इस प्रभाव को मानो पहले से तय सच मान लेते हैं, लेकिन हक़ीक़त में management की उम्मीदें और ground reality अलग होती हैं
  engineer के नज़रिए से देखें तो यह अंतर साफ़ दिखता है