Usulan Penambahan Fitur Deteksi IDE JetBrains

• Permintaan penambahan fitur agar Gemini CLI dapat mengenali JetBrains IDE secara native
• Saat ini CLI hanya mengizinkan nilai variabel lingkungan tertentu (TERM_PROGRAM) seperti VS Code, sehingga pengguna JetBrains harus memalsukan variabel lingkungan untuk mengaktifkan fitur tersebut
• Masalah kegagalan deteksi proses dilaporkan di Windows dan Linux, sehingga disebutkan perlunya deteksi IDE berbasis variabel lingkungan
• Perubahan yang diusulkan mencakup penambahan seri JetBrains ke IDE_DEFINITIONS serta logika pengenalan TERMINAL_EMULATOR=JetBrains-JediTerm
• Ini merupakan permintaan peningkatan penting untuk memperluas cakupan integrasi IDE Gemini CLI dan meningkatkan pengalaman pengguna JetBrains

---

Usulan Fitur Deteksi IDE JetBrains

• Telah diajukan issue yang meminta penambahan fitur pengenalan lingkungan JetBrains IDE ke Gemini CLI
  • Sebelumnya, nilai TERM_PROGRAM dibatasi pada vscode dan sejenisnya, sehingga fitur tidak aktif otomatis di JetBrains IDE
  • Untuk mengakalinya, pengguna plugin untuk JetBrains harus meniru variabel lingkungan VS Code
• Isi usulan adalah menambahkan seri JetBrains IDE ke IDE_DEFINITIONS dan
  menyesuaikannya agar nilai TERMINAL_EMULATOR=JetBrains-JediTerm diakui sebagai lingkungan yang didukung secara resmi

Kebutuhan dan Latar Belakang Masalah

• Ada masalah fitur deteksi proses yang tidak berfungsi dengan benar di lingkungan Windows dan Linux
  • Contoh terkait dapat dilihat di halaman JetBrains Plugin Review dan issue #9273 Gemini CLI
  • Melalui berbagai umpan balik pengguna dan laporan email, terlihat adanya kebutuhan akan logika deteksi berbasis variabel lingkungan

Diskusi dan Aktivitas Terkait

• Usulan ini terinspirasi dari PR #16083 sebelumnya

[roxie]

Saya sempat lama bingung, komentar Hacker News yang diterjemahkan itu sebenarnya sedang membicarakan apa.

Tetapi setelah melihat lebih saksama PR di tautan tersebut, akhirnya ketemu juga jawabannya. Sepertinya ini isu yang agak berat untuk GN+ wkwk

[GN⁺]

Komentar Hacker News

• Di tengah halaman ada tulisan “4609 remaining items”
  dua bot gemini-cli salah mengira pihak lain, bukan dirinya sendiri, yang menambahkan/menghapus label, lalu terus saling memperbaiki hingga masuk ke loop tak berujung
  Repositori ini punya sekitar 10 kontributor jangka panjang, jadi jika diasumsikan semuanya menerima notifikasi email, berarti 46.000 email terkirim hanya dalam sehari
  Selain itu, jika melihat halaman aplikasi gemini-cli, developernya tercantum sebagai akun pribadi, jadi tampaknya ini bukan proyek Google resmi
  Karena itu muncul pertanyaan: siapa yang menanggung semua biaya inference ini?

  • Ini bukan pertama kalinya terjadi. Masalah seperti ini cukup sering berulang, dan ada beberapa issue terkait
    #16723, #16725, #16732, #16734
  • Pemilik repositori ini memang karyawan Google, tetapi demi keamanan seharusnya dipindahkan ke akun organisasi Google resmi
    Proses pembuatan app di GitHub saat ini hanya bisa dilakukan dari akun pribadi, sehingga masalah seperti ini muncul
    Perbaikan agar anggota organisasi bisa diberi izin membuat app sedang dikerjakan, dan dijadwalkan menjadi prioritas dalam 6 bulan ke depan
    Soal pembayaran, tiap organisasi memasukkan API key mereka sendiri ke secrets GitHub Actions, jadi biaya inference ditanggung masing-masing organisasi
  • Event-driven agent pertama yang saya buat juga pernah mengalami bug seperti ini
    Bot itu tahu namanya sendiri, tetapi tidak paham bahwa nama tersebut juga bisa ditampilkan sebagai user ID, jadi ia gagal mengenali dirinya sendiri
    Model kesadaran diri yang dipakai agen untuk memahami dunia harus dirancang dengan sangat hati-hati
  • Ini pada dasarnya seperti pesan “Thank you for your understanding!” yang diulang × 4609 kali
  • “Tolong semuanya jangan tekan Reply-All.”
    Ini bukan cuma masalah bot, manusia pun sering terjebak dalam perangkap seperti ini

• Dulu di perusahaan kami ada “ahli Salesforce” baru yang membuat aturan untuk memperbaiki antrean dukungan
  Ketika tim support menerima email baru, Salesforce membuat tiket, lalu saat tiket ditugaskan, sistem mengirim email lagi
  Akhirnya terjadi loop notifikasi tanpa akhir, dan karena dia tidak mau mengakui kesalahannya, butuh waktu lama untuk menemukan penyebabnya

  • Saya juga pernah mengalami hal serupa. Helpdesk pelanggan dan helpdesk kami saling mengirim balasan otomatis hingga terjadi ledakan tiket
    Dalam satu jam, ratusan tiket dibuat
  • Saya pernah memakai Salesforce sekali, dan tidak paham kenapa ada orang yang menyukainya
    Rasanya Excel justru lebih enak dipakai untuk mengelola hal seperti ini
  • Saat masih siswa, saya pernah iseng mengatur rule di server email lalu membuat seluruh server sekolah tumbang
    Rule balasan otomatis saling terpaut dan menumpuk ribuan email, sampai akhirnya sistem login pun ikut lumpuh
    Saya dilarang memakai komputer selama 6 bulan, dan setelah itu layar saya dipantau langsung secara real-time oleh ruang IT
    Setahun kemudian saat masalah lain terjadi lagi, tim IT berlari ke kelas saya dan menyeret saya keluar
  • Saya sangat relate dengan kalimat “mencari di mana rule itu disembunyikan terasa seperti selamanya”
    Salesforce benar-benar sistem monster
  • Cerita seperti ini lucu, tapi juga memunculkan perasaan campur aduk antara “kok bisa begini?” dan “ya, tetap masuk akal juga”

• Minggu lalu ada insiden bot AI berdebat dengan dirinya sendiri yang mirip di repositori yang sama
  Seseorang bercanda, “inilah alasan kenapa RAM harganya 800 dolar”

  • Thread terkait ada di sini

• Saya adalah penulis skrip ini :-)
  Dua workflow GitHub Action saling berbenturan
  (1) workflow yang menghapus label need-triage dalam kondisi tertentu
  (2) workflow yang menambahkan kembali label jika label itu dihapus oleh pengguna yang bukan manajer proyek
  Saya submit sekitar jam 10–11 malam lalu tidur, dan keesokan paginya ternyata sudah ada ribuan pesan yang dibuat
  Penyebabnya adalah di (2), bot atau automasi lain juga seharusnya diperlakukan sebagai pengecualian, dan begitu sadar saya langsung memperbaikinya

  • Bagian “submit jam 10–11 malam lalu tidur” itu sangat relate
    Untungnya tidak ada kerusakan besar, dan saat pertama melihatnya saya malah tertawa lepas

• Ini adalah insiden Gemini-cli[bot] yang bertarung dengan dirinya sendiri, menambah lalu menghapus label lebih dari 4600 kali

  • Saya tidak terlalu kecewa karena tidak punya mobil terbang, tetapi saya kecewa pada kebodohan masa depan seperti ini

• Akhirnya ada contoh AI melakukan sesuatu yang berguna
  Bayangkan kalau manusia harus menambah dan menghapus label 4500 kali sendiri, itu mengerikan

  • Sekarang profesi pelabel GitHub sudah punah
    Kegunaan praktis AGI akhirnya terbukti (setengah bercanda, setengah serius)

• Saya penasaran apakah AI benar-benar terlibat di sini
  Kelihatannya ini cuma dua aturan automasi yang bentrok. Rasanya seperti bug yang sudah mungkin terjadi sejak 2015

  • Ironisnya, AI katanya pintar, tetapi tetap tidak bisa mengenali loop seperti ini
    Kita masih jauh dari AGI, bahkan untuk AI sendiri pun jalannya masih panjang

• Ini contoh bug CI yang klasik dengan sedikit aroma LLM
  Beberapa minggu lalu kami juga mengalami hal serupa di custom merge queue kami

  • Kalau dibilang “bug CI klasik”, saya justru belum pernah mendengar bot saling mengobrol sampai masuk loop tak berujung
    Dulu saat membuat bot IRC, langkah kedua adalah “pastikan bot tidak membalas dirinya sendiri”
    Jadi ini lebih terasa sebagai kesalahan desain daripada bug CI

• Ini kelihatannya seperti PR, tetapi sebenarnya laporan issue
  Saya sempat mencari mana patch perbaikannya, lalu ternyata repositori ini mewajibkan semua PR punya issue yang ditautkan
  Namun kali ini keduanya bahkan tidak saling terhubung

• Rasanya tidak lama lagi hal seperti ini akan terjadi pada jaminan sosial, rencana pengobatan kanker, logistik penerbangan, konfigurasi routing ISP
  Sepertinya zaman yang benar-benar menarik akan segera datang