मुझे लगता है कि अभी कई कंपनियाँ AI की सामूहिक उन्माद की स्थिति में फँसी हुई हैं

 (twitter.com/mitchellh)
4 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मिशेल हाशिमोटो: "अभी कई कंपनियाँ गंभीर AI सामूहिक उन्माद में फँसी हुई हैं, और उनके साथ तर्कसंगत बातचीत करना असंभव है"
  • cloud infrastructure automation के दौर की MTBF vs MTTR बहस अब पूरे software development उद्योग में फैल रही है, और AI agents पर अंधविश्वास सामूहिक उन्माद का एक नया रूप बना रहा है
  • "एजेंट जल्दी bug ठीक कर देंगे, इसलिए bug के साथ release करना भी ठीक है" जैसी MTTR-प्रधान सोच फैल रही है, जबकि infrastructure के दौर में यह सोच पहले ही विफल साबित हो चुकी है
  • सिस्टम स्थानीय metrics पर स्वस्थ दिखते हुए भी समग्र रूप से समझ से बाहर की स्थिति में बदल सकते हैं, और bug reports में कमी या test coverage में वृद्धि वास्तविक सुरक्षा की गारंटी नहीं देती
  • जब इस समस्या को सीधे उठाया जाता है, तो "test coverage 100% है", "bug reports कम हो रही हैं" जैसी तुरंत आने वाली प्रतिक्रियाएँ बातचीत को बंद कर देती हैं, और लोग पूरी तस्वीर नहीं देख पाते
  • बदलाव की रफ्तार इतनी तेज है कि कोई भी मूल architecture के क्षरण को पहचान नहीं पा रहा, और हम एक स्वचालित "resilient disaster machine" बना रहे हैं

मुख्य दावा: AI सामूहिक उन्माद (AI Psychosis)

  • अभी कई कंपनियाँ गंभीर AI सामूहिक उन्माद की स्थिति में हैं, और उनके साथ तर्कसंगत बातचीत करना ही असंभव है
  • विशिष्ट लोगों का नाम नहीं लिया जा सकता क्योंकि उनमें निजी तौर पर गहराई से सम्मानित मित्र भी शामिल हैं
  • इस स्थिति के आगे कैसे विकसित होने को लेकर गहरी चिंता व्यक्त की गई है

infrastructure युग से सबक: MTBF vs MTTR

  • cloud transition और cloud automation के समय हुई MTBF (औसत विफलता-अंतराल) vs MTTR (औसत पुनर्प्राप्ति समय) बहस फिर उभर रही है
  • तब यह infrastructure तक सीमित थी, लेकिन अब यह पूरे software development उद्योग (और आगे चलकर पूरी दुनिया) तक फैल चुकी है
  • AI पर अंधविश्वास रखने वाले लगभग पूर्ण रूप से "MTTR ही काफी है" वाली सोच से काम कर रहे हैं
    • तर्क यह है: "agents इंसानों से कहीं अधिक गति और scale पर bugs ठीक कर देंगे, इसलिए bugs के साथ release करना स्वीकार्य है"
  • infrastructure युग से मिला सबक: MTTR शानदार है, लेकिन resilient systems को पूरी तरह छोड़ा नहीं जा सकता

बातचीत का बंद होना और प्रतिक्रिया का पैटर्न

  • जब यह मुद्दा निजी तौर पर परिचित लोगों के सामने रखा जाता है, तो तुरंत उपेक्षा मिलती है
    • जैसे: "नहीं, test coverage पूरी है" या "bug reports कम हो रही हैं"
    • ऐसी प्रतिक्रियाएँ पूरी तस्वीर नहीं दिखातीं
  • निजी तौर पर चिंता जताई गई, लेकिन किसी ने नहीं सुना; इसलिए इसे व्यापक स्तर पर साझा करना जरूरी समझा गया

स्वचालित disaster machine

  • infrastructure में पहले ही सीखा गया सबक: automation के जरिए एक "बेहद resilient disaster machine" बनाई जा सकती है
  • ऐसी स्थिति बन सकती है जहाँ सिस्टम स्थानीय metrics पर स्वस्थ दिखे, लेकिन समग्र रूप से समझ से बाहर हो जाए
  • bug reports घटती हैं, लेकिन छिपे हुए जोखिम विस्फोटक रूप से बढ़ते हैं
  • test coverage बढ़ती है, लेकिन semantic understanding घटती जाती है
  • बदलाव इतनी तेजी से हो रहे हैं कि कोई भी आधारभूत architecture के क्षरण को पहचान नहीं पाता

प्रमुख replies में उठे बिंदु

  • @adamhjk: "pure vibe coding सबसे पहले architecture को ही नष्ट करती है", और क्षरण पहचानने के लिए पहले architecture होना भी चाहिए
  • मिशेल हाशिमोटो की अतिरिक्त व्याख्या: infrastructure में online systems को update करके उचित समय के भीतर सभी users पर MTTR लागू किया जा सकता है, लेकिन libraries, desktop software, mobile apps जैसी software श्रेणियों में, जिन्हें दूसरे लोग integrate करते हैं या सीधे चलाते हैं, यह तरीका काम नहीं करता
  • @tinygrad: हम ऐसे दौर में प्रवेश कर चुके हैं जहाँ AI की बात पूरी तरह गलत है या नहीं, यह समझने में 10 सेकंड नहीं बल्कि 20 मिनट लगते हैं, और संगठनों को वास्तविकता से जुड़ाव बनाए रखना होगा
  • @beyang: मौजूदा agent UX "LGTM(Looks Good To Me)" को सबसे कम resistance वाले रास्ते में बदल रहा है, और agents द्वारा बनाए गए विश्वसनीय दिखने वाले code की गति code review की verification समस्या को तत्काल खतरे में बदल रही है
  • @beh_zod: release करने का reward function छोटा होता है, जबकि लोग जो debt जमा कर रहे हैं उसे पहचानने में लगने वाला समय अधिकतर लोगों की attention span से बाहर होता है
  • @shipwithjay: जब engineering leadership counterfactual questions (इसे रोकने के लिए क्या सच होना चाहिए?) का जवाब नहीं दे पाती और चुप रह जाती है, तो वह एक लक्षण है
  • @chadfowler: इस विषय पर एक किताब लिखी जा रही है, और मूल बात है rigor को architecture और evaluation systems में फिर से स्थापित करना; अभी वह मौका है जब समय और लागत की कमी के कारण अब तक लागू न हो सकी best practices को वास्तव में लागू किया जा सकता है

लोगों के सवालों और विचारों पर Mitchell Hashimoto के जवाब

  • Q: "इसके बजाय क्या करना चाहिए?"
    • A: "सोचो (AI का उपयोग करो, लेकिन सोचो)"
  • Q: "AI को overhyped कहना" शायद उससे भी अधिक विक्षिप्त लक्षण हो सकता है
    • A: हर सांसारिक trend overhyped होता है, लेकिन यह उसे पूरी तरह नज़रअंदाज़ करने का कारण नहीं है
  • Q: "अगर अभी जो है उसे बचाने और जोखिम में छलांग लगाने में से एक चुनना हो, तो मैं दूसरा विकल्प चुनूँगा"
    • A: यह कोई द्विआधारी switch नहीं है

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

1 टिप्पणियां

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

  • लगता है AI architecture consulting एक बड़े रूप में उभरेगा, ठीक वैसे ही जैसे security breach response या data recovery experts जैसी high-value consulting
    पूरी तरह AI द्वारा लिखे गए systems इतनी जटिलता तक बढ़ सकते हैं कि इंसान उन्हें समझ ही न पाएँ, defect fix rate घटे जबकि प्रति defect token खपत बढ़े, और अंत में AI changes जितने bugs ठीक करें उससे ज़्यादा नए bugs पैदा करें, जिससे पूरा system अस्थिर हो जाए
    ऐसी अफरातफरी को cleanroom की तरह व्यवस्थित करके, core design principles निकालकर, और शायद फिर भी AI का उपयोग करके नए सिरे से rebuild करने की एक विशेष प्रक्रिया की ज़रूरत पड़ेगी
    भविष्य की software engineering शायद शुरुआत से ही ऐसी स्थिति से बचने वाले principles पर केंद्रित होगी, लेकिन जैसे पुरानी software engineering को भी stable design principles तक पहुँचने में उम्मीद से ज़्यादा समय लगा, वैसे ही इसे सीखने में 20 साल लग सकते हैं

    • “पूरी तरह AI द्वारा लिखे गए systems इतनी जटिलता तक बढ़ सकते हैं कि इंसान उन्हें समझ ही न पाएँ…” यह पढ़कर मज़ाक किया जा सकता है कि AI शायद सचमुच बड़े और जटिल software systems में human-level performance तक पहुँचने की कोशिश कर रहा है
    • एक non-technical दोस्त ने Claude से inventory management solution vibe coding करके hospital contract जीत लिया
      hospital ने तो IT department server access भी दे दिया, लेकिन Claude को connect नहीं कर पाने की वजह से उसे deployment का तरीका समझ नहीं आया और उसने काफी परेशान होकर संपर्क किया; app में data/state से जुड़े कुछ दिलचस्प issues भी लग रहे हैं
    • वह complexity शायद अनावश्यक verbose complexity होगी
      जैसे कोई Amazon का सामान unlimited free में घर मँगवा रहा हो; सिद्धांत में यह abundance वाली life लगती है, लेकिन व्यवहार में लगता है कि इंसान समृद्धि नहीं बल्कि किसी और चीज़ के नीचे दब जाएगा
    • इससे मूल Westworld फ़िल्म का यह dialogue याद आता है: “ये बहुत जटिल उपकरण हैं… लगभग जीवित प्राणियों जितने जटिल। कुछ मामलों में इन्हें दूसरे computers ने design किया है। हमें ठीक-ठीक नहीं पता कि ये कैसे काम करते हैं।”
      और उसका नतीजा क्या हुआ, यह सबको पता है
    • हाल ही में मैं एक ऐसे ही customer से मिला, जहाँ पूरा infrastructure और CI/CD vibe coded था
      हजारों lines की Github Actions में Kubernetes आधा implement कर दिया गया था, और उसे समझना असंभव था
      मुझे AI marketing पसंद नहीं, लेकिन एक experienced व्यक्ति को तेज़ी से आगे बढ़ाने वाले tool के रूप में यह उपयोगी है
      बस अगर आप expert नहीं हैं, तो AI हर काम के लिए जरूरत से ज़्यादा जटिल solution बनाने लगता है

  • लगता है वह AI के इस्तेमाल की बात कम, और इस बात की ज़्यादा कर रहा है कि कंपनियाँ और लोग decision-making और thinking को AI को outsource कर रहे हैं
    AI से code लिखवाना अपने-आप में AI psychosis या बुरी बात नहीं है, लेकिन अगर आप बस prompt डालकर AI की बात पर भरोसा कर लेते हैं, तो वह AI psychosis के काफ़ी करीब है
    Twitter पर finance वाले लोगों और VC को अक्सर देखा है कि किसी विषय पर खुद थोड़ा सोचने के बजाय वे ChatGPT screenshots से सोच और reasoning को replace कर देते हैं
    ideas, thinking और advice के लिए ये tools बहुत खराब हैं; ये बस pattern matching जैसा दिखने वाला output देते हैं, इसलिए अगर आप इनसे ideas पर बात करें तो ज़्यादातर वही सबसे generic bakwaas निकालते हैं
    दूसरी ओर, code writing जैसे कामों में, जहाँ pattern matching सचमुच मदद करती है, ये काफ़ी उपयोगी हैं; लेकिन thinking और decision-making इन्हें नहीं सौंपनी चाहिए

    • सही बात। मैं AI का बहुत ज़्यादा उपयोग कर रहा हूँ, और इसकी वजह से पहले से ज़्यादा मज़े से रोज़ काम कर रहा हूँ
      कुल मिलाकर highs ऊँचे हुए हैं और lows नीचे गए हैं, और ऊपर का वर्णन बहुत सटीक है
      इस पर मैंने यहाँ लिखा है: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
      आख़िरी लेख AI की मदद से किया गया एक जटिल बदलाव है, और यह दिखाता है कि मैं इसे समझदारी से कैसे approach करता हूँ
    • मुझे लगता है AI “सही जवाब” और “गलत जवाब” दोनों देता है
      यह लगभग हमेशा ऐसा text बनाता है जो तर्कसंगत रूप से सही लगता है, लेकिन उस text में कभी-कभी गलत implicit assumptions और decisions होते हैं जो उस particular use case पर फिट नहीं बैठते
      सचमुच सही solution बनाने के लिए problem definition सही होना चाहिए, और वह शायद solution बनाने से भी ज़्यादा कठिन हो सकता है
    • सोचता हूँ कि यह कितना अलग है उन कंपनियों से जो अपनी thinking Fortune या Inc जैसी magazines को outsource करती थीं
      या फिर किसी random consultant को
      क्या “AI ने कहा कि यह अच्छा idea है” सचमुच “हमने industry trend follow किया” से ज़्यादा बुरा है?
    • मेरे आसपास कई लोग पहले ही इस phase से गुज़र चुके हैं
      जब कोई अकेले ऐसा करता है, तो दोस्त और परिवार उसके अजीब व्यवहार या बातों की ओर इशारा करके कुछ हद तक उसे रोक लेते हैं
      लेकिन अगर employer leadership level पर ऐसा करने लगे, तो यह कितना बुरा हो सकता है, इसकी कल्पना करना मुश्किल है
      आप पर साथ देने का दबाव होगा या नौकरी जाने का डर होगा, और आपकी सोच को संतुलित करने वाले सिर्फ वे सहकर्मी होंगे जो असहमत हैं; लेकिन ऐसे लोगों के छोड़कर जाने या निकाले जाने की संभावना ज़्यादा है
      नौकरी बचानी है तो आपको उसी के हिसाब से चलना पड़ेगा
    • thinking को AI को outsource करने से जादुई speedup मिलता है
      agent आपकी जगह decisions लेता है, इसलिए काम agent की speed से चलता है, और अक्सर वह बिना कुछ बोले decisions लेकर आखिर में बस “योजना यह है” जैसा final output देता है
      उसे ठीक से review करने के लिए आपको problem को गहराई से समझना पड़ता है, यानी वापस human speed पर आना पड़ता है; इसलिए अंत में आप बस ऊपर-ऊपर देखकर approve कर देते हैं
      असली बात यह है कि कौन-से decisions outsource करने हैं, यह सचेत और सावधानी से तय किया जाए
      इसके लिए आपको धीमा होना पड़ता है; इससे बढ़ा-चढ़ाकर बताए जाने वाले 10x vibe coding gains कम हो जाते हैं, लेकिन बदले में आप ज़्यादा involved रहते हैं और cognitive debt भी कम जमा होता है
      array को कैसे iterate करना है, एक call के output को दूसरी call के input से कैसे मिलाना है जैसी boring decisions agents को दे सकते हैं
      असली decisions पहले से लेकर spec में डालने चाहिए: boundaries, API, core data structures, systems और responsibilities, error handling, security और privacy की सख्त constraints तय करनी चाहिए
      agent को यह भी कहना चाहिए कि अगर चीज़ें ambiguous हों तो वह रुक जाए; और एक अच्छा engineer बिना side effects के 2~3x speedup पा सकता है

  • शायद यह software engineering को सचमुच एक engineering discipline बना दे
    अभी prompters पूरी company infrastructure खड़ी कर रहे हैं
    मैं निजी तौर पर एक ऐसे व्यक्ति को जानता हूँ जिसने company database को नए Postgres version पर migrate किया; आखिरकार वह सफल तो हुआ, लेकिन उसके process का वर्णन सुनकर दाँत पीसने का मन हुआ
    वह कुछ ऐसा था जैसे: “मैंने server पर पेट्रोल डालकर सिगरेट जला दी, लेकिन चिंता मत करो, basement में fire extinguisher मिल गया। gauge खाली दिखा रहा है, पर हिलाने पर अभी भी अंदर liquid की आवाज़ आती है”
    अगर वह company छोड़ दे, तो उस DB infrastructure को maintain करने के लिए एक और भी ज़्यादा आत्मविश्वासी prompter चाहिए होगा

  • यह पोस्ट कहती है कि उन लोगों से बहस नहीं की जा सकती जो कहते हैं, “bugs deploy करना ठीक है, agents उन्हें इंसानों की पहुँच से बाहर की speed और scale पर ठीक कर सकते हैं”
    लेकिन सबसे ऊपर का जवाब ही तुरंत “लेकिन agents बहुत तेज़ हैं” कहने का उदाहरण है

    • अगर tool release से पहले bugs ठीक करने लायक पर्याप्त अच्छा और तेज़ नहीं है, तो release के बाद उसके इतनी आसानी से catch up कर लेने पर कोई कैसे भरोसा कर सकता है, समझ नहीं आता
      शायद मान लिया जाता है कि codebase और features के दोगुना होने का फायदा bugs के दोगुना होने के नुकसान से बड़ा है
      कम-से-कम इस quarter की investor news में तो अच्छा लगेगा
    • यह भी नहीं समझ आता कि fixes में bugs नहीं हैं, यह कैसे पता चलेगा
      हो सकता है आप बस और ज़्यादा कचरा deploy करते जाएँ; feedback loop फिर customer है क्या?
    • अगर यह इतना तेज़ है, तो deploy से पहले bugs जल्दी ठीक कर दो
    • AI boom के शुरुआती दिनों में मैं एक दोस्त से कह रहा था कि AI पर हद से ज़्यादा निर्भरता तरह-तरह की तबाहियाँ लाएगी
      जवाब मिला, “यह game theory है। कोई-न-कोई तो करेगा, इसलिए तुम्हें भी करना पड़ेगा। इतना बुरा नहीं हो सकता।”
      logic उपयोगी है, लेकिन risk को नज़रअंदाज़ करना अलग बात है
      यह मान लेना कि बहुत तेज़ी से चलकर सब तोड़ देने से आखिर में अच्छा नतीजा निकलेगा, खतरनाक है
      यह AI लहर मुझे सही दिशा में जाती नहीं दिख रही और मुझे पसंद भी नहीं है
    • व्यवहारिक रूप से मेरा business bugs के बावजूद ज़्यादा efficiency के साथ चलता रहा है
      मुझे ज़रूरी नहीं लगता कि psychosis वाली side हमेशा “हमारी side” ही हो

  • मैं एक बहुत बड़ी company में काम करता हूँ, और हमारी company हमेशा modernization और नई technology adoption में glacier जैसी धीमी रही है
    लेकिन अजीब बात यह है कि अब वही शायद competitive advantage बन जाए

    • यह तो literally Battlestar Galactica की plotline है
      life art की नकल कर रही है
    • जर्मनी में काम करके मुझे कभी इतनी खुशी नहीं हुई
      पहले मैं मज़ाक करता था कि यहाँ अब भी fax है, लेकिन मुझे अंदाज़ा नहीं था कि ऐसी craze से दूर culture में काम करना इतना राहत देने वाला होगा
      HN पढ़ते हुए लगता है जैसे token maximizers और AI psychosis के शिकार लोगों की Alice's Wonderland में घुस गए हों
      यहाँ मैं सचमुच एक भी ऐसे व्यक्ति को नहीं जानता जिसे इस तरह काम करने पर मजबूर किया जा रहा हो

  • अगर आपकी भी यही feeling है, तो शायद नया CLI tool Burn, Baby, Burn (those tokens) पसंद आए: https://github.com/dtnewman/burn-baby-burn/tree/main
    Show HN यहाँ है: https://news.ycombinator.com/item?id=48151287

  • इससे Rich Hickey की Simple Made Easy और Clojure बनाते समय अपनाया गया उनका approach याद आता है
    LLMs के पूरे program generate करने से पहले भी, complex frameworks developers को program का शुरुआती version बहुत तेज़ी से बनाने देते थे, लेकिन उसकी कीमत यह होती थी कि उन्हें समझना मुश्किल हो जाता था और इसलिए debug और modify करना भी कठिन होता था
    कुछ लोग दाँव लगा रहे हैं कि चाहे AI कितने भी उलझे और जटिल programs लिख दे, AI हमेशा इतना smart होगा कि उन्हें debug, maintain और modify कर सके
    मुझे इस पर इतना भरोसा नहीं है

  • AI psychosis, AI उपयोग के विरोध की स्थिति नहीं है
    मैं रोज़ AI coding tools का उपयोग करता हूँ, लेकिन AI tools के पास भविष्य की कोई अवधारणा नहीं है
    स्थिर systems बनाने के लिए हम लंबे समय से engineer की उस स्वार्थी सोच पर निर्भर रहे हैं जो सोचता है, “अगर यह production में टूट गया तो मैं इसे ठीक नहीं कर पाऊँगा, और मुझे रात 3 बजे जगाया जाएगा”
    CPAN पर perfect library खोजकर खुद काम न करने की सामान्य आलस भी रही है, और कभी-कभी खुद लिखने से ज़्यादा समय library ढूँढ़ने में लग जाता था
    मैंने AI tools से हजारों lines का code लिखवाकर production में डाला है, और यह ज़्यादातर स्वाभाविक लगा, क्योंकि 2017 से मैं लोगों से कहता आया हूँ कि सारा code खुद type मत करो, उसे लिखवाओ, और tests में ऐसे traps लगाओ जो खराब code पकड़ लें
    लेकिन AI एक काम नहीं करता: कम code लिखना: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/

    • शायद यह prompt की वजह से हो, लेकिन मेरा coding agent Opus 4.7 पर आधारित है और वह अक्सर कहता है, “यह वही तरह की चीज़ है जो 6 महीने बाद रात 2 बजे फटेगी”

  • bug reports तब भी कम हो जाती हैं जब लोगों का यह भरोसा टूट जाता है कि उन्हें ठीक किया जाएगा
    क्योंकि bug report करना अक्सर काफ़ी बड़ा time investment होता है
    किसी group या company पर trust टूटने पर ऐसा काफी बार होता है

    • इसके ऊपर यह भी जोड़ लें कि वास्तव में दर्ज होने वाली reports का बड़ा हिस्सा शायद AI द्वारा generated या rewritten हो
      इसलिए उनके गलत report होने की संभावना ज़्यादा है, और कुछ बातें गलत भी हो सकती हैं
      यानी हर दिशा से हमला हो रहा है
      अभी तो adversarial tactics की बात भी शुरू नहीं हुई
      अगर नैतिकता न हो, तो agents से competitors पर fake bug reports की बौछार कराने से बेहतर तरीका क्या होगा?
    • बस AI से bug report करवा दो
      समस्या हल
    • सही। लेकिन यह समस्या सिर्फ AI-driven projects तक सीमित नहीं है
      Mitchell ने जो देखा, उसमें से काफ़ी कुछ, शायद सब कुछ, AI के बिना भी हो सकता है

  • मुझे लगता है मैं एक बहुत अजीब स्थिति में हूँ
    code लिखने के अनुभव और practice में AI जो बदलाव ला रहा है, वह मुझे इतना नापसंद है कि कभी-कभी लगता है computer से जुड़े काम के अलावा कुछ भी करना बेहतर होगा, लेकिन साथ ही मुझे यह भी लगता है कि ये tools बहुत शक्तिशाली हैं और लगातार बेहतर हो रहे हैं
    Mitchell की बात वाजिब है। ऐसे tools सड़ी हुई नींव अंदर ले आते हैं और शायद पूरी संरचना गिरने के बाद ही वह दिखाई दे
    मैं उस स्थिति में नहीं होना चाहता जहाँ जवाबदेही मेरी हो लेकिन पहले की तरह codebase की गहरी समझ मेरे पास न हो
    लेकिन इंसान भी बहुत पहले से code में subtle मगर घातक bugs डालते आए हैं
    इसलिए इसका बड़ा हिस्सा अब भी एक खुला अनुभवजन्य सवाल लगता है
    क्या हम ऐसे systems बहुत देखेंगे जो उन तरीकों से बुरी तरह टूटते हैं जिनकी पहले कल्पना नहीं थी? कुछ हद तक शायद हाँ
    साथ ही, क्या हम इससे यह सीखेंगे कि specs और verification की ओर ज़्यादा बढ़ना चाहिए? पता नहीं
    जो भी हो, systems बनाने का यह तरीका बीच में टक्करों के बावजूद अब टाला नहीं जा सकता
    anti-AI camp में भी अपनी तरह की एक reactionary psychosis दिखती है
    मैं AI में फँसना नहीं चाहता, लेकिन इन tools का इस्तेमाल करके जो अनुभव हुआ है उसे भी झुठला नहीं सकता
    काश ऐसी जगहें और होतीं जहाँ AI पर ऐसी व्यावहारिक लेकिन नकारात्मक चर्चा हो सके
    Mitchell अच्छा developer है, इसका एक कारण यह भी है