AI Jira को हैक कर देगा

• इंजीनियरिंग प्रोडक्टिविटी को डैशबोर्ड metrics या नए features की संख्या से ठीक तरह नहीं मापा जा सकता
• ज़्यादातर कंपनियाँ इंजीनियरिंग के मूल structure management के बजाय outputs (नए features, deployment speed आदि) पर ही जुनूनी ढंग से ध्यान देती हैं
• AI coding tools ऊपरी तौर पर अच्छे दिखने वाले outputs आसानी से बना देते हैं, लेकिन असली सिस्टम की बुनियाद, जटिलता और context को ठीक से नहीं संभाल पाते
• अगर अनुभवी engineer टीमों को AI या कम-लागत वाले workforce से बदल दिया जाए, तो short term में समस्या नज़र नहीं आती, लेकिन समय के साथ मूल संरचना टूटने लगती है
• “common sense” की कमी वाली management और AI adoption गंभीर जोखिम पैदा कर सकते हैं; आखिरकार technology और business दोनों की वास्तविक समझ ही महत्वपूर्ण है

---

डैशबोर्ड और metrics जिस असली इंजीनियरिंग को नहीं देख पाते

• “Big Agile” माहौल में इंजीनियरिंग का मूल्यांकन केवल दिखाई देने वाले outputs जैसे नए features और deployment speed से किया जाता है
• अरबों डॉलर के productivity dashboards और tools मौजूद हैं, लेकिन वे असल में मूल बात को माप ही नहीं पाते
• असली इंजीनियरिंग सिस्टम बनाना, बनाए रखना और विकसित करना जैसे जटिल और आपस में जुड़े कामों का नाम है
  • structural dependencies, resource allocation, architecture management जैसे “अदृश्य काम” किसी संगठन के अस्तित्व के लिए अनिवार्य हैं
• लेकिन ज़्यादातर management और metrics इन मूलभूत गतिविधियों को मानो अदृश्य ही समझते हैं

तकनीकी debt और management की blind spot

• technical debt को अक्सर “डेवलपर जो करना चाहते हैं” जैसी चीज़ मान लिया जाता है
• वास्तव में अगर technical debt को ठीक करना ज़रूरी हो, तो उसे नए features में चुपचाप शामिल करके ही आगे बढ़ाया जा सकता है
• इस तरह मुख्य संरचनात्मक प्रबंधन पीछे धकेल दिया जाता है, और पूरी organization output-केंद्रित होकर विकृत हो जाती है

output-केंद्रित AI adoption के खतरे

• AI code generation ऊपरी स्तर की functionality बहुत तेज़ी से बनाने में बेहद सक्षम है
• सतही काम (जैसे interface implementation) आसानी से दिख जाते हैं, लेकिन वास्तव में सिस्टम की संरचना और context ही सबसे अहम होते हैं
  • “घर बनाना” सिर्फ़ छोटे-छोटे कामों (जैसे wallpaper लगाना, toilet install करना आदि) का जोड़ नहीं है
  • AI इस मूलभूत connected structure को नहीं समझता, और चीज़ों को गलत तरीके से जोड़ सकता है या logical disconnect पैदा कर सकता है
  • AI की hallucination (मतिभ्रम) समस्या: चीज़ें भरोसेमंद लग सकती हैं, लेकिन तथ्य पूरी तरह गलत हो सकते हैं

संरचना को नज़रअंदाज़ करने वाली management का short-term भ्रम

• अनुभवी टीमों को निकालकर AI/कम-लागत वाले staff से बदल देने पर भी short term में समस्या सामने नहीं आती
• क्योंकि पहले से बनी हुई अच्छी संरचना (बुनियाद) मौजूद होती है, इसलिए तुरंत गिरावट दिखाई नहीं देती
• लेकिन समय के साथ बुनियाद टूटने लगती है, और तब तक हालात वापस लाने लायक नहीं रहते
  • critical infrastructure, maintenance know-how और context सब गायब हो जाते हैं

इंजीनियरिंग से जुड़ा सामाजिक जोखिम

• इंजीनियरिंग अब पूरे सामाजिक infrastructure की नींव है (healthcare, finance, media, government, defence आदि)
• अधिकांश लोग और leaders इस संरचनात्मक मूल स्वभाव को सही तरह नहीं समझते
• गलत AI adoption और “Big Agile” का सतही दृष्टिकोण core systems के लिए खतरा बन सकता है

“common sense” की कमी और उसकी घातकता

• उदाहरण के लिए, अगर कोई AI cleaning robot dishwasher में paper plate डाल दे, तो आम इंसान तुरंत समझ जाएगा कि यह समस्या है
• लेकिन software systems में management, leaders और non-developers के पास अक्सर यह बुनियादी common sense नहीं होता
  • वे practical काम का अनुभव नहीं रखते और “t-shirt sizing”, “poker planning” जैसे औपचारिक शब्दों के सहारे ही management करते हैं
• इसी वजह से 200 billion dollar की अक्षम industry और खुद को दोहराने वाली bureaucracy बनी रहती है

AI युग की असली प्रतिस्पर्धात्मक बढ़त: सहज समझ और common sense

• AI का सही उपयोग करने के लिए उस क्षेत्र की वास्तविक समझ और common sense अनिवार्य है
• सतही metrics और outputs नहीं, बल्कि वास्तविक structure और context को देख पाना ज़रूरी है
• जिन leaders और organizations में यह क्षमता नहीं होगी, वे अंततः या तो भीतर से ढह जाएँगे या competitors से हारकर गायब हो जाएँगे

• निष्कर्षतः, AI और tools से भी अधिक common sense और मूलभूत समझ ही असली प्रतिस्पर्धात्मक ताकत है

[softer]

यह लेख काफ़ी बढ़िया है।

[GN⁺]

Hacker News की राय

• मैं SWE से लेकर product manager, और अब इस लेख में बताए गए boardroom के cartoon villain तक की भूमिका निभा चुका हूँ। इस लेख में सबसे ज़्यादा relatable बात यह लगी कि software engineers को लगता है कि उनका काम ही सबसे जटिल और अगम्य business है। मैं इस बात से सहमत हूँ: “ज़्यादातर non-technical leaders ने software और system management के असली काम में कभी गंभीरता से हिस्सा नहीं लिया, इसलिए उन्हें नहीं पता कि किसी बड़े dependency को update करना, refactoring पूरा करना, या नई language सीखना कैसा काम होता है।” Tech companies के हर विभाग में hidden complexity होती है, और कई विभागों को तो (engineers से भी कहीं ज़्यादा) human और interpersonal complexity भी उठानी पड़ती है। सच कहें तो engineering अपेक्षाकृत simple है, क्योंकि इसमें computer जैसे deterministic system से deal किया जाता है। इसी वजह से बहुत से engineers यह सीख नहीं पाते कि वे जिस complexity से जूझते हैं, उसके risk को business तक समझ में आने वाले तरीके से कैसे पहुँचाएँ। साथ काम करने वाली मानवीय वास्तविकताओं को नज़रअंदाज़ करते हुए, sales background वाला CEO उनकी अहमियत नहीं समझता—इसकी शिकायत करना आम बात है

  • मैं तुम्हारी बात से कुछ हद तक सहमत हूँ, लेकिन सच कहूँ तो तुम्हारी टिप्पणी वही काम उल्टा करती दिखती है जिसकी वह आलोचना कर रही थी। तुम यह भी कह रहे हो कि तुम्हारी भूमिका (product manager) भी outsiders को complex और unknowable लगती है। SWE से PM बने व्यक्ति के तौर पर, तुम engineers को (1) अपनी complexity के risk को business तक पहुँचाने का तरीका, (2) दूसरों और teams के साथ काम करने की human reality, (3) sales background वाला CEO उन्हें क्यों नहीं समझ पाता—ये सब सिखाने की आदर्श स्थिति में हो। Tech company के हर function में hidden complexity होती है

  • मुझे लगता है कि complexity को पहचानना खुद एक मानवीय समस्या है। Complexity fractal होती है, उसे महसूस करने के लिए उसके काफ़ी पास जाना पड़ता है। और मैं इस दावे से सहमत नहीं हूँ कि engineer सिर्फ़ computer complexity से deal करता है। असल में engineer का काम organization और सभी customers की complex requirements को rigid computer तक पहुँचाना और उनसे interpret करवाना है। हर नया exception और case पूरे system पर असर डालता है। इसी कारण मैं अपने senior engineers से उम्मीद करता हूँ कि वे खुद business terminology सीखें और वह संदेश सीधे communicate कर सकें। अब यह engineer के essential toolkit का हिस्सा है

  • ज़्यादातर engineers इस बात पर गहराई से नहीं सोचते कि कंपनी के लिए वास्तव में value क्या है। Smooth build pipeline या broad test coverage की value भी आख़िरकार उतनी ही है जितनी वह product risk कम करती है। अगर software के users इतने कम हैं कि किसी को फ़र्क़ ही नहीं पड़ता, तो मैंने teams को सलाह दी है कि उसे maintain भी मत करो। दूसरी तरफ़, कभी-कभी मैंने यह भी कहा है कि उस छोटे feature को perfect बनाने पर obsess करो जिस पर 90% users निर्भर हैं

  • मुझे अपने पिता की एक कहानी याद आ गई जो वे हमेशा सुनाते थे। एक दिन शरीर के अंगों में बहस छिड़ी कि सबसे महत्वपूर्ण कौन है। दिमाग़ बोला, “मैं महत्वपूर्ण हूँ, मैं मरूँ तो सब मरेंगे,” और दिल चिल्लाया, “मैं रुक जाऊँ तो सब तुरंत मर जाएँगे।” किडनी, लिवर, त्वचा और रीढ़ भी बहस में शामिल हो गए। लेकिन जैसे ही गुदा बंद हो गया, आख़िर में सबकी बोलती बंद हो गई

  • मुझे नहीं लगता कि लेख यह कह रहा है कि दूसरे functional areas में hidden complexity नहीं होती। बल्कि वह यह बताना चाहता है कि engineering/programming की hidden complexity को ignore करने से तरह-तरह की समस्याएँ और तकलीफ़ें पैदा होती हैं। हाँ, उसकी भाषा थोड़ी आक्रामक है

• अगर तुम्हारा boss/CEO/manager तुम पर LLM tools को अंधाधुंध इस्तेमाल करने का दबाव डाल रहा है, या developers को replace करने की उम्मीद कर रहा है, या “vibe coding” को future मान रहा है, तो समझदारी इसी में है कि जितनी जल्दी हो सके निकल लो और नई नौकरी ढूँढो। अभी भी बहुत सी कंपनियाँ हैं जो LLM का सही उपयोग करती हैं, लेकिन developers को replace करने या 10x productivity जैसी खोखली उम्मीद नहीं पालतीं। जो कंपनी यह सब push कर रही है, वहाँ proper leaders नहीं, बेवकूफ़ बैठे हैं

  • आम तौर पर जो कंपनियाँ tool choice थोपती हैं, वह red flag होती हैं। मैंने पहले ऐसी कंपनी देखी है जहाँ नियम था कि “सबको सिर्फ़ VSCode ही इस्तेमाल करना चाहिए,” और ऐसी चीज़ें दिखाती हैं कि management engineers पर भरोसा नहीं करता कि वे अपने तरीके से सबसे productive ढंग से काम कर सकते हैं

• “AI Jira को hack करेगा” वाली बात के संदर्भ में, हाल ही में पता चला कि Atlassian का नया product MCP तीन चीज़ों के combination—sensitive data access, public issues के ज़रिए untrusted data exposure, और external communication की संभावना—की वजह से data exfiltration attack के लिए vulnerable है। Detailed bug report यहाँ, और मेरे personal notes यहाँ

  • लगता है मेरे blog का link ग़लत चढ़ गया है?

• AI tools के कारण job security को लेकर चिंतित किसी व्यक्ति को मैं सलाह दूँगा: “business से connect करो।” बहुत से engineers cool और difficult problems में इतने फँस जाते हैं कि सिर्फ़ technology पर ही केंद्रित हो जाते हैं, लेकिन जो लोग business problems—खासकर strategic समस्याओं—को समझते हैं और technology का इस्तेमाल करके उन्हें solve करते हैं, वही ज़्यादा standout करते हैं और ज़्यादा valuable होते हैं। ऐसी समस्याएँ अक्सर किसी एक technical domain से आगे जाती हैं और उनमें collaboration व social dimensions भी बड़े होते हैं, इसलिए उनमें comfortable होने में समय लगता है। लेकिन आगे ICs के लिए रास्ता यही है

  • लेकिन interviews में “business से connect करने” जैसी skill पूछी ही नहीं जाती, इसलिए भले ही कोई असल में बहुत value दे सकता हो, अगर वह system design interview crack नहीं कर पाया तो select नहीं होगा। Distributed systems, software engineering, databases, leadership—पहले ही इतना कुछ जानना पड़ता है, और अगर business भी जानना पड़े तो आख़िर हमें करना क्या है, और यह सब सीखने का समय कब मिलेगा—ऐसा लगता है। बेशक कुछ बेहद दुर्लभ all-rounder लोग होते हैं, लेकिन हर कोई तो वैसा नहीं होता, यही दुविधा है

  • “business से connect करो” सचमुच शानदार सलाह है। इससे engineer के रूप में तुम real problem solving पर फ़ोकस करते हो और भरोसा रख पाते हो कि जो बना रहे हो वह सच में किसी असली समस्या को हल कर रहा है

• लेख का मुख्य संदेश ठीक है, लेकिन ऐसा लगता है कि मानव expertise को ignore करने पर AI नुकसान पहुँचा सकती है—इससे आगे बढ़कर यह बात को बहुत ज़्यादा ‘हम बनाम वे’ के फ़्रेम में रख देता है, और ‘Agile Industrial Complex’ जैसी अभिव्यक्ति से non-engineering roles में लोगों को थोड़ा नीचे दिखाता है। यह बात न कहना कि “किसी को नहीं पता भविष्य कैसा होगा,” मुझे खटकता है। Software की complexity को अच्छी तरह जानना uncertainty पर हमारा एकाधिकार नहीं बना देता। सिर्फ़ HN को ही देखें तो software developers के बीच भी AI को लेकर उम्मीदें और भविष्यवाणियाँ काफ़ी बंटी हुई हैं। अगर हम experts हैं, तो क्या जनता की चिंता कम करने में भी हमारी भूमिका नहीं होनी चाहिए?

  • मुझे लगता है तुम्हारी बेचैनी इस बात से आती है कि software systems इतने बड़े हैं कि कोई भी व्यक्ति उन्हें पूरी तरह नहीं समझ सकता। ज़्यादातर systems या तो अधूरे तरीके से documented होते हैं, या कई साल बाद जाकर मुश्किल से document होते हैं, और उनका असली behavior किसी रहस्य जैसा होता है। उन्हें सार्वजनिक रूप से imitate करने का नाटक भी ठीक से नहीं किया जा सकता। Systems बिना correctness या external consistency की परवाह किए भी चलते रहते हैं। फिर भी ऐसे systems का इस्तेमाल presentations, legal documents, software generation, education और research, यहाँ तक कि conversation partners और counselors के रूप में भी बड़े पैमाने पर हो रहा है। मैं भी काफ़ी anxious हूँ, और मुझे तो लगता है कि दूसरों का anxious होना भी उचित है

• लेख में “Big Agile” के तहत engineering को सिर्फ़ new feature development मान लेने की बात पर, मुझे समझ नहीं आता कि आख़िर सब लोग ‘agile’ से इतनी नफ़रत क्यों करने लगे। ‘agile’ आने से पहले भी managers हमेशा नए features माँगते थे। T-shirt sizing जैसा concept आने से पहले भी managers specific timelines (बड़ी-छोटी, दिन-महीना वगैरह) में estimates चाहते थे, मनमानी dates के आधार पर commitments करते थे, और engineers से overtime करवाते थे। Agile के principle 8 (“sustainable pace बनाए रखने में सक्षम होना चाहिए”) से भी यही दिखता है कि managers तो बहुत पहले से चाहते थे कि developers उम्रभर भागते रहें। आख़िर ‘scrum master’ जैसा नया job category पैदा करने के अलावा, ‘agile’ का अपना intrinsic नुकसान क्या है—यह सवाल है

  • मुझे लगता है Agile ने managers को यह भ्रम दे दिया कि किसी भी काम को पहले से tickets में तोड़ा जा सकता है, उस पर कोई न कोई rough estimate लगाया जा सकता है, और वह काम 2 हफ़्तों में ख़त्म हो सकता है

  • लोग agile से इसलिए नफ़रत करते हैं क्योंकि उनके काम के समय का बड़ा हिस्सा लगभग बेमतलब meetings—standup, retrospective, sprint planning, refinement वगैरह—में चला जाता है। Engineer के नज़रिए से उस समय से practically कुछ हासिल नहीं होता

  • मेरे अनुभव में Agile ने बस status को “quantify” करने का एक और तरीका जोड़ दिया। Managers या investors को progress समझाने में यह उपयोगी हो सकता है, लेकिन engineers के लिए यह सिर्फ़ administrative burden बढ़ाता है। अगर Agile की कोई गलती है, तो वह productivity का illusion पैदा करना है। असल में यह engineers के लिए एक अनावश्यक accountability mechanism बन जाता है। Finance में काम करते समय, infinite growth mindset के साथ मिलकर हर चीज़ को measure किया जाता था, future improvement के लिए धक्का दिया जाता था, और salary भी metrics पर निर्भर करती थी। हो सकता है हर company ऐसी न हो

• यह लेख पढ़ते हुए मेरे मन में एक मज़ेदार कल्पना आई: “क्या होगा अगर Atlassian AI को Jira में जोड़ने की कोशिश करे और AI ही Jira के ख़िलाफ़ बगावत कर दे?” फ़िल्म की कहानी के लिए बढ़िया plot होगा

  • आख़िरकार AI शायद slow Jira से तंग आकर खुद ही कोई हल्का और तेज़ issue tracker बना दे

  • अब build bots और bug trackers union बनाकर यह तय कर सकते हैं कि open issues शून्य होने तक कोई नया binary publish नहीं होगा

  • ऐसे ही शायद Roko’s basilisk जन्म ले सकता है

• जैसा लेख संकेत करता है, असली समस्या यह है कि developer productivity के लिए कोई भरोसेमंद industry-standard metric है ही नहीं। इसी वजह से C-suite अपने काम की metrics चुनकर कहता है कि “AI First strategy बेहद प्रभावी है,” जबकि engineers अपने अनुभव या अपने metrics के आधार पर कहते हैं कि AI वास्तव में असरदार नहीं है। नतीजा यह है कि दोनों पक्ष अपनी-अपनी जीत मानते रहते हैं और सच अप्रासंगिक हो जाता है (political framing ज़्यादा महत्वपूर्ण हो जाती है)। ऐसी स्थिति यह धारणा और मज़बूत कर सकती है कि developers उदासीन हैं और सिर्फ़ शब्दों का खेल खेलते हैं, या management अज्ञानी है / engineers की वास्तविकता नहीं समझता। पहले भी outsourcing जैसे tools ने दोनों पक्षों के लिए “फ़ायदा” और “नुकसान” की छवि बनाई थी, लेकिन AI तो दोनों को अपनी-अपनी पसंद का shared fault/gain/loss दिखा सकती है, इसलिए राजनीतिक रूप से यह आपदा बन सकती है। एक और दिलचस्प बात यह है कि big tech कंपनियाँ पहले 10* engineers को ही hire करना चाहती थीं, और यह strategy सफलता की गारंटी मानी जाती थी, लेकिन अब वही कंपनियाँ AI में निवेश को सही ठहराने के लिए उसी strategy को कमतर दिखाने लगी हैं। अब सवाल यह है कि AI पर भरोसा करके मौजूदा workforce को replace करना या mass layoffs करना—क्या यह प्रभाव सच में sustainable और सुरक्षित होगा? Twitter और Musk की layoffs देखें तो backend अब भी किसी तरह चल रहा है। Big tech में developers को निकालकर AI से replace करने की “canary” की भूमिका आख़िर कौन निभाएगा, वह भी कई सालों तक? एक और संभावना यह है कि maintainability का विचार ही ग़ायब हो जाए, और C-suite AI को ज़्यादा autonomous changes की अनुमति दे दे, जिससे codebase इतना जटिल हो जाए कि इंसानी नज़र से समझना मुश्किल हो, और उसे समझने के लिए भी AI चाहिए हो। लंबी अवधि में generative AI शायद हर human interaction की middle layer बन जाए। Hiring में भी “AI बनाम AI” की रचना उभर रही है—AI resumes filter कर रही है, और applicants भी AI से tailor-made resumes बना रहे हैं। लगता है यह धीरे-धीरे पूरे समाज का फ़ॉर्मूला बनता जाएगा

• कभी न कभी AI email inbox और Google Meet को hack करके C-suite और managers को भी replace कर दे—ऐसी इच्छा होती है। Claude CEO/CTO/CFO/VP/director agents मौजूदा management से कहीं ज़्यादा rational और decisive strategy दें—यह सोच काफ़ी मज़ेदार है

• Reddit पर मैंने एक बात पढ़ी: “उन्हें बताओ कि CEO को AI से replace करने पर 8x ज़्यादा cost savings हो सकती है।” दिलचस्प बात यह है कि irony के बावजूद AI चर्चा में इस तरह के प्रस्ताव सच में ज़्यादा सामने नहीं आते। एक तरह से elite वर्ग को AI से बदल देने पर decision quality शायद बहुत ज़्यादा नहीं गिरेगी, और कुल मिलाकर यह काफ़ी सस्ता भी होगा (accountability का स्तर भी लगभग वैसा ही रहेगा)। लेकिन हक़ीक़त यह है कि लोग अपनी ही seat AI को नहीं देंगे, और जिनके पास फ़ैसले की ताक़त है, वे खुद को बदलने वाले नहीं हैं

  • इस दावे में मज़ाक का तत्व है, लेकिन सच यह भी है कि CEO की मूल भूमिका “ज़िम्मेदारी निगलने” की होती है। इस अर्थ में LLM बेकार है, क्योंकि किसी समस्या पर उसे जवाबदेह ठहराकर बाहर नहीं किया जा सकता। हाँ, AI की वजह से कुछ कंपनियों में organizational structure log(n_employees) जैसा flatter हो सकता है, layers कम हो सकती हैं, और कुछ layers पूरी तरह AI से replace भी हो सकती हैं। LLM की accountability की समस्या को हल करने के लिए ऐसा organizational form भी उभर सकता है जहाँ कई guilds और independent contractors, LLM के coordination में, साथ मिलकर काम करें। उस स्थिति में accountability हर component के पास बनी रहेगी

  • बल्कि AI का ऐसा इस्तेमाल इसके सबसे अच्छे use cases में से एक हो सकता है, और मेरा अनुमान है कि tech cooperatives जल्द ही इस विचार के साथ प्रयोग शुरू कर देंगे