जब सभी के पास AI हो, फिर भी कंपनी कुछ न सीख पाए

 (robert-glaser.de)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कर्मचारियों की व्यक्तिगत AI उत्पादकता में बढ़ोतरी अपने-आप संगठन-स्तरीय सीख में नहीं बदलती, और असली खोजों का व्यक्ति से टीम और फिर संगठनात्मक क्षमता तक पहुँचना ही मुख्य चुनौती बन जाता है
  • AI अपनाने के जटिल मध्य चरण में Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor जैसे टूल्स का उपयोग व्यापक हो चुका है, लेकिन हर टीम में उपयोग की गहराई अलग है, और कुछ सीख छिपी रहती है, जिससे तुलना और प्रसार मुश्किल हो जाता है
  • बदलाव प्रबंधन के पारंपरिक तरीके जैसे कम्युनिटी, चैंपियन नेटवर्क, डेमो, सर्वे, डैशबोर्ड आदि, वास्तविक काम के दौरान पैदा होने वाले AI उपयोग के संदर्भ, विफलताएँ, सत्यापन और मानवीय हस्तक्षेप को पर्याप्त रूप से पकड़ नहीं पाते
  • Agentic engineering दोहराव की लागत घटाकर इरादे से प्रोटोटाइप और मूल्यांकन तक तेज़ी से पहुँचने देती है, लेकिन संगठन की Scrum, sprint और handoff प्रक्रियाएँ अब भी इस धारणा पर टिकी रह सकती हैं कि iterations दुर्लभ हैं
  • संगठनों को Agent Operations, Loop Intelligence और Agent Capabilities तीनों की साथ में ज़रूरत है; कर्मचारियों की निगरानी नहीं, बल्कि वास्तविक काम के loops को समझकर उन्हें दोबारा उपयोग योग्य क्षमताओं और तेज़ सीख में बदलने वाला feedback harness अधिक महत्वपूर्ण है

संगठन AI अपनाकर भी क्यों नहीं सीख पाते: जटिल मध्य चरण

  • Ethan Mollick के Leadership, Lab, and Crowd दृष्टिकोण के अनुसार, कर्मचारियों की व्यक्तिगत AI उत्पादकता अपने-आप संगठन-स्तरीय परिणाम नहीं बनती
    • कर्मचारी तेज़ लिख सकते हैं, अधिक विश्लेषण कर सकते हैं, automation कर सकते हैं, और “cyborg” की तरह काम कर सकते हैं, लेकिन कंपनी फिर भी लगभग कुछ नहीं सीख सकती
    • GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor जैसे टूल्स कंपनी के अंदर आ चुके हैं, और हर टीम में ऐसे लोग मौजूद हैं जो आधिकारिक training material से बहुत आगे हैं
    • प्रबंधन license उपयोग, prompts की संख्या, surveys, internal PoCs, steering committee की सामग्री देख सकता है, लेकिन वास्तविक सीख कहाँ हो रही है, यह साफ़ नहीं दिखता
    • कुछ कंपनियों में AI सीधे IT विभाग के हवाले कर दिया जाता है और फिर आगे बढ़त रुक जाती है
  • AI अपनाने का जटिल मध्य चरण वहाँ से शुरू होता है जहाँ AI का उपयोग व्यापक तो हो चुका होता है, लेकिन असमान, आंशिक रूप से छिपा हुआ, तुलना में कठिन और अभी तक संगठनात्मक सीख से जुड़ा नहीं होता
    • adoption की इकाई अब पूरा संगठन या शायद टीम भी नहीं रह जाती, बल्कि वास्तविक काम के अंदर मौजूद loop बन जाती है

सबके पास Copilot आने के बाद क्या होता है

  • AI अपनाने का पहला चरण पारंपरिक enterprise rollout जैसा दिखता है, इसलिए अपेक्षाकृत परिचित लगता है
    • seats खरीदी जाती हैं, acceptable use की सीमा तय की जाती है, training चलती है, champion network बनते हैं, और Teams channels में use cases साझा करने को कहा जाता है
    • ये channels थोड़ी देर सक्रिय रहते हैं, फिर अच्छे इरादों से भरे किसी corporate storage room जैसे बन सकते हैं
  • दूसरे चरण में, उसी कंपनी के भीतर AI उपयोग के तरीके बहुत अलग होने लगते हैं
    • कुछ टीमें Copilot को सिर्फ autocomplete के स्तर पर इस्तेमाल करती हैं
    • दूसरी टीमें Claude Code को testing, review और लगातार adjustment के साथ घने loops में चलाती हैं
    • product managers Figma screens बनाने के बजाय वास्तविक software का prototyping करने लगते हैं
    • senior engineers root cause analysis agents को सौंपकर 1 घंटे में उपयोगी समाधान पा लेते हैं, जबकि AI के बिना वही काम 2 हफ्ते ले सकता था
    • junior कर्मचारी polished code तो बना लेते हैं, लेकिन यह नहीं समझ पाते कि system में कौन-सी architectural assumptions घुस आई हैं
    • support teams दोहराए जाने वाले tickets को चुपचाप workflow automation में बदल देती हैं, और Center of Excellence से अधिक अच्छी तरह वास्तविक pain points जानती हैं
  • Mollick की रूपरेखा में leadership दिशा और अनुमति तय करती है, Crowd वास्तविक काम करता है इसलिए use cases खोजता है, और Lab उन खोजों को साझा practices, tools, benchmarks और नए systems में बदलता है
    • असली कठिनाई इस बात में है कि खोजें व्यक्ति से टीम तक, और टीम से संगठनात्मक क्षमता तक वास्तव में कैसे पहुँचें

पारंपरिक change management बहुत धीमा है

  • अधिकांश कंपनियाँ AI adoption को मौजूदा change management तंत्रों से संभालने की कोशिश करती हैं
    • communities of practice, lunch sessions, champion networks, enablement material, office hours, monthly demos, surveys, dashboards आदि का उपयोग होता है
    • जिन संगठनों में अभी experiment की अनुमति भी चाहिए, वहाँ ये तरीके मददगार हो सकते हैं
  • लेकिन दिलचस्प AI उपयोग अगले community meeting का इंतज़ार नहीं करता; वह वास्तविक काम के बीच में पैदा होता है
    • code review, sales proposals, research work, product prototypes, operational incidents, test strategy, compliance questions के भीतर यह उभरता है
    • कुछ खास product component types में “dark factory” जैसा pattern बन सकता है
      • इरादा लिखा जाता है
      • agent को ढीले loop में चलने दिया जाता है
      • पर्याप्त backpressure देकर उसे पटरी पर रखा जाता है
      • मजबूत scenarios से output का मूल्यांकन किया जाता है
      • इरादे को refine करके बार-बार उच्च गुणवत्ता वाले परिणाम निकाले जाते हैं
  • जो सीख वास्तव में उपयोगी थी, वह best-practice slides में बदलते ही अपनी धार खो देती है
    • क्योंकि असली मूल्य उस छूटे हुए context, असफल tests, अजीब API behavior और उस friction में था जहाँ agent बेतुकी दिशा में चला गया और इंसान ने उसे वापस मोड़ा
  • elastic loop दृष्टिकोण से AI collaboration कोई एकल mode नहीं है
    • यह घने, synchronous co-driving से लेकर ढीले, asynchronous delegation तक फैला हुआ है
    • अहम सवाल यह नहीं है कि “क्या लोग AI का उपयोग कर रहे हैं”, बल्कि यह है कि टीमों को किस आकार के loops चाहिए, कहाँ resistance चाहिए, कौन-से outputs loop के बाद भी बने रहने चाहिए, और वे outputs संगठनात्मक सीख में कैसे बदलें
    • यह tool usage या token count गिनने से कहीं कठिन प्रश्न है

Scrum इस धारणा पर बना था कि iterations महँगे होते हैं

  • आधुनिक software process का बड़ा हिस्सा इसलिए मौजूद है क्योंकि मानवीय iteration महँगा था
    • sprint planning, estimation, standups, user stories, ticket grooming, handoffs, coordination और risk reduction के लिए rituals इसमें शामिल हैं
    • जब एक iteration में कई दिन या हफ्ते लगते हों, तब बेकार iterations को रोकने वाली संरचना की ज़रूरत होती है
  • Agentic engineering iteration की economics बदल देती है
    • यह अधिक विकल्पों को वास्तव में बनाकर देखने योग्य बनाती है
    • यह intention से prototype और evaluation तक तेज़ी से ले जाती है
    • इससे product managers को काम करने वाला software पहले दिखाई देता है
    • engineers निर्णय लेने से पहले अधिक hypotheses जाँच सकते हैं
    • यह delivery को जादुई रूप से आसान नहीं बनाती, लेकिन constraints को implementation से हटाकर intention, validation, judgment और feedback की तरफ़ ले जाती है
  • कई संगठन 20 वर्षों से खुद को agile कहते रहे हैं, लेकिन agile जिन organizational reflexes को हटाना चाहता था, उन्हें बचाए रखा है
    • AI वास्तविक agility को अधिक संभव बना सकता है, लेकिन systems अब भी 2-week sprint commitments, handoff documents और ऐसी प्रक्रियाएँ मांगते हैं जो मानती हैं कि iteration दुर्लभ है
    • loops संगठन जितनी तेज़ी से उनसे सीख पचा सके, उससे भी तेज़ चल सकते हैं

AI usage cost संगठन को बेहतर सवाल पूछने पर मजबूर करेगी

  • AI उपयोग को कहीं अधिक स्पष्ट रूप से मापा जा सकेगा
    • आज का वह enterprise माहौल, जहाँ “सबके पास access है और cost की बहुत चिंता नहीं”, शायद लंबे समय तक न चले
    • model routing, token budgets, usage-based pricing, reasoning cost, और किस काम के लिए कौन-सा model अनुमति पाएगा, इस पर governance अधिक स्पष्ट हो जाएगी
  • महत्वपूर्ण प्रश्न यह नहीं है कि abstract रूप से token cost कैसे घटाई जाए
    • ठीक वैसे ही जैसे software delivery में अहम सवाल keypresses की संख्या कम करना नहीं था
    • बेहतर सवाल है: “इन tokens को खर्च करने से वास्तव में क्या बदला?”
  • pull requests गिनने जैसी माप से बचना चाहिए
    • कौन-से loops जल्दी बंद हुए
    • कौन-से decisions बेहतर हुए
    • कौन-सा root cause analysis अधिक सटीक हुआ
    • किस review ने अधिक समस्याएँ पकड़ीं
    • किस टीम ने reusable patterns सीखे
    • किस product idea की कमज़ोरी prototype की वजह से जल्दी उजागर हुई और उसे पहले ही छोड़ दिया गया
    • AI ने कहाँ सीख पैदा की, और कहाँ सिर्फ़ अधिक output पैदा किया
  • “tokens के मुकाबले output” पुरानी measurement reflex का नया रूप है
    • उससे अधिक महत्वपूर्ण माप tokens के मुकाबले सीख के करीब है

गायब feedback path के रूप में Loop Intelligence

  • AI adoption के जटिल मध्य चरण में कंपनियों को तीन क्षमताओं की ज़रूरत होती है

  • Agent Operations

    • कौन-से agents और AI tools चल रहे हैं, वे किन systems को छू सकते हैं, और कौन-सा data देख सकते हैं—यह सब manage करता है
    • किन actions के लिए approval चाहिए, identity, audit, permissions और runtime visibility कहाँ है—यह भी इसमें शामिल है
    • क्योंकि agentic work अंततः वास्तविक systems को छूता है, इसलिए control का पहलू महत्वपूर्ण है

  • Loop Intelligence

    • यह पहचानता है कि कौन-से AI-assisted या पूरी तरह agentic loops वास्तव में सीख पैदा कर रहे हैं
    • कौन-से loops खुले रह जाते हैं, कौन-से कमजोर पड़ते हैं, agent कहाँ leverage बना रहा है, और कहाँ भटक रहा है—यह सब देखता है
    • कौन-सी टीमें testing, context या judgment की कमी के कारण घनी supervision में बँधी हैं, और कौन-सी टीमें अधिक ढीली delegation के लिए तैयार हैं—यह समझता है

  • Agent Capabilities

    • उपयोगी capabilities को पूरे संगठन में deploy करता है, लेकिन यह मानकर नहीं चलता कि तीन विशाल agents सबका काम कर देंगे
    • AI एक single application category से ज़्यादा, एक fluid foundational technology की तरह व्यवहार करने लगता है
    • इसलिए enterprise zoo में एक-एक “HR agent”, “engineering agent”, “sales agent” रखने वाला मॉडल ठीक से फिट नहीं बैठता
    • capabilities को वहाँ बहना चाहिए जहाँ वास्तविक काम हो रहा है
      • employee harnesses
      • background agents
      • product teams
      • platform services
      • local skills
      • MCP servers
      • evaluation suites
      • runbooks
      • examples
      • domain-specific procedures

platform सवाल और feedback harness

  • platform स्तर पर सबसे महत्वपूर्ण सवाल है: उपयोगी capabilities का ownership और movement कैसे हो
    • किसी एक टीम द्वारा खोजी गई उपयोगी agent skill दूसरी टीमों तक ऐसे पहुँचे कि वह एक मृत template बनकर न रह जाए—इसके लिए तरीका चाहिए
    • developer harness, product manager harness, support team के background agents और compliance workflows—इन सबको अलग-अलग तरह से मजबूत करना होगा
    • कुछ capabilities टीम के करीब रहनी चाहिए, कुछ platform layer में, और कुछ को सामान्यीकृत नहीं करना चाहिए क्योंकि local context ही उनकी कुंजी है
  • तीन क्षमताओं में से केवल एक होने पर चीज़ें जल्दी अजीब हो जाती हैं
    • सिर्फ Agent Operations हो और Loop Intelligence न हो, तो यह control bureaucracy बन जाती है
    • सिर्फ Loop Intelligence हो और Agent Capabilities न हों, तो यह ऐसी analysis layer बन जाती है जो उपयोगी patterns तो पहचानती है, पर उन्हें वापस काम में नहीं ला पाती
    • सिर्फ Agent Capabilities हों और Operations व Loop Intelligence न हों, तो यह बेहतर branding के साथ tool sprawl बन जाता है
    • control path, learning path और capability path को कहीं न कहीं मिलना होगा
  • अंदरूनी तौर पर इसे feedback harness कहा जा सकता है
    • ग्राहक किसी elegant mechanism को नहीं खरीदते; वे confidence, बेहतर decisions, तेज़ learning, कम waste और सुरक्षित delegation खरीदते हैं
    • ग्राहकों के लिए अधिक उपयोगी शब्द Loop Intelligence Hub हो सकता है
  • feedback harness वास्तविक work loops को सुनने वाला तंत्र है
    • यह tasks, prompts, specs, reviews, scenarios, अपनाई या खारिज की गई hypotheses, operational signals, rework, मानवीय decisions और interventions को देखता है
    • इसका उद्देश्य लोगों की निगरानी नहीं, loops को समझना है
    • इसका पहला version किसी विशाल platform जैसा होना ज़रूरी नहीं
    • कुछ वास्तविक workflows चुनकर उन बिंदुओं को instrument करना काफ़ी है जहाँ intention, agent work, validation और human decisions पहले से निशान छोड़ रहे हों; फिर इतना qualitative feedback इकट्ठा करना कि समझा जा सके loop क्यों सफल हुआ या विफल, और उसे बार-बार उपयोगी learning outputs में बदला जा सके
  • Loop Intelligence Hub signals को संगठन के लिए actionable रूप देता है
    • enablement backlog
    • capability radar
    • investment briefs
    • governance gaps
    • reusable workflows
    • training needs
    • evaluation priorities
    • यहाँ one-size-fits-all dashboard नहीं, बल्कि relevance-आधारित outputs चाहिए
  • दिलचस्प output dashboard नहीं, बल्कि उसके बाद लिए गए decisions होते हैं
    • कुछ टीमों को अधिक delegation से पहले बेहतर backpressure चाहिए
    • कुछ product groups के पास संकीर्ण component types के लिए दोहराए जा सकने वाले dark factory patterns हैं
    • कुछ compliance workflows को governance-applied tool boundaries चाहिए
    • कुछ skills को platform पर ले जाना चाहिए क्योंकि पाँच टीमें उन्हें गलत तरीके से फिर-फिर बना चुकी हैं
    • harness इकट्ठा करता है, hub संगठन को निर्णय लेने में मदद करता है, और capability layer सीख को वापस काम में डालती है

यह अगर employee surveillance बन गया, तो विफल होगा

  • यदि यह ढाँचा employee scoring में बदल गया, तो पूरा सिस्टम ढह जाएगा
    • अगर कर्मचारी मानने लगें कि संगठन यह माप रहा है कि उन्होंने AI “काफी” इस्तेमाल किया या नहीं, तो वे signal को manipulate करेंगे
    • अगर उन्हें लगे कि हर experiment productivity expectation बन जाएगा, तो वे experiments छिपाएँगे
    • अगर उन्हें लगे कि सबसे अच्छा workflow जल्द ही नया default workload बन जाएगा, तो वे उसे निजी रखेंगे
    • कंपनी को adoption का सबसे खराब रूप मिलेगा: दिखाई देने वाला compliance और अदृश्य learning
  • उपयोगी सवाल यह नहीं है कि “कौन AI का पर्याप्त उपयोग कर रहा है”
    • बल्कि यह है कि AI ने कहाँ काम को ऐसे बदला कि संगठन उससे सीख सके
    • कौन-से loops अधिक स्वस्थ हुए
    • किन टीमों को अधिक delegation से पहले बेहतर backpressure चाहिए
    • अगर prototypes वास्तविक software बन रहे हैं, तो किन product teams को अलग environment चाहिए
  • policies ज़रूरी हैं, लेकिन governance भी learning की तरह उपयोग के ज़रिए ही वास्तविक बनती है
    • जब agents operations-निकट कामों को छूते हैं
    • जब product managers specifications लिखने के बजाय prototypes बनाते हैं
    • जब developers root cause analysis delegate करते हैं
    • जब token spend बढ़ता है और management जवाब चाहता है
    • तभी संगठन को पता चलता है कि उसने learning system बनाया है या सिर्फ़ बहुत सारी seats खरीदी हैं

जटिल मध्य चरण सिर्फ़ झेलने की चीज़ नहीं है

  • AI adoption का पहला चरण access के बारे में था
    • किसे tools मिलते हैं, किसे permission मिलती है, कौन contracts negotiate करता है, और कौन procurement tickets के बिना नवीनतम models आज़मा सकता है—यही अहम था
    • यह चरण अब भी महत्वपूर्ण है, लेकिन लंबे समय तक differentiation नहीं देगा
    • frontier intelligence तक पहुँच उधार ली जा सकती है, लेकिन operational control और organizational learning उसी तरह उधार नहीं लिए जा सकते
  • अगला advantage learning speed है
    • कौन वास्तविक patterns जल्दी खोजता है
    • कौन discoveries को व्यक्ति से टीम और टीम से संगठनात्मक capability तक ले जाता है
    • कौन agentic loops में backpressure डालकर agents को भटकने से रोकता है
    • कौन उपयोगी agent capabilities deploy करता है, बिना उन्हें सबके लिए एक विशाल enterprise agent में बदले
    • कौन AI को मौजूदा rituals के ऊपर चिपकाने के बजाय agentic engineering के ज़रिए agile को वास्तविकता के करीब लाता है
  • इस बदलाव को समझना मुश्किल है अगर कोई finalized adoption playbook का इंतज़ार करे
    • vendors, consultants और AI labs के अंतिम उत्तर की प्रतीक्षा करने के बजाय, वास्तविक काम को instrument करना, messy learning साझा करना, दूसरों को कमियाँ इंगित करने देना और खुलकर iterate करना ज़रूरी है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय

  • बड़े एंटरप्राइज़ माहौल में AI अपनाना लगभग डेवलपमेंट टीम के बाहर तक गया ही नहीं, और सिर्फ़ डेवलपर ही GitHub Copilot इस्तेमाल कर सकते हैं
    commit से production deployment तक code पहुँचने में 6~12 महीने लगते हैं, और development speed मूल bottleneck कभी थी ही नहीं
    समय infrastructure provisioning, testing, approvals, change management, deployment schedules जैसी प्रक्रियाओं में लगता है, और AI development के बाद वाले bottlenecks को और बदतर बना देता है, जिससे बदलाव release train के आगे जमा होने लगते हैं
    अगर बड़े एंटरप्राइज़ token cost पर ROI पाना चाहते हैं, तो उन्हें software को तेज़ी से deploy करना सीखना होगा, और deploy न किया गया code asset नहीं बल्कि liability है

    • management अब भी software को assembly line की तरह देखता है, और सोचता है, “Ford जैसे कार बनाती है, वैसे software बनाया जाता है”
      software development में inefficiency है, यह सही है, लेकिन असल बात code लिखना नहीं बल्कि यह पता लगाना है कि कौन-सा code लिखना चाहिए; यही investigation और design वाला हिस्सा है, जिसे ठीक से गिना ही नहीं जाता
      जब Microsoft चिल्लाता है “code 50% faster!”, तो management उसे “product भी 50% faster, और पैसा भी 50% faster” समझ लेता है
      जैसे ही ROI माँगा जाएगा, यह बहुत आसानी से आपदा बन सकता है, और अभी बस सब लोग measurement से बच रहे हैं
      किसी दिन investor कहेंगे, “2 million dollar खर्च किए हैं, तो 4 million dollar net profit दिखाओ,” लेकिन ऐसा नतीजा आना मुश्किल है
      Copilot और Claude पुराने organizational knowledge, undocumented special-case solutions, और future reuse potential जैसे असली bottlenecks हल नहीं करते
      code असली product भी नहीं है और असली काम भी नहीं; एक healthy codebase में यह design और investigation process का लगभग मुफ़्त byproduct होता है
      “procurement team को search इस्तेमाल करना मुश्किल लग रहा है” जैसी बात को practical ticket में बदल देने के बाद React search filter component लगभग पहले से तय होता है, और coding बस 10 मिनट की औपचारिक प्रक्रिया जैसी रह जाती है
      Copilot अगर उसे 5 मिनट कर भी दे, तो उससे पहले लगी 6 घंटे की meetings और calls के सामने यह खास प्रभावशाली नहीं लगता
    • बड़े एंटरप्राइज़ अभी तक यह बुनियादी बात भी नहीं सीखे कि कम code बेहतर होता है, इसलिए यह उम्मीद करना मुश्किल है कि वे अचानक software को तेज़ी से deploy करने जैसी अधिक उन्नत अवधारणाएँ सीख लेंगे
    • काफ़ी बड़े systems में एक बिंदु ऐसा आता है जहाँ अधिक code होना, वास्तव में ज़रूरी चीज़ के उलट हो जाता है
      nutrition और calories भी एक सीमा तक ही उपयोगी हैं; उसके बाद returns घटते हैं और अंततः नकारात्मक असर आने लगता है
      यह perfect analogy नहीं है, लेकिन यह समझने में मदद करती है कि ज़्यादा output देना भी कभी-कभी कम value पैदा कर सकता है
      एक ग्राहक से feedback मिला कि documentation पूरी और विस्तृत थी, लेकिन इतनी भारी थी कि overwhelm कर रही थी; अंत में समझ आया कि मुख्य बात बताने वाले कुछ छोटे bullet points 5 पन्नों के document से बेहतर हैं
    • यह बस पुरानी चीज़ का फिर से नया हो जाना है: Theory of Constraints का AI-युग संस्करण
      [0] https://en.wikipedia.org/wiki/Theory_of_constraints
      [1] https://www.goodreads.com/book/show/113934.The_Goal
      [2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
    • आज के बड़े एंटरप्राइज़ माहौल में AI अपनाना जैसे और भी बुरी दिशा में मुड़ गया है
      finance team ने आकर पूछा कि क्या वे Copilot, Cursor, Claude से financial planning app की vibe coding कर सकते हैं, और कारण यह दिया कि “CFO ने Lovable को test किया, भरोसा हो गया, और हमें app vibe coding से बनाने को कहा”
      उन्हें पता था कि management “CFO ने कहा है” सुनते ही जम जाता है, इसलिए वही तर्क आगे किया गया
      अंत में इस पर यह चमकदार पैकेजिंग भी चढ़ा दी गई कि “हमें देखना चाहिए कि क्या proper data security और maintainability वाली vibe-coded app enterprise finance domain में मौजूद हो सकती है”
      और भी चौंकाने वाली बात यह है कि यह reasoning 20 billion dollar से ज़्यादा annual revenue वाली कंपनी से आई

  • मेरे जैसे साधारण engineer के लिए कंपनी में AI इस्तेमाल करने का कोई ठोस फ़ायदा नहीं है
    कंपनी हमें धीरे-धीरे उबाल रही है, और HN के elite—investors, executives, celebrities, top engineers—कहेंगे, “innovation का विरोध कैसे कर सकते हो?”
    AI/LLM TCP/IP, Linux, Postgres जैसी innovation नहीं है
    Claude, Codex, Gemini, Grok जैसी चीज़ें profit के लिए मौजूद हैं; ये productivity की आख़िरी बूँद तक निचोड़ने और बाद में ज़रूरत न रहे तो लोगों को निकाल देने के औज़ार हैं
    अगर AI अच्छा लगता है, तो open source models इस्तेमाल करो और personal projects में करो

    • खेल ख़त्म नहीं हो रहा, बस बदल रहा है
      AI बहुत code उगल सकता है, लेकिन वास्तव में क्या हो रहा है यह समझने वाले engineers अब भी चाहिए, और वही हमेशा bottleneck था
      junior positions गायब हो सकती हैं, लेकिन senior engineers कुछ समय तक सुरक्षित दिखते हैं
      मैं खुद भी मूलतः विरोधी स्वभाव का हूँ, इसलिए यह कठिन सीखा हुआ सबक है: एक बार नौकरी पर हो, तो तुम्हें management जो चाहता है वह करने के लिए रखा गया है
      अगर विरोध करोगे, तो बस यही उम्मीद कर सकते हो कि उन्हें पता न चले या वे परवाह न करें; बड़ा बदलाव लाना मुश्किल है
    • फ़ायदा तो यह है कि काम बहुत आसान हो जाता है, नहीं? मुझे समझ नहीं आ रहा कि मैं क्या मिस कर रहा हूँ
    • यह कहानी तो है कि engineers का capitalists द्वारा शोषण होता है, लेकिन executive के नज़रिए से भी, “next quarter bonus” को छोड़ दें तो यह सब पागलपन जैसा लगता है
      पता नहीं किसी को याद है या नहीं कि SCO ने डूबते-डूबते industry के साथ क्या किया था
      अब भी समझ से बाहर है कि कंपनियाँ अपना secret information—code, processes, customer requirements, internal politics, leadership की योजनाएँ—startups और अविश्वसनीय बड़े vendors के हाथ क्यों सौंप रही हैं
      Microsoft भी कभी NDA और deal abuse के लिए बदनाम था
      मुझे नहीं लगता कि ये LLM giants enterprise material पर train नहीं करेंगे; और अगर करेंगे, तो उसके बारे में झूठ नहीं बोलेंगे—यह मानना भी मुश्किल है
      जब इनका पतन शुरू होगा, तो यह gold rush एक लंबी और बदसूरत tail छोड़ सकता है
    • Hacker News पर CEO कर्मचारियों के बारे में कैसे सोचते हैं और layoffs क्यों होते हैं, इस पर बहुत विकृत सोच दिखती है, और यह बहुत ख़राब व्याख्या है
      असल में जिनकी छँटनी होती है, वे वे लोग होते हैं जो ऐसी technologies नहीं अपनाते; इस तरह व्यवहार करके वे खुद को layoff zone में डाल देते हैं
      आज Coinbase का उदाहरण ही देख लो: जो लोग future नहीं अपनाते, उन्हें हटाया जा रहा है
      क्योंकि वे progress में मदद नहीं करते, आगे धक्का नहीं देते, और जो ऐसा करते हैं उन्हें भी रोकते हैं

  • इस लेख ने messy middle को बिल्कुल सही पकड़ा है
    जिन developers की अपनी responsibility और नौकरी दाँव पर लगी है, उनके पास ऐसे intelligence loops बनाने की प्रेरणा लगभग नहीं होती
    management चाहे जितनी विनम्रता से कहे, मेरी productivity gains को पूरी कंपनी के साथ मुफ़्त और निःस्वार्थ ढंग से बाँटने का मेरा कोई इरादा नहीं
    अगर कोई उपयोगी tool हो तो शायद साझा कर दूँ, लेकिन AI हैंडल करने या agent सेट करने का know-how, अगर sharing के बदले recognition नहीं मिलता, तो अपने पास रखना ही बेहतर है
    हमारी कंपनी ने adoption फैलाने के लिए “prompt of the week” award और lunch sessions बनाए हैं, और ऐसी flows बनाने वाली teams भी हैं
    लेकिन बिना वास्तविक monetary reward या job security के, ज्ञान फैलाने का risk और cost पूरी तरह developer पर ही गिरता है

    • मुझे समझ नहीं आता कि ज़्यादा लोग इस तरह क्यों नहीं सोचते
      AI के इस स्तर तक पहुँचने से बहुत पहले भी, मैंने अपना काम आसान करने और automation scripts लिखना सुविधाजनक बनाने के लिए personal CLI बनाया था
      सहकर्मियों ने वह tool देखकर उसे share करने को कहा, लेकिन मेरा कूटनीतिक जवाब दरअसल इनकार ही था
      share करने पर support burden आता, और सब लोग मेरे जितने productive हो जाते, जिससे मेरा advantage खत्म हो जाता—यानी negative return पैदा होता
      ऊपर से leadership मेरी creativity को asset मानती भी नहीं, इसलिए job security भी नहीं बढ़ती
      नज़दीकी भविष्य में वैसे भी layoff हो सकता है, तो भलाई दिखाकर कंपनी की मदद करने का मन नहीं होता
      अगर आज के market में developers नौकरी को लेकर चिंतित हैं, तो personal workflows को trade secret की तरह ट्रीट करना चाहिए
      यह उदाहरण सिर्फ़ AI तक सीमित नहीं है, लेकिन AI workflows पर भी बिल्कुल वैसे ही लागू होता है
      worker-favored market में ऐसा ज्ञान organization के साथ share करना कभी-कभी मज़ेदार था, लेकिन employer-favored market में अगर कोई मेरी personal edge तक पहुँचना चाहता है, तो पैसे देने होंगे
    • नौकरी को दुश्मनी से देखना अच्छा नहीं है, लेकिन जब तक कंपनी की सोच zero-sum वाली रहेगी—“सब लोग इतने productive हैं और इतना achieve कर रहे हैं, फिर इतने लोगों की ज़रूरत क्यों है?”—तब तक क्या किया जाए
      मैं नौकरी को परिवार नहीं मानता, लेकिन अच्छा होता अगर हम बिना इस डर के कि हम अपनी ही कब्र खोद रहे हैं, साथ काम कर पाते और चीज़ें साझा कर पाते
    • अगर employer आपसे उम्मीद करता है कि आप अपना समय मुफ़्त और निःस्वार्थ रूप से share करें, तो यह शोषण है
      ज़्यादातर लोगों को काम करने के लिए वेतन मिलता है, और काम के घंटों में स्वाभाविक रूप से employer के लिए काम करना चाहिए
    • जो छिपे हुए “secrets” बताए जाते हैं, वे ज़्यादातर Gary Tan की supercharged prompts list जैसी चीज़ों के स्तर के होते हैं
      सच तो यह है कि ऐसी बहुत कम बातें होती हैं जो बाक़ी लोग सोच ही न सकें
      मेरे अनुभव में prompts या techniques share करने पर या तो लोग उनका इस्तेमाल नहीं करते, या वे इतने बुनियादी होते हैं कि हर किसी के पास उनका अपना version पहले से होता है
      AI से पहले भी अगर किसी को xyz में दिलचस्पी नहीं थी, तो AI के बाद भी उसे चाँदी की थाली में परोस कर दे दो, फिर भी वह अचानक दिलचस्पी नहीं लेगा
    • एक दूसरा नज़रिया यह है कि AI tools शुरू में व्यक्ति को लाभ देते हैं, और user बढ़ी हुई productivity को खाली समय के रूप में अपने पास रख लेता है
      उबाऊ काम लगभग गायब हो जाते हैं, और कुछ समस्याएँ बस आगे बढ़ा देने से निपट जाती हैं, जिससे दिन के 1~4 घंटे वापस मिल जाते हैं
      क्या वह व्यक्ति समझदारी से उस समय का उपयोग करके और ज़्यादा काम खोजेगा? जब तक वह उसकी अपनी कंपनी न हो, या कोई विशेष प्रेरणा न हो, इसकी संभावना कम है

  • 3 साल से retired system analyst होने के नाते मुझे युवा सहकर्मियों के लिए अफ़सोस होता है
    2023 में मैंने टीम में अपेक्षाकृत जल्दी AI इस्तेमाल किया और Perl-आधारित legacy code को समझ निकाला, जिसके मूल लेखक बहुत पहले जा चुके थे और लगभग कोई comments या documentation छोड़कर नहीं गए थे
    वह code महत्वपूर्ण काम करता था, और AI ने मुझे मुश्किल से बाहर निकाला, इसलिए सब लोग इस नई technology से प्रभावित थे
    लेकिन समय के साथ यह मुझे ऐसे tool से ज़्यादा लगने लगा, जिसे मैं इस्तेमाल कर रहा हूँ, और ज़्यादा ऐसा जिसे मुझ पर इस्तेमाल किया जा रहा है
    किसी ने यह माँगा नहीं था
    पता नहीं “सब कुछ तुरंत कर देने” के नाम पर inspiration और thought कब से devalue होकर worthless हो गए; काम से आत्मा ही निकल गई है

  • AI अपने आप में इतना उपयोगी नहीं है
    agents भूल जाते हैं और पर्याप्त गलतियाँ भी करते हैं, इसलिए हर काम verify करना पड़ता है, और नतीजतन productivity उल्टा कम भी हो सकती है
    असली ताकत तब दिखती है जब AI को दूसरे tools बनाने वाले tool की तरह इस्तेमाल किया जाए
    जैसे उससे ऐसे tools बनवाना जो किसी task को तब तक चलाते रहें जब तक वह एक खास quality तक न पहुँच जाए, या output पर compliance checks चलवाना ताकि पता चले कहाँ सुधार चाहिए
    तभी जाकर काम पर भरोसा किया जा सकता है
    अभी ज़्यादातर roles और workflows इस तरह डिज़ाइन हैं कि दिए गए tools से कोई खास काम पूरा किया जाए, और ऐसे सिस्टम में AI सिर्फ़ किनारों से ही घुस पाता है

  • यह अच्छा लेख है, और खास तौर पर यह बात उभरकर आई कि संगठन काम को परिभाषित करने का तरीका बदल रहे हैं
    पुराने मॉडल में performance और OKR, functional area, title और role-specific expectations से बंधे थे
    AI युग में ये सीमाएँ टूटने लगी हैं
    गहरी समस्या psychological और organizational है: लोग “यह मेरा काम है” और “यह मेरी ज़िम्मेदारी नहीं” के बीच की रेखा पर लगातार मोलभाव करते रहेंगे
    इसलिए adoption का असली सवाल यह बनता है: AI power user के रूप में साफ़-साफ़ पहचाने जाने का फ़ायदा क्या है?
    अगर कंपनी recognition, rewards और career growth के लिए साफ़ व्यवस्था नहीं बनाती, तो जब उन्हें पता चले कि मैं तेज़, बेहतर और functions के पार जाकर काम कर सकता हूँ, तो मैं यह क्यों दिखाऊँ?

    • आख़िरकार ownership उसी के पास जाता है जिसकी ज़िम्मेदारी operational failures को ठीक करने और maintenance करने की होती है
      agents के इन boundaries को cross करने वाली दुनिया में यह काफ़ी messy हो सकता है
      क्या AI engineer जो agents की पूरी फ़ौज चलाता है, हर चीज़ को चालू रखने की ज़िम्मेदारी भी लेगा? इस पर काफ़ी शक है, लेकिन देखना होगा
    • अगर AI power users को reward करने के लिए framework बनाया जाता है, तो वही career खुद समस्या बन सकता है
      कोई व्यक्ति अगर उस नए काम की ओर आकर्षित हो, और company-specific context पर सलाह में कुछ हफ़्तों की ताज़ा approaches जोड़ दे, तो अंततः वह खुद हटाए जाने वाले domain expert की भूमिका में आ सकता है
    • अगर कोई team member इन चीज़ों को default की तरह करना शुरू कर दे, तो वह तब तक ठीक है जब तक उस व्यक्ति और बाकी टीम के बीच का gap खुलकर सामने नहीं आ जाता

  • “पिछले साल Anthropic को दिए गए 2 million euro का ROI कहाँ है?”—इसका जवाब CEO office में टंगा YouTube-style platinum token plaque है

  • “पिछले साल Anthropic को दिए गए 2 million euro का ROI कहाँ है?” इस सवाल के पीछे छिपी धारणा का bias वाक़ई बेहूदा है
    समस्या यह है कि generative AI कोई दिखने लायक ROI पैदा नहीं कर पा रहा
    लेकिन “समाधान” यह बताया जाता है कि पूरी development organization को उसी technology के इर्द-गिर्द फिर से सजाओ और नए tools invent करो
    ऐसे लेखों का असली मक़सद ऊपर-ऊपर जिस चीज़ पर बात हो रही है वह नहीं, बल्कि उन assumptions को normalise करना है जिन पर वह बहस टिकी है

    • जैसे LLM असफल हो ही नहीं सकते, और अगर असफल होते हैं, तो सिर्फ़ इसलिए कि आपने उन्हें असफल किया

  • इस क्षेत्र में अभी काम करना सच में बहुत खराब है
    जिस कंपनी में मैं हूँ, वहाँ managers ने non-developers तक सबको AI इस्तेमाल करने दिया है
    मेरा सच में मन है कि नौकरी छोड़ दूँ और किसी दूसरे क्षेत्र में चला जाऊँ, लेकिन जहाँ मैं रहता हूँ वहाँ entry-level salary पर किराया नहीं चल सकता, और मेरी उम्र भी बढ़ रही है

  • AI के वादे को dot-com boom से तुलना करके देखना समझने में मददगार लगा, और समानताएँ भी बहुत हैं
    लेकिन enterprise के नज़रिए से internet कहीं ज़्यादा सरल विचार था
    मूल रूप से उसका मतलब यह था कि अब लोग अपने computer से सामान खरीद सकते हैं
    AI का वादा क्या है? क्या यह कि चीज़ों के बारे में reasoning को approximate किया जा सकता है?
    यह implementation के स्तर पर सचमुच कहीं ज़्यादा कठिन puzzle है
    coding tasks के बाहर अभी तक मुझे कोई वास्तविक ठोस चीज़ दिखाई नहीं दी