- पिछले 18 महीनों में जिन AI प्रोजेक्ट्स को देखा या जिनमें भाग लेने का अनुरोध मिला, उनकी सफलता दर 0% रही; तकनीक की अनिश्चितता और मौजूदा software projects के खराब संचालन के कारण निवेश परिणामों में नहीं बदल पाया
- 500 से अधिक कर्मचारियों वाले संगठनों में सिर्फ AI की उपयोगिता पर संदेह करने से promotion और नौकरी खतरे में पड़ जाते हैं, और कर्मचारी AI washing तथा token उपयोग में हेरफेर करके संगठन की मांगों के अनुरूप व्यवहार कर रहे हैं
- natural language data query जैसे चमकदार AI demos सटीकता और operational सीमाओं की चेतावनी देने पर भी खरीदारी का उत्साह भड़का देते हैं, और विक्रेता के लिए reputation व legal risk तक पैदा कर सकते हैं
- ग्राहक और boards एक-दूसरे के बढ़ा-चढ़ाकर किए गए productivity दावों को नकार नहीं पाते—इस coordination problem के कारण संदेह रखने वाले executives भी सार्वजनिक रूप से AI निवेश का समर्थन करते हैं, और non-AI business में भी जबरन AI तत्व जोड़े जाते हैं
- संगठनों को सही रास्ते पर लाने के लिए one-on-one conversations, anonymous surveys, on-the-ground validation की जरूरत है; और जिन कर्मचारियों के लिए internal politics से बचना मुश्किल है, उन्हें AI-generated code से burnout होने से पहले नौकरी बदलने या contract work में जाने की तैयारी करनी चाहिए
18 महीनों में देखे गए AI projects की विफलता
- पिछले एक साल में कंपनी की sales और अधिकतर technical work संभालते हुए दुनिया भर के experts से करीब 300 conversations के अनुभव में, private और public organizations के जिम्मेदार लोग बिना योजना के AI में डूबे हुए थे या चुप थे
- AI projects के वास्तविक परिणामों की पुष्टि करना मुश्किल है, क्योंकि board, management, employees, vendors और consultants—किसी के पास भी failures सार्वजनिक करने का incentive नहीं है
- management failure मान ले तो पद गंवा सकता है
- employee layoffs या restructuring का target बन सकता है
- कुछ listed companies Copilot licenses खरीदने के बाद इसे AI productivity improvement के रूप में घोषित करती हैं
- जिन projects को देखा गया या जिनमें भाग लेने का अनुरोध मिला, वे 18 महीनों में सभी failed रहे; team ने AI implementation work पूरी तरह ठुकरा दिया और केवल वे contracts बनाए रखे जो सीधे OpenAI के बने रहने पर निर्भर नहीं थे
- AI tools कुछ tasks को तेज कर सकते हैं, फिर भी मौजूदा निवेश का तरीका और पैमाना उचित नहीं था
- सामान्य software projects के सभी failure factors वैसे ही मौजूद हैं
- नई technology होने का अतिरिक्त risk है, इसलिए implementation सही होने पर भी failure हो सकता है
- इतने risk को संभालने लायक software delivery capability बहुत कम कंपनियों में होती है
Internal और customer-facing chatbots परिणाम क्यों नहीं दे पाते
- Internal chatbots corporate documents की खराब quality के कारण पर्याप्त जवाब नहीं बना पाते, और वास्तविक employee usage भी meaningful नहीं था
- Customer-facing chatbots के भी संतोषजनक उदाहरण दुर्लभ थे; medical consultation के दौरान real-time transcription लगभग एक exception था
- Project owners उन basic metrics से बचते हैं जो दिखाते हैं कि tool वास्तव में इस्तेमाल हो रहा है या नहीं, और आसानी से manipulate होने वाले metrics चुनते हैं
- Mitsubishi का car fault support voice bot natural voice, तेज response और वास्तविक operating environment के लिहाज से काफी polished था, लेकिन वादा किया गया follow-up 6 महीनों तक नहीं आया
- यह पता नहीं चला कि request गायब हो गई, या बिना human intervention के solved के रूप में गिनी गई
- system में error न दिखने के बावजूद customer ने तय किया कि वह फिर Mitsubishi vehicle नहीं खरीदेगा
- चल रहे AI project के goals, users और outcomes के बारे में पूछना ही accountability structure पर हमला माना जा सकता है, इसलिए crisis आने से पहले intervention मुश्किल है
- Gerry Weinberg के इस principle के अनुसार कि consulting तब होती है जब दूसरा पक्ष request करे और वह लोगों को प्रभावित करे, जब तक general data strategy पर सलाह स्पष्ट रूप से न मांगी जाए, project में दखल नहीं दिया जाता
संदेह की अनुमति न देने वाली organizational culture
- 500 से अधिक कर्मचारियों वाली सभी देखी गई कंपनियों में promotion और employment बनाए रखने के लिए AI की transformative power को बार-बार घोषित करना पड़ता था
- यह technical use cases सुझाने से ज्यादा धार्मिक आस्था-स्वीकारोक्ति जैसा था; इसे मुख्यतः non-technical staff चला रहे थे और कुछ technologists भी साथ दे रहे थे
- कुछ लोग “AI सब कुछ बदल देगा” कहते थे, लेकिन अपने संगठन में LLM usage का एक भी example या कोई actual change नहीं दिखा पाते थे
- सालाना revenue 2 billion dollars से अधिक वाले organization की AI-centric technology strategy बनाने वाले executive ने ChatGPT समेत कोई AI tool कभी इस्तेमाल ही नहीं किया था
- साधारण PR-style झूठ से ज्यादा खतरनाक वे जिम्मेदार लोग थे जिनके पास technical background नहीं था और जो सचमुच अपनी बात पर विश्वास करते थे
- झूठ बोलने वाले से self-interest के आधार पर negotiation की जा सकती है, लेकिन सच्चा believer अपने हितों से भी नहीं डगमगाता
- एक organization ने सिर्फ इसलिए top performers को निकाल दिया कि उन्होंने LLM के बिना high performance दी थी
- “My AI Skeptic Friends Are All Nuts” से critical stance अलग हो सकता है, लेकिन इस बात पर सहमति है कि management द्वारा LLM usage mandatory करना खराब strategy है और professional staff पर असामान्य work constraints डालता है
AI washing और manipulate हो सकने वाले evaluation metrics
- जब managers ने results से ज्यादा AI usage को महत्व देना शुरू किया, तो engineers ने पुराने तरीके से काम करके report करना शुरू किया कि Claude ने किया—यानी AI washing
- कुछ organizations token consumption जितना ज्यादा हो, उतनी higher rating देने वाले leaderboards चलाते हैं
- system optimization skills के लिए hire किए गए employees LLM को अपना prompt बार-बार repeat करने के लिए configure करते हैं
- output deployment के लायक न हो तब भी token usage भरकर वे दूसरा काम करते हैं
- एक software engineer ने Go repository की copy AI को दी, उससे पूरा Zig में rewrite करवाया, फिर result फेंक दिया—इस तरह usage quota पूरा किया
- असल layoffs उन लोगों पर हुए जिन्होंने AI strategy पर साफ तौर पर सवाल उठाए, और employees ने सीख लिया कि management की AI vision की तारीफ करना सुरक्षित है
- जैसे hospital या civil engineering firm के non-expert executives field experts की सहमति के बिना specific procedures enforce नहीं करते, वैसे ही non-technical management द्वारा software professionals पर specific tools mandatory करना भी अनुचित है
Snowflake Cortex demo से शुरू हुई खरीदारी की होड़
- Snowflake usage-based billing पर चलता है और सामान्य enterprise data को रोज करीब 1 minute process कर सकता था, इसलिए इसे analytics database के रूप में इस्तेमाल किया गया; लेकिन AI chatbot layer Cortex का उपयोग नहीं किया गया
- Cortex data columns के meaning जैसे metadata के आधार पर “पिछले हफ्ते revenue कितना था?” जैसे natural language questions को database queries में बदलता है
- Snowflake employee की presentation में best setup की accuracy करीब 92% थी; बड़े enterprise data में 10 numbers में से करीब 1 गलत हो सकता था, और deployment management में भी गंभीर issues थे
- operational environment के लिए उपयुक्त नहीं होने की warning के साथ demo दिखाया गया, लेकिन पहले उदासीन रहे सभी prospects तुरंत खरीदना चाहते थे
- non-AI तरीके से millions of dollars की value बना सकने वाला proposal भी interest से बाहर हो गया
- rational judgement की खाली जगह का फायदा उठाना irresponsible लगा, इसलिए sales रोक दी गई और Cortex को demo list से हटा दिया गया
- team ने दो घंटे में जो low-quality demo बनाया, वह भी prospects द्वारा पहले देखे गए outputs से बेहतर था
- पहले से AI usage का promotion कर रही ASX-listed company तक के पास मौजूदा investments से दिखाने लायक result नहीं था
- जिन prospects ने AI में temporary curiosity से ज्यादा interest दिखाया, उन्होंने sales process में irrational behavior और worship-like management environment दिखाया; contracts reputation और legal risks बना सकते थे, इसलिए सभी deals छोड़ दी गईं
Executives अतिशयोक्ति क्यों नहीं रोक पाते: coordination problem
- annual recurring revenue 1 billion dollars से अधिक वाली कंपनियों के कुछ AI leads ने कहा कि वे अपनी role को practically fake मानते हैं, फिर भी संगठन में promotion का यही एक रास्ता था इसलिए उसे स्वीकार किया
- Fortune 500 कंपनी के technically capable executive भी कंपनी के “100x productivity” जैसे public statements को निजी तौर पर defend नहीं कर पाए
- अतिशयोक्ति की मुख्य driver sales copy से ज्यादा customer executives की face-saving और contractual relationship थी
- अगर vendor executive customer के 100x productivity claim को नकारता है, तो यह customer executive की credibility पर हमला माना जा सकता है
- उसके परिणामस्वरूप बड़ा enterprise contract cancel हो जाए तो वही vendor executive भी निकाला जा सकता है
- जब कंपनियां एक-दूसरे की customer और supplier दोनों होती हैं, तो कोई executive पहले सच बोलना मुश्किल पाता है
- सभी exaggeration में सहयोग करें तो अपनी position बचा सकते हैं
- एक व्यक्ति अलग हुआ तो वह colleagues को liar, coward या incompetent बना देता है, और निकाला जा सकता है
- सभी एक साथ मान लें तो स्थिति बदल सकती है, लेकिन इसे coordinate करने का कोई तरीका नहीं है
- S&P 500 companies के board members भी AI investment के risks पर संदेह करते थे, फिर भी अपनी seat बचाने के लिए investment मांगना जरूरी महसूस करते थे
- एक director ने कहा, “इतनी जल्दी investment करना ऐसा लगता है जैसे upside के बिना सिर्फ risk उठा रहे हों”
- करीब 2 साल बाद वही कई-billion-dollar organization खुद को AI-native के रूप में promote करने लगा
हर business को AI की packaging में डालने वाला purity test
- organization में politics शामिल होने वाले हर proposal को approval पाने के लिए, वास्तविक value unclear होने पर भी AI alignment शामिल करना पड़ता है
- कई AI projects वास्तव में existing non-AI projects पर बाद में AI element जोड़कर purity test पास करने का रूप थे
- Oracle से Snowflake में database migration के एक case में vendor ने Oracle SQL को Snowflake SQL में बदलने का काम LLM से automate करने का step जोड़ा
- permission की कमी से automation fail हुआ, तो humans ने manually convert किया
- केवल कुछ SQL AI से translate हुए, इस आधार पर पूरे project को AI-based success के रूप में report किया गया
- असल खरीद का कारण license renewal से पहले existing system हटाने के लिए सामान्य database migration था
- ऐसे genuine AI projects दुर्लभ थे जिनमें LLM ही एकमात्र core mechanism हो और success को concrete metrics से मापा जा सके
- वे अधिकतर startups में दिखे, लेकिन sales process के अंत में बार-बार यह request आई कि जिस product को पहले से complete बताकर promote किया गया था, उसे उनके लिए बना दिया जाए—इसलिए deals बंद कर दी गईं
- जिन businesses में AI जोड़ना मुश्किल था, उनकी funding requests reject हो जाती थीं, या communication तब तक delay होती थी जब तक proposal “काफी AI-like” न बन जाए
- कुछ companies extra headcount मांगने से पहले यह साबित करने को कहती हैं कि आपने AI इस्तेमाल करके देखा है
- अगर आप कहते हैं कि AI इस्तेमाल करने के बाद भी people चाहिए, तो आपको “AI ठीक से इस्तेमाल न करने वाला” माना जा सकता है और निकाला जा सकता है
- उन बहुत कम companies को छोड़कर जहां AI सच में top priorities से align है, बड़े organizations के लिए सही software खरीद, talent hiring, honest project reporting और rational new business initiatives पर focus करना मुश्किल हो जाता है
जब किसी specific project को सही करना हो
- AI project की समस्याओं को group meetings की बजाय one-on-one conversations में संभालना अधिक effective है
- public setting में हर attendee डरता है कि colleagues उसे skeptic समझेंगे
- opinions कहीं और share करते समय identity छिपाने का वादा करना चाहिए
- direct quotes जैसी ऐसी चीजों से बचना चाहिए जिनसे source का अनुमान लग सके
- अगर 6 में से सिर्फ 1 व्यक्ति समस्या बताए, तो शायद ऐसे organization में जाना बेहतर हो जहां improvement की संभावना ज्यादा हो
- चल रहे project में Secrets of Consulting से मिली anonymous survey method इस्तेमाल की जा सकती है
- success probability को 1–10 पर rate कराने से कुछ लोग 3 और कुछ 8 देते हुए polarized distribution दिख सकता है
- 3 साल पहले से delayed project में भी ऐसा gap दिखा, और यह CEO को दिखा सकता है कि important information छिपाई जा रही है
- project की actual success daily tool इस्तेमाल करने वाले frontline employees से verify करनी चाहिए
- उन्हें ऐसे environment में बोलने देना चाहिए जहां वे respected महसूस करें
- एक customer में employees को यह तक नहीं पता था कि उन्हें AI tool license दिया गया है, जिससे productivity improvement claim का आधार हिल गया
- अगर आप किसी specific problem को solve करने की स्थिति में हैं, तो “AI सब कुछ बदल देता है” जैसे broad proposition को refute न करना बेहतर है
- organization के reality model को challenge करना हो तो पहले top decision-maker का trust जीतना होगा
- public embarrassment देने की बजाय private dinner setting में anxiety कम करनी चाहिए
- meeting attendees ने पहले क्या public statements दिए हैं, यह पता नहीं होता; इसलिए “LLM को human review के बिना code deploy नहीं करना चाहिए” जैसी common-sense बात भी शुरुआती trust-building को तोड़ सकती है
- अगर किसी दूसरे public-interest goal को हासिल करना जरूरी है और honest approach संभव नहीं है, तो project में $10,000 AI chatbot जोड़कर सिर्फ उस हिस्से को highlight करना भी एक practical option माना जाता है
संगठन बदलने के बजाय जब जीवित रहना हो
- AI के प्रति collective obsession technology से ज्यादा dysfunctional corporate culture की समस्या है, इसलिए individual के लिए meaningful resistance करना मुश्किल है
- full-time employee के बजाय contractor बनना ज्यादा pay दे सकता है और internal politics से दूर कर सकता है; मुश्किल environment में भी clear end date मिलती है
- AI news जितनी जरूरी हो उतनी ही consume करें, और Hacker News·Reddit जैसे लगातार related news feed देने वाले channels से बचना mental load घटाता है
- दोस्तों से शिकायत करते समय भी बताएं कि यह conversation क्यों जरूरी है और उचित स्तर पर रुकें
- अगर आसपास का कोई व्यक्ति non-dangerous use case में AI का गलत इस्तेमाल कर रहा है, तो argue किए बिना आगे बढ़ें; programmer के रूप में opinion मांगा जाए तो “इसमें hype ज्यादा है” कहकर topic बदल दें
- अगर आपको लगातार 2,000-line AI-generated PR review करना पड़ रहा है, तो burnout और layoff मानकर energy बाकी रहते job search शुरू कर दें
- generator को low-quality code की बड़ी मात्रा रोकने के लिए convince करना मुश्किल है
- work slowdown और manager की नाराजगी या तो अभी job search से होगी या बाद में burnout से—बचना मुश्किल है
- अगर manager स्पष्ट AI-generated text से reply करता है, तो energy बचाने के लिए AI से respond करें और नई job खोजें
- token usage को maximum भरने की मांग मिले तब भी reality sense खोने से पहले job change की तैयारी करनी चाहिए
- ऐसी companies hiring platforms पर आसानी से न दिखने वाली small organizations हो सकती हैं
- खोजने में कई महीने लग सकते हैं, इसलिए जल्दी शुरू करना चाहिए
1 टिप्पणियां
Hacker News की रायें
हममें से ज़्यादातर लोग किसी हद तक आश्वस्त थे कि AI समाज को पूरी तरह बदल देगा और सिंगुलैरिटी ले आएगा, लेकिन हक़ीक़त वैसी नहीं निकली। गलती मानकर फिर से मूल्यांकन करने के बजाय, लोग AI को हर दरार में जबरन ठूँस रहे हैं और उसे प्रगति कहकर एक तरह का भविष्यवादी roleplay कर रहे हैं
यह 1990 के दशक के उस बच्चे जैसा है जो मानता था कि Nintendo Power Glove पहनते ही वह hacker बन जाएगा, और यह सिंगुलैरिटी नहीं है। उम्मीद है कि यह उन्माद खत्म होगा और सब लोग फिर अगली सर्व-समाधान तकनीक का इंतज़ार करने वाली स्थिति में लौटेंगे
मेरे जैसे व्यक्ति के लिए, जो software industry छोड़ चुका है और हर हफ्ते 40 घंटे coding नहीं कर सकता, agentic AI search engine, electronic bulletin board और compiler के बराबर की तकनीकी छलांग है। अगर मैं Claude Code से home lab SMTP setup, 2017 के Android app का modernization और signing, और अलग-अलग operating system व architecture के लिए GitHub Actions runner configuration करने को कहूँ, तो मैं बर्तन धोते समय वह नतीजा तैयार कर देता है
इसे मामूली बताकर नकारने वाला पक्ष ही उल्टा AI psychosis पर psychosis में फँसा हुआ है। भले ही model intelligence अभी अपनी सीमा से टकरा जाए, यह पहले से ही खेल बदल देने वाली तकनीक है
लोग काम में LLM का कुछ हद तक सही इस्तेमाल करेंगे, लेकिन अपने काम और दूसरों की अपेक्षित outcome को ठीक से न समझ पाने के कारण बहुत सी गलतियाँ भी करेंगे। जो executives email, text और phone के अलावा शायद ही कोई तकनीक इस्तेमाल करते हैं, वे तकनीक को समझे बिना बोलते रहेंगे
अंतिम नतीजा कोई नहीं जानता, लेकिन Claude को सिर्फ 5 मिनट इस्तेमाल करके भी यह कल्पना करना मुश्किल है कि सारी white-collar jobs पहले जैसी ही बनी रहेंगी
भले ही वह मानव मस्तिष्क के बराबर हो जाए, पूरी मानव समाज की कुल उत्पादकता को पकड़ने के लिए उसे दक्षता में कई अंकों की बढ़त चाहिए होगी, और तभी वह मानव प्रगति की रफ़्तार से आगे निकल सकेगा। AI सिंगुलैरिटी संभव भी हो, तो उस acceleration में पूरी ज़िंदगी लग सकती है
AI के मामले में भी 1950 में Turing test प्रस्तावित होने के बाद, उसे पार करता हुआ लगने वाला system आने में लगभग 75 साल लगे, इसलिए इसे और समय देना चाहिए
इस बात से सहमति है कि “अगर आपकी organization आपसे भयानक AI code से भरे 2,000-line PR की बड़े पैमाने पर review करवाना चाहती है, तो आख़िरकार वह आपको थका देगी और निकाल देगी; इसलिए ऐसे नौकरी ढूँढो जैसे आपको पहले ही निकाला जा चुका हो।” Agentic development जितना ज़्यादा व्यापक होगा, ऐसी बातें उतनी ही बार होंगी
ऐसी शर्तें खोजकर संगठन बनाना चाहिए जिनसे throughput दो-तीन गुना बढ़े, और bottleneck तथा सबसे कठिन हिस्सों पर ध्यान देना चाहिए। यह मैं वास्तव में करके देख चुके व्यक्ति के रूप में कह रहा हूँ
“डेढ़ साल में देखे गए सारे AI projects असफल रहे, इसलिए success rate 0% है” जैसी बात अतिशयोक्ति है और भरोसा कम करती है। AI कहें तो उसमें expert systems से लेकर LLM, transformer, diffusion model तक बहुत कुछ आता है
semantic search, diffusion model द्वारा content generation, यहाँ तक कि supervised learning के संदर्भ में linear regression में भी productivity gains देखे गए हैं। हाल की दिलचस्पी फिर से जगाने वाले transformer LLM तक सीमित करें, तब भी साधारण और उबाऊ कामों को automate करने वाले छोटे प्रोजेक्ट आम तौर पर सफल रहे हैं
model capability से ज़्यादा माँगने वाले महत्वाकांक्षी projects असफल होने की संभावना रखते हैं और अधिकतर मामलों में यह पहले से अनुमानित भी होता है, लेकिन सीमा-रेखा पर मौजूद कुछ प्रोजेक्ट वैध R&D projects हैं
यह selection bias है: वे सिर्फ उन कंपनियों को target करके विज्ञापन करते हैं जिनमें internal expertise नहीं है और जो पहले से असफल हो रही हैं, फिर लिखते हैं कि उन्होंने जो projects देखे वे सब विफल थे। ऊपर से मदद तक ठुकरा देने से, उनके सफल उदाहरण में बदलने की संभावना भी बंद हो जाती है
लगता है कि उसे विनम्र corporate शैली पसंद नहीं, लेकिन यह writing style मुझे पसंद है और वह अक्सर उद्योग की प्रथाओं के खिलाफ जाने वाले सूझबूझ भरे दृष्टिकोण भी पेश करता है
code lines, unit tests, documentation, PR speed जैसे metrics बढ़े हैं, लेकिन वास्तविक business outcomes अस्पष्ट हैं। PR बढ़ने से feature release जल्दी हो सकता है, लेकिन review धीमा पड़ सकता है या bugs के कारण user experience खराब हो सकता है। ज़्यादा code आखिर असली revenue से कैसे जुड़ता है, यह कंपनियाँ नहीं बतातीं
पहले मामले में, जब तक तकनीक का सक्रिय विरोध न किया जाए, software engineer के लिए उपयोगी नतीजे पाना अपेक्षाकृत आसान है। दूसरे मामले में, LLM जैसे अजीब आधार के ऊपर निर्माण करना पड़ता है, इसलिए यह बहुत कठिन है, और internal chatbot जैसे घिसे-पिटे projects अक्सर ज़रूरत से ज़्यादा वादों और उम्मीद से कम नतीजों तक पहुँचते हैं
मैंने दुनिया के दूसरे छोर पर स्थित दो बिल्कुल अलग कंपनियों में management को ऐसे बाहरी दस्तावेज़ LLM से लिखवाने की कोशिश करते देखा है जिनके कानूनी और वित्तीय असर बड़े हो सकते हैं। वे हमेशा कहते हैं कि भेजने से पहले कोई expert उसे पढ़कर fact-check कर लेता है, लेकिन जिन लोगों की विशेषज्ञता editing और fact-checking नहीं है, वे शुरू से सही लिखने की तुलना में review करते समय कहीं ज़्यादा लापरवाह हो जाते हैं
“जब तक आप दूसरे काम कर रहे हों, तब तक Go repository की पूरी कॉपी को Zig में rewrite करवाना ही नौकरी बचाने का तरीका है” जैसी बातें, या फिर ग्राहक कंपनी के executives 100x productivity का दावा करें और supplier का executive अगर कह दे कि यह यथार्थवादी नहीं है, तो उससे ग्राहक executives का भरोसा टूटकर enterprise contract रद्द हो सकता है—ऐसे किस्से बेहतरीन हैं
यह कहा गया है कि “जिन भी AI projects को मैंने देखा, उनकी success rate 0% रही,” लेकिन AI project की परिभाषा ही नहीं दी गई। क्या मतलब है शुरू से software लिखना, या non-developers द्वारा अंदरूनी या बाहरी तौर पर LLM chatbot इस्तेमाल करना, या कुछ और—इस पर ठोस उदाहरण चाहिए
workflow automation पर नंगे राजा वाली आलोचना से मैं पूरी तरह सहमत हूँ, लेकिन यह अजीब है कि कई लोगों के लिए उपयोगी AI-assisted engineering की चर्चा ही नहीं की गई। chatbots भी समस्या का दायरा सीमित करके और सही चुनाव के साथ सफल हो सकते हैं। मेरी पिछली कंपनी को vector database के लिए conversational interface से अच्छे नतीजे मिले थे, लेकिन असली core तो vector database ही था, और संभव है कि traditional UI उससे तेज़ और ज़्यादा accurate होता
कुल मिलाकर लेख की दिशा मोटे तौर पर सही है, खासकर executives पर छाए AI उन्माद और अवास्तविक अपेक्षाओं वाला हिस्सा बिल्कुल वाजिब है
Claude से advanced SQL और Python code लिखने का मेरा अनुभव इस लेख के दावों से मेल नहीं खाता। natural language में data query करने वाला सचमुच संतोषजनक chatbot मैंने खुद नहीं देखा, लेकिन बहुत complex queries को natural language में लिखकर मैं 80~90% स्तर तक पहुँच पाया हूँ
जो कंपनियाँ AI की मदद से competitors से आगे निकल रही हैं, वे शायद उसका ढिंढोरा नहीं पीट रहीं और चुपचाप उसका उपयोग कर रही हैं। लेख का असली निशाना managers से भरी बड़ी कंपनियाँ लगती हैं, और ऐसी organizations AI से पहले भी data science·analytics या blockchain के साथ बिल्कुल ऐसा ही व्यवहार करती थीं
अब कोई भी LLM की मदद से बुरे ideas को भी भरोसेमंद दिखा सकता है, इसलिए किसी औसत vice president का गलत idea पूरे organization पर थोपा जा सकता है और भारी productivity loss हो सकता है
feature development अब भी लगभग उतना ही समय लेता है, या productivity gain सीमित रहता है। शायद इसलिए कि ज़्यादातर organizations software बनाना ही पुरानी बीमारी की तरह लगातार खराब तरीके से करती हैं
पिछले हफ़्ते मुझे दो अलग-अलग जगहों से यह पूछने वाले survey मिले कि काम में AI का उपयोग कैसे किया जाता है, और दोनों में multiple-choice सवाल थे जिनमें 0 विकल्प चुनने की अनुमति नहीं थी, और उन्हें mandatory question बनाया गया था
कंपनियों द्वारा AI अपनाने से सच में भारी productivity gains हो रहे हैं या नहीं, यह तो पता नहीं, लेकिन फावड़ा बेचने वालों Nvidia और Anthropic के लिए यह पूरी तरह समझ में आता है
यह बता देने से कि राजा नंगा है, उन्माद रुक नहीं जाता। सिर्फ़ 17वीं सदी का tulip mania ही नहीं, बल्कि agile processes, work timesheets, और lines of code पर आधारित productivity measurement भी वैसी ही चीज़ें हैं; कंपनियाँ हर दौर में नए सामूहिक उन्माद दोहराती रहती हैं
consulting experts की process-centrism, security teams का excessive control, पीछे छूट जाने का डर, और AI-driven modern enterprise जैसा दिखने की घोषणा-लालसा—ये सब इसे भड़काते हैं। ग्राहक, कंपनियाँ, supply chain, सरकारें और विचारक—सब इस वैश्विक नाच में शामिल हैं; संगीत कभी न कभी बदलेगा और नाच भी बदल जाएगा
business और politics अक्सर इसी से संचालित होते हैं, और tech industry भी बार-बार trends, hype, और दशकों तक चलने वाली उन गलतियों में फँसती रहती है जो बाद में साफ़-साफ़ दिखने लगती हैं