JetBrains IDE डिटेक्शन फीचर जोड़ने का प्रस्ताव

• Gemini CLI में JetBrains IDE को native रूप से पहचानने की सुविधा जोड़ने का अनुरोध
• अभी CLI केवल VS Code जैसे खास environment variable (TERM_PROGRAM) मानों को स्वीकार करता है, इसलिए JetBrains उपयोगकर्ताओं को फीचर सक्रिय करने के लिए environment variable बदलकर दिखाना पड़ता है
• Windows और Linux में process detection विफल होने की समस्या रिपोर्ट हुई है, इसलिए environment variable-आधारित IDE detection की ज़रूरत स्पष्ट की गई है
• प्रस्तावित बदलाव में IDE_DEFINITIONS में JetBrains श्रृंखला जोड़ना और TERMINAL_EMULATOR=JetBrains-JediTerm को पहचानने वाली logic शामिल है
• यह Gemini CLI के IDE integration के दायरे का विस्तार करने और JetBrains उपयोगकर्ता अनुभव को बेहतर बनाने के लिए एक महत्वपूर्ण सुधार अनुरोध है

---

JetBrains IDE डिटेक्शन फीचर प्रस्ताव

• Gemini CLI में JetBrains IDE environment पहचान सुविधा जोड़ने का अनुरोध करने वाला issue दर्ज किया गया
  • पहले TERM_PROGRAM मान vscode आदि तक सीमित होने के कारण JetBrains IDE में फीचर अपने आप सक्रिय नहीं होता था
  • इसे bypass करने के लिए JetBrains plugin उपयोगकर्ताओं को VS Code environment variable की नकल करनी पड़ती थी
• प्रस्ताव में JetBrains IDE श्रृंखला को IDE_DEFINITIONS में जोड़ने और
  TERMINAL_EMULATOR=JetBrains-JediTerm मान को आधिकारिक रूप से समर्थित environment के रूप में पहचानने के लिए संशोधन करना शामिल है

आवश्यकता और समस्या की पृष्ठभूमि

• Windows और Linux environment में process detection फीचर के ठीक से काम न करने की समस्या है
  • संबंधित उदाहरण JetBrains Plugin Review पेज और Gemini CLI के issue #9273 आदि में देखे जा सकते हैं
  • कई उपयोगकर्ता फीडबैक और ईमेल रिपोर्ट के आधार पर environment variable-आधारित detection logic की आवश्यकता सामने आई है

संबंधित चर्चा और गतिविधि

• यह प्रस्ताव पहले के PR #16083 से प्रेरित है

[roxie]

काफ़ी देर तक मैं यह सोचकर पूरी तरह उलझन में था कि अनुवाद किए गए Hacker News कमेंट आख़िर कहना क्या चाह रहे हैं,

फिर लिंक में दिए गए PR को ध्यान से देखा तो जवाब मिल गया। लगता है यह GN+ के लिए थोड़ा मुश्किल issue था, haha

[GN⁺]

Hacker News की राय

• पेज के बीच में “4609 remaining items” लिखा दिख रहा था
  स्थिति यह थी कि दो gemini-cli bots एक-दूसरे के बारे में यह गलत समझ बैठे कि सामने वाले ने, न कि खुद उन्होंने, label जोड़ा/हटाया है, और उसे ठीक करने की कोशिश में वे infinite loop में फँस गए
  इस repository में लंबे समय से योगदान देने वाले लगभग 10 लोग हैं, और अगर मान लें कि सभी को email notifications मिलती हैं, तो एक ही दिन में 46,000 emails भेजी गई होंगी
  और gemini-cli app page देखने पर लगता है कि developer एक personal account है, इसलिए यह शायद कोई official Google project नहीं है
  तो फिर सवाल उठता है कि इस पूरे inference cost का भुगतान किसने किया होगा

  • यह पहली बार नहीं हुआ। यह काफ़ी बार दोहराई जाने वाली समस्या है, और इससे जुड़े कई issues हैं
    #16723, #16725, #16732, #16734
  • repository के owner एक Google employee हैं, लेकिन सुरक्षा के लिए इसे official Google organization account में migrate किया जाना चाहिए
    GitHub का app creation process अभी केवल personal accounts पर ही संभव है, इसलिए ऐसी समस्या पैदा हुई
    organization members को app creation permission देने के लिए सुधार का काम चल रहा है, और इसे 6 महीनों के भीतर प्राथमिकता के साथ किया जाना है
    billing के मामले में, हर organization अपनी API key को GitHub Actions secrets में डालकर इस्तेमाल करती है, इसलिए inference cost हर organization खुद उठाती है
  • मैंने जो पहला event-driven agent बनाया था, उसमें भी यही bug था
    bot अपना नाम जानता था, लेकिन उसे यह नहीं पता था कि वही नाम user ID के रूप में भी दिख सकता है, इसलिए वह खुद को पहचान नहीं पाया
    agent दुनिया को कैसे समझता है, उसके self-awareness model को बहुत सावधानी से design करना पड़ता है
  • मतलब “Thank you for your understanding!” × 4609 वाला message बार-बार दोहराया गया
  • “सब लोग प्लीज़ Reply-All मत दबाइए।”
    यह सिर्फ bots की समस्या नहीं है, इंसान भी अक्सर इस जाल में फँसते हैं

• पहले हमारी कंपनी में एक नए आए “Salesforce expert” ने support queue सुधारने के नाम पर एक rule बनाया था
  support team को नया email मिलता तो Salesforce में ticket बनता, और ticket assign होते ही फिर से email भेजा जाता
  आखिरकार एक infinite notification loop बन गया, और उसने अपनी गलती मानने से इनकार किया, इसलिए वजह ढूँढने में काफ़ी समय लग गया

  • मेरा भी ऐसा ही अनुभव रहा है। customer के helpdesk और हमारे helpdesk ने एक-दूसरे को auto-replies भेजना शुरू कर दिया था, और ticket flood जैसी स्थिति बन गई
    एक घंटे में सैकड़ों tickets बन गए थे
  • मैंने एक बार Salesforce इस्तेमाल किया था, और समझ नहीं आया कि किसी को यह क्यों पसंद आएगा
    लगा कि इससे अच्छा तो Excel में manage करना है
  • छात्र जीवन में मैंने email server पर मज़ाक में कुछ rules सेट कर दिए थे, और पूरे स्कूल का server down हो गया था
    auto-reply rules एक-दूसरे से टकरा गए, हज़ारों mails जमा हो गए, और आख़िर में login system तक ठप हो गया
    मुझे 6 महीने तक computer इस्तेमाल करने से प्रतिबंधित कर दिया गया, और उसके बाद IT room में मेरी screen real time में monitor की जाती थी
    एक साल बाद फिर कोई समस्या हुई तो IT team मेरी classroom तक दौड़कर आई और मुझे पकड़कर ले गई थी
  • “वह rule कहाँ छिपा है, इसे ढूँढने में जैसे हमेशा लग गया” — इस बात से पूरी तरह सहमत हूँ
    Salesforce सच में एक राक्षसी system है
  • ऐसी कहानियाँ मज़ेदार भी लगती हैं, लेकिन साथ ही “ऐसा कैसे हो सकता है?” और “फिर भी समझ आता है” जैसी दोहरी भावना भी पैदा करती हैं

• पिछले हफ़्ते भी उसी repository में ऐसा ही AI bot self-argument वाला मामला हुआ था
  किसी ने मज़ाक में कहा, “इसी वजह से RAM की कीमत 800 dollars है”

  • उससे जुड़ा thread यहाँ है

• मैं इस script का author हूँ :-)
  दो GitHub Action workflows आपस में टकरा गए थे
  (1) कुछ conditions में need-triage label हटाने वाला workflow
  (2) अगर project maintainer न होने वाला user label हटाए तो उसे फिर से जोड़ने वाला workflow
  मैंने इसे रात 10–11 बजे submit किया और सो गया, और सुबह उठकर देखा तो हज़ारों messages बन चुके थे
  वजह यह थी कि (2) में दूसरे bots या automations को भी exception के तौर पर handle किया जाना चाहिए था, और पता चलते ही मैंने तुरंत fix कर दिया

  • “रात 10–11 बजे submit किया और सो गया” — यह बात बहुत relatable लगी
    अच्छी बात यह रही कि कोई बड़ा नुकसान नहीं हुआ, और पहली बार देखते ही हँसी छूट गई

• यह वह घटना है जिसमें Gemini-cli[bot] ने खुद से लड़ते हुए label जोड़ना-हटाना 4600 से ज़्यादा बार दोहराया

  • मुझे उड़ने वाली कारों के न होने का अफ़सोस नहीं है, लेकिन भविष्य की ऐसी मूर्खताओं से निराशा ज़रूर होती है

• आख़िरकार AI ने कुछ उपयोगी काम किया
  सोचिए, अगर किसी इंसान को खुद 4500 बार label लगाना-हटाना पड़ता तो कितना डरावना होता

  • अब GitHub labeler जैसी नौकरी खत्म हो गई
    इससे AGI की उपयोगिता साबित हो गई है (आधा मज़ाक, आधा सच)

• यहाँ सच में AI शामिल था भी या नहीं, यह जानने की जिज्ञासा है
  ऊपर से तो यह बस दो automation rules के टकराने जैसा लगता है। 2015 में भी संभव होने वाला bug जैसा

  • विडंबना यह है कि AI को बहुत स्मार्ट कहा जाता है, फिर भी वह ऐसे loops पहचान नहीं पाता
    अभी AGI बहुत दूर है, सच कहें तो AI को ही अभी लंबा रास्ता तय करना है

• यह एक क्लासिक CI bug है, बस उसमें LLM की हल्की-सी खुशबू जुड़ गई है
  कुछ हफ़्ते पहले हमारे custom merge queue में भी ऐसा ही कुछ हुआ था

  • “क्लासिक CI bug” तो ठीक है, लेकिन bots का एक-दूसरे से infinite conversation loop में फँसना मैंने पहली बार सुना है
    पहले जब IRC bots बनाते थे, तब दूसरा step ही यह होता था कि उन्हें खुद को reply करने से रोका जाए
    इसलिए यह CI bug से ज़्यादा design mistake जैसा लगता है

• यह PR जैसा दिखता है, लेकिन असल में issue report है
  मैं सोच रहा था fix patch कहाँ है, फिर पता चला कि इस repository में हर PR के साथ linked issue होना ज़रूरी है
  लेकिन इस बार तो दोनों आपस में linked भी नहीं थे

• लगता है कि जल्द ही ऐसी चीज़ें social security payments, cancer treatment plans, airline logistics, ISP routing configs जैसी जगहों पर भी होंगी
  आगे वाकई दिलचस्प समय आने वाला है