दो तरह के AI उपयोगकर्ता उभर रहे हैं, और उनके बीच का अंतर चौंकाने वाला है

• AI उपयोगकर्ताओं के बीच प्रोडक्टिविटी गैप तेज़ी से बढ़ रहा है, जहाँ ‘पावर यूज़र्स’ Claude Code, MCPs जैसे उन्नत AI टूल्स का सक्रिय रूप से उपयोग कर रहे हैं, जबकि अधिकांश लोग अब भी ChatGPT-स्तर के संवादात्मक उपयोग तक सीमित हैं
• बड़ी कंपनियों के लिए security policy, बंद IT environment, legacy system के कारण नवीनतम AI टूल्स अपनाना कठिन है, जबकि छोटी कंपनियाँ तेज़ी से AI को अपने कामकाज में शामिल कर दक्षता बढ़ा रही हैं
• यह अंतर ऐसे दौर की ओर ले जा रहा है जहाँ छोटी टीमें बड़ी कंपनियों की तुलना में कहीं अधिक प्रोडक्टिविटी दे सकती हैं, और internal API तथा सुरक्षित code execution environment बनाना भविष्य की प्रतिस्पर्धात्मक क्षमता का केंद्र बन रहा है
• अगर programming language और API access वाले bash sandbox को agent के साथ जोड़ा जाए, तो non-technical user भी लगभग सभी productivity apps को replace कर सकते हैं, और यही knowledge work का भविष्य है

---

AI उपयोगकर्ताओं के दो प्रकार

• AI उपयोगकर्ताओं के बीच प्रोडक्टिविटी का अंतर तेज़ी से बढ़ रहा है
  • एक तरफ वे लोग हैं जो Claude Code, MCPs, skill-based workflow का उपयोग करते हैं, और non-technical user भी terminal में AI का सक्रिय उपयोग कर रहे हैं
  • खासकर finance क्षेत्र में Python-आधारित automation से Excel की सीमाओं को पार करने के कई उदाहरण मिल रहे हैं
• दूसरी तरफ वे लोग हैं जो अब भी ChatGPT-स्तर के सरल प्रश्न-उत्तर वाले उपयोग तक सीमित हैं
  • कई कर्मचारी अब भी इसी श्रेणी में आते हैं और AI की पूरी क्षमता का उपयोग नहीं कर पा रहे हैं

Microsoft Copilot की सीमाएँ

• M365 Copilot Office 365 subscription के साथ bundle होकर आता है, इसलिए enterprise market में इसकी हिस्सेदारी अधिक है, लेकिन इसका interface ChatGPT के कमजोर संस्करण जैसा है
  • "agent" feature CLI coding agent (जिसमें Microsoft का अपना GitHub Copilot CLI भी शामिल है) की तुलना में लगभग हास्यास्पद स्तर का है
    यह बड़े फ़ाइलों पर अक्सर विफल हो जाता है, और memory·CPU limits बहुत ज़्यादा प्रतिबंधात्मक हैं
• Microsoft के अंदर भी Claude Code को internal teams में अपनाया जा रहा है
  • यह दिखाता है कि Copilot तकनीकी रूप से पीछे है
• enterprise environment में कई बार Copilot ही एकमात्र अनुमत AI tool होता है, इसलिए कर्मचारियों को दूसरे tools इस्तेमाल करने के लिए या तो नौकरी का जोखिम उठाना पड़ता है या बहुत अधिक प्रयास करना पड़ता है
  — वरिष्ठ निर्णयकर्ता ऐसे tools से बेहद खराब परिणाम देखने के बाद पूरे AI को कमतर आँकते हैं, या बड़ी consulting firms पर भारी खर्च करने के बाद भी परिणाम नहीं मिलते

बड़ी कंपनियों के सामने संरचनात्मक जोखिम

• security-केंद्रित बंद IT policy innovation को रोक रही है
  • अत्यधिक locked-down environment: basic script interpreter तक local में चलाना संभव नहीं (किस्मत अच्छी हो तो VBA, और वह भी Group Policy से सीमित)
  • legacy software: core workflow के लिए internal API ही नहीं है, इसलिए agent के पास connect करने के लिए कुछ नहीं
  • siloed engineering departments: कई बार पूरी तरह outsourced, इसलिए सुरक्षित sandboxed agent चलाने के लिए आवश्यक infrastructure बनाने वाला internal staff ही नहीं होता
• निश्चित रूप से, security concerns वास्तविक हैं — production database पर बिना नियंत्रण coding agent को अंधाधुंध चलाना जोखिमभरा है
• लेकिन sandboxing कठिन काम है, और असली समस्या यह है कि इसे सुरक्षित रूप से बनाने वाली engineering team का न होना

छोटी कंपनियों की तेज़ बढ़त

• legacy constraints से मुक्त mid/small companies AI को तेज़ी से अपना रही हैं और प्रोडक्टिविटी को विस्फोटक रूप से बढ़ा रही हैं
  • एक तरफ ऐसे finance directors हैं जिन्होंने Microsoft का Excel Copilot (और Gemini का Google Sheets integration भी उतना ही कमजोर) आज़माया, और साधारण काम भी खराब होने पर फिर उसे छुआ तक नहीं,
  • दूसरी तरफ Claude Code सीख चुके non-technical executives हैं जो local में Python चला रहे हैं
    • 30 sheets वाले बेहद जटिल Excel financial model को Claude Code की मदद से Python में बदलने का काम सिर्फ 2~3 prompts में लगभग पूरा हो जाता है
    • मॉडल Python में बदलते ही Claude Code के साथ data science team-स्तर की क्षमता मिल सकती है
    • Monte Carlo simulation चलाना, external data source जोड़ना, web dashboard बनाना, और model (या business) की कमजोरियों का analysis करना — यह सब संभव हो जाता है
• पहले छोटी कंपनियों के कर्मचारी बड़ी कंपनियों के resources और teams से ईर्ष्या करते थे,
  लेकिन इस माहौल में छोटी टीमें बड़ी कंपनियों से कहीं अधिक दक्षता दिखा रही हैं और प्रोडक्टिविटी का रुझान उलट रहा है

भविष्य की कार्य संरचना

• AI से होने वाला productivity improvement bottom-up तरीके से हो रहा है
  • छोटी टीमें किसी खास process के लिए AI-assisted workflow बनाने की कोशिश करती हैं, और क्योंकि वे उस process को गहराई से जानती हैं, अच्छे परिणाम निकालती हैं
  • यह उन outsourced software engineering teams के विपरीत है जिन्हें उस process का कोई अनुभव नहीं होता
  • यह अधिकांश मौजूदा 'digital transformation' projects के ठीक उलट है
• जिन कंपनियों के पास internal systems के लिए API हैं, वे कहीं अधिक हासिल कर सकती हैं
  • दायरा read-only data warehouse से शुरू होकर, जहाँ कर्मचारी connect होकर user की ओर से query चला सकें, core business processes के APIकरण तक जाता है
• security-controlled VM environment में code agent चलाना एक व्यावहारिक विकल्प है
  • read-only reporting के लिए उपयुक्त, लेकिन data modification में अब भी सीमाएँ हैं
• legacy enterprise SaaS कंपनियाँ या तो मज़बूत lock-in में हैं, या नज़रिए के अनुसार बेहद कमज़ोर स्थिति में
  • ज़्यादातर "API-first" products नहीं हैं, और मौजूदा API developers के लिए design किए गए हैं, इसलिए वे ऐसी स्थिति के लिए optimized नहीं हैं जहाँ हज़ारों कर्मचारी उन्हें अक्षम ढंग से call करें
  • लेकिन यदि वही कंपनी का single source of truth हैं, तो migration बहुत कठिन हो जाता है और वे प्रोडक्टिविटी improvement की bottleneck बन जाते हैं
• छोटी कंपनियाँ नए और बेहतर API-designed products का उपयोग करने की अधिक संभावना रखती हैं
  • ये नए SaaS products API-केंद्रित design के कारण AI integration के लिए अनुकूल हैं

knowledge work का नया रूप

• programming language और system API access वाले bash sandbox और agent framework का संयोजन non-technical users के लिए भी शक्तिशाली productivity tool बन सकता है
  • user prompt देता है, और agent API के ज़रिए परिणाम तैयार करता है
  • report writing, data analysis, document generation जैसे कामों को मनचाहे format में output किया जा सकता है, इसलिए यह अधिकांश पारंपरिक office apps को replace कर सकता है
• user के prompt देने पर agent API से जुड़कर अनुरोध के अनुसार output तैयार करे — यही knowledge work का भविष्य है
  • यह ध्रुवीकरण वास्तविक है और तेज़ी से बढ़ रहा है
• यह बदलाव ऐसे दौर की शुरुआत कर रहा है जहाँ छोटी टीमें बड़ी कंपनियों से तेज़ी से competitive advantage हासिल कर सकती हैं
  • AI उपयोग का अंतर वास्तव में मौजूद है, और उसकी रफ़्तार लगातार बढ़ रही है
  • इतिहास में कभी भी छोटी टीमें अपने से हज़ार गुना बड़ी कंपनियों को इतनी आसानी से पीछे नहीं छोड़ पाई थीं

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे लगता है कि उपयोगकर्ताओं को दो वर्गों में बाँटा जा सकता है
  एक वे लोग हैं जो AI को एक tool की तरह इस्तेमाल करते हैं, उसकी सीमाएँ समझते हैं, और उसे दोहराव वाले या उबाऊ काम सौंपने या summary लेने के लिए इस्तेमाल करते हैं
  दूसरे वे लोग हैं जो सोचने की प्रक्रिया ही outsource कर देते हैं; उन्हें विषय की लगभग कोई समझ नहीं होती, वे सिर्फ नतीजे चाहते हैं और सीखने की इच्छा नहीं रखते
  यही वह वर्ग है जो मानता है कि chatbot senior developer की जगह ले सकता है

  • जब मुझे एहसास हुआ कि कंपनी को ‘सोचने वाले engineer’ नहीं चाहिए, तो मैंने भी काम में अपनी सोच को outsource करना शुरू कर दिया
    सिर्फ तेज delivery मायने रखती है, और customer feedback आधे साल बाद आता है, इसलिए उसका कोई मतलब नहीं
    अब मैं बस न्यूनतम मेहनत करके वेतन लेते हुए किसी तरह टिके रहने की कोशिश कर रहा हूँ
  • एक और प्रकार भी है। वे लोग जो अपनी सोचने की क्षमता का इस्तेमाल करके और अधिक उन्नत tools बनाते हैं, और धीरे-धीरे ज्यादा सोच और skill को AI को सौंपते जाते हैं। मैं और मेरे आसपास के लोग इसी श्रेणी में आते हैं
  • सोच को outsource करना हमेशा बुरा नहीं होता
    मैंने Claude Code और ElevenLabs से German listening practice के लिए एक app बनाया, और वह इतना प्रभावी था कि शिक्षक भी हैरान रह गए
    मुझे code सीखने में रुचि नहीं थी; मेरा लक्ष्य German कौशल सुधारना था
  • मुझे लगता है तीसरा समूह भी है। वे लोग जो AI को एक virtual teammate की तरह इस्तेमाल करते हैं और उसके साथ ideas आगे-पीछे करते हैं। मुझे लगता है यह सबसे दिलचस्प use case है
  • एक और वर्ग वे लोग हैं जो इसे search engine, doctor या counselor, और documentation के विकल्प के रूप में इस्तेमाल करते हैं।
    यानी, सिर्फ एक साधारण tool से बढ़कर एक conversational partner की तरह इस्तेमाल करते हैं

• greenfield project और brownfield project में AI को इस्तेमाल करके देखें तो productivity का अंतर बहुत बड़ा होता है
  नए project के पहले दिन यह एक हफ्ते का काम कर देता है, लेकिन मौजूदा system में यह सिर्फ लगभग 20% सुधार तक सीमित रहता है
  आखिरकार इसका मतलब है कि AI ‘innovator’s dilemma’ को बहुत तेजी से फिर से पैदा कर देता है
  सवाल यह है कि जटिल systems को mature करने के चरण में AI कितनी भूमिका निभा सकता है

  • enterprise IT में काम करने वाले व्यक्ति के रूप में मैं इस बात से सहमत हूँ
    मैंने Hashicorp Packer build file लगभग पूरी AI से बनवाई, और local AI ने बहुत मदद की
    लेकिन पुरानी infrastructure में unpredictability इतनी अधिक होती है कि LLM उल्टा चीजें खराब कर सकता है
  • सच तो यह है कि ऐसा phenomenon AI के बिना भी नए project में हमेशा होता है
    शुरुआत में चीजें तेज चलती हैं, लेकिन बाद में architecture की सीमाएँ सामने आ जाती हैं
  • मैं AI को productivity lubricant की तरह इस्तेमाल करता हूँ। जब मैं थका होता हूँ या जरूरत से ज्यादा सोच रहा होता हूँ, तो यह मुझे शुरुआत का बिंदु दे देता है
    overengineering कम करने में भी मदद मिलती है
  • लेकिन यह speed-up context window की सीमा पर आकर रुक जाता है
    project जब 200k tokens से ऊपर चला जाता है, तो productivity शून्य हो जाती है
    आखिर में वे organizations जीतती हैं जिनकी process memory पर निर्भर नहीं करती
  • आम तौर पर यह 10~20% सुधार देता है, लेकिन personal projects में कभी-कभी 200~500% तक improvement मिला है

• जब मैंने सुना कि एक executive ने Claude Code से 30-sheet वाले जटिल Excel financial model को Python में convert कर दिया, तो मुझे लगभग उल्टी आ गई
  mathematics और geophysics background वाले व्यक्ति के रूप में, ऐसा Excel model अपने आप में ही एक nightmare है
  फिर भी मैं मानता हूँ कि Python conversion के मूल से बदतर होने की संभावना बहुत ज्यादा नहीं है

  • code-adjacent क्षेत्रों का असली रहस्य यह है कि testing लगभग होती ही नहीं
    गलत modeling को पकड़ने वाला कौन होगा? लगभग कोई नहीं
    LLM द्वारा बनाए गए simulation में verification process और भी कम होती है
  • finance sector में वास्तव में production Excel spreadsheet को code की तरह version control और test किया जाता है
    शुरुआत में उसे तेज प्रयोगों के लिए इस्तेमाल किया जाता है, और जब revenue बड़ा हो जाता है, तो tech team उसे औपचारिक app में बदल देती है
  • लेकिन मुझे पूरा यकीन है कि Claude Code वाला version कहीं ज्यादा खराब होगा
    मूल Excel को सालों तक सुधारा गया है, जबकि converted version सिर्फ एक नकली प्रतिरूप है
  • “बदतर होने की संभावना बहुत ज्यादा नहीं है” वाली बात सुनकर मुझे हँसी आ गई
  • अब हम “Excel की वजह से मंदी आने वाले दौर” से “AI-निर्मित financial model की वजह से मंदी आने वाले दौर” की ओर बढ़ रहे हैं
  • भले ही Claude Code ने conversion लगभग एक ही बार में कर दिया हो, लेकिन इस बात की संभावना ज्यादा है कि उसने critical logic खराब कर दिया हो
    • बेशक, अगर Excel और Python दोनों को साथ चलाकर results compare किए जा सकें, तो accuracy बढ़ सकती है
    • लेकिन उस Excel model के खुद ठीक से validated होने की संभावना भी कम है
    • ‘लगभग एक ही बार में’ कहना ऐसा है जैसे CPU के बारे में कहना कि वह ‘लगभग 100% reliable’ है
    • आखिरकार यह डरावना है कि हमारा 401k शायद AI द्वारा बनाए गए model से manage किया जा सकता है

• यह बात डरावनी लगती है कि गैर-विशेषज्ञ लोग AI से financial model बना रहे हैं

  • लेकिन शायद कोई बड़ा हादसा होने पर ही capitalists सचेत होंगे
  • फिर भी, पास में Excel रखकर comparison test किया जा सकता है, और कुछ अजीब लगे तो AI से explanation भी माँगी जा सकती है
  • medical field में जाएँ तो यह और भी डरावना लगता है
  • मैं भी Python से Rust सीख रहा हूँ, और LLM को बार-बार गलती करते देख AI पर भरोसे के जोखिम को गहराई से महसूस कर रहा हूँ
  • सच तो यह है कि बहुत से Excel model भी ठीक से test नहीं होते। बस इतना कि ‘लगता है सही है’

• अभी Shadow AI का जन्मकाल चल रहा है
  2000s के Shadow IT की तरह, कर्मचारी छिपकर terminal में Claude Code चला रहे हैं
  क्योंकि आधिकारिक Copilot CSV तक सही से handle नहीं कर पाता
  CISO डर से काँप रहे हैं, लेकिन अगर वे इसे रोकेंगे, तो सक्षम कर्मचारी नौकरी छोड़ देंगे

  • समस्या यह है कि ये लोग tokens या account permissions सीधे AI को दे देते हैं। यह एक security nightmare है

• 1980s की शैली में कहें तो, असली innovation मैदान में काम करने वाले कर्मचारियों द्वारा स्वेच्छा से बनाए गए workflow से आती है
  क्योंकि process को सबसे अच्छी तरह वही जानते हैं
  उसके बाद ही CIO-friendly packaged software पीछे-पीछे आता है

  • आखिरकार शक्ति tail distribution में होती है, यानी मुट्ठीभर experimental कोशिशें ही बदलाव लाती हैं

• पिछले कुछ महीनों में agents उपयोगी होने लगे हैं, इसलिए अब सब लोग इन्हें बस इस्तेमाल करना शुरू कर रहे हैं
  MCP, LangChain, vector DB जैसी चीजें कभी trend में थीं, लेकिन अब शांत हैं
  अभी trend की बात करने के लिए बहुत जल्दी है

  • MCP का उन्माद ज्यादातर बेचने के उद्देश्य से था। लेकिन protocol के रूप में देखें तो यह काफी उपयोगी है
    मैंने context7 और playwright MCP server इस्तेमाल किए हैं, और वे planning तथा feedback loop में प्रभावी रहे
  • MCP की बात करने वाले ज्यादातर लोग सिर्फ LinkedIn पर सक्रिय manager होते हैं
  • मेरे जैसे पुराने Linux user के लिए भी Claude Code इतना आसान हो गया है कि मैं हर weekend 2 apps पूरा कर लेता हूँ
  • व्यवहार में MCP की जगह REST या मौजूदा API ज्यादा इस्तेमाल होते हैं

• Microsoft Copilot का Excel integration बेहद खराब है
  30 साल तक जटिल XML format बनाने का नतीजा यह है कि LLM उसे समझ ही नहीं पाता
  इसलिए हमारी कंपनी Word documents को Markdown में migrate कर रही है। यह किसी तरह का कर्मफल जैसा लगता है

  • Tim Berners-Lee द्वारा कल्पित machine-readable web का सपना अब जाकर सच होता दिख रहा है
    लेकिन documents को AI-friendly बनाने में लगने वाला समय लगातार बढ़ता जा रहा है
  • विडंबना यह है कि Claude Code ने Excel के साथ कहीं बेहतर काम किया
    Copilot ने CSV conversion का निर्देश भी अनदेखा कर दिया और fail हो गया
  • पहले हमने interns को Visio XML parse करके JSON में convert करने वाला project दिया था; वह सफल तो हुआ, लेकिन जल्दी ही गायब हो गया

• मैंने पहले एक बात सुनी थी — “अब बड़े enterprise छोटे enterprise को नहीं हराते, बल्कि तेज enterprise धीमे enterprise को हराते हैं”
  अब AI के दौर में यह बात और भी सच लगती है। सवाल है तेज कैसे बने रहें

  • लेकिन तेज होना हमेशा अच्छा नहीं होता। हो सकता है आप पहले खाई में गिर जाएँ
  • और यह जानना भी महत्वपूर्ण है कि कब गति धीमी करनी चाहिए। security और compliance को नुकसान पहुँचाए बिना तेज चलना ही असली बात है
  • बेशक, यह एक तरह की typical startup सलाह है, लेकिन कभी-कभी धीमी तरफ भी जीत जाती है (उदाहरण: Teams vs Slack)

[tazuya]

Copilot को अब भी काफ़ी आलोचना झेलनी पड़ रही है। MS इसे आखिर कब सुधारेगा?

[bichi]

मैं "Meoseum 1, 2, 3" के रूप में लिख रहा हूँ

[xguru]

बीच में Copilot की काफ़ी आलोचना है, लेकिन असल में
Claude Code Microsoft के अंदर तेज़ी से फैल रहा है

लगता है कि यह स्थिति देश की बड़ी कंपनियों पर भी ज़रूर लागू होगी।
कंपनी कहती है इसलिए इस्तेमाल तो करते हैं, लेकिन शायद ऐसी जगहें भी काफ़ी होंगी जहाँ ChatGPT/Claude की अनुमति नहीं होगी और सिर्फ़ Copilot ही इस्तेमाल किया जा सकेगा।