Propuesta para agregar detección de IDEs de JetBrains

• Solicitud para agregar una función en Gemini CLI que reconozca de forma nativa los IDEs de JetBrains
• Actualmente, el CLI solo permite valores de ciertas variables de entorno (TERM_PROGRAM) como VS Code, por lo que los usuarios de JetBrains deben falsificar variables de entorno para activar la función
• Se ha reportado un problema de fallo en la detección de procesos en Windows y Linux, por lo que se indica que es necesaria una detección de IDE basada en variables de entorno
• El cambio propuesto incluye agregar la serie JetBrains a IDE_DEFINITIONS e incorporar la lógica para reconocer TERMINAL_EMULATOR=JetBrains-JediTerm
• Es una solicitud de mejora importante para ampliar el alcance de la integración de IDEs de Gemini CLI y mejorar la experiencia de los usuarios de JetBrains

---

Propuesta de detección de IDEs de JetBrains

• Se registró un issue solicitando agregar a Gemini CLI una función para reconocer entornos de IDE de JetBrains
  • Hasta ahora, el valor de TERM_PROGRAM estaba limitado a opciones como vscode, por lo que en los IDEs de JetBrains la función no se activaba automáticamente
  • Para sortear esto, los usuarios del plugin para JetBrains tenían que imitar las variables de entorno de VS Code
• La propuesta consiste en agregar la serie de IDEs de JetBrains a IDE_DEFINITIONS y
  modificarlo para que el valor TERMINAL_EMULATOR=JetBrains-JediTerm sea reconocido como un entorno oficialmente compatible

Necesidad y contexto del problema

• Existe un problema por el cual la detección de procesos no funciona correctamente en entornos Windows y Linux
  • Casos relacionados pueden verse en la página de revisión del plugin de JetBrains y en el issue #9273 de Gemini CLI, entre otros
  • A través de varios comentarios de usuarios y reportes por correo electrónico, se confirmó la necesidad de una lógica de detección basada en variables de entorno

Discusiones y actividad relacionadas

• Esta propuesta estuvo inspirada en el anterior PR #16083

[roxie]

Me quedé un buen rato totalmente desconcertado tratando de entender qué demonios querían decir los comentarios traducidos de Hacker News,

pero al revisar con detalle el PR del enlace, por fin encontré la respuesta. Parece que fue un tema un poco pesado para GN+ jaja

[GN⁺]

Comentarios en Hacker News

• En medio de la página aparecía la frase “4609 remaining items”
  Dos bots de gemini-cli creyeron por error que el otro, y no ellos mismos, estaba agregando o quitando etiquetas, y al intentar corregirse mutuamente cayeron en un bucle infinito
  En este repositorio hay unos 10 colaboradores de largo plazo, y si asumimos que todos reciben notificaciones por correo, eso significa que en un solo día se enviaron 46,000 correos
  Además, al ver la página de la app gemini-cli, el desarrollador figura como una cuenta personal, así que no parece ser un proyecto oficial de Google
  Entonces surge la duda de quién pagó todo ese costo de inference

  • No es la primera vez que pasa algo así. Es un problema que se repite con bastante frecuencia, y hay varios issues relacionados
    #16723, #16725, #16732, #16734
  • El dueño del repositorio es un empleado de Google, pero por seguridad debería transferirse a una cuenta oficial de organización de Google
    El proceso actual de GitHub para crear apps solo permite hacerlo desde cuentas personales, y eso genera este tipo de problemas
    Ya se está trabajando en una mejora para permitir dar permisos de creación de apps a miembros de la organización, y se planea tratarlo como prioridad dentro de los próximos 6 meses
    En cuanto al cobro, cada organización usa su propia API key en los secrets de GitHub Actions, así que el costo de inference lo asume cada organización
  • El primer event-driven agent que hice también tuvo este bug
    El bot conocía su propio nombre, pero no sabía que ese nombre también podía mostrarse como ID de usuario, así que no lograba reconocerse a sí mismo
    Hay que diseñar con mucho cuidado el modelo de autoconciencia con el que el agente entiende el mundo
  • Básicamente fue el mensaje “Thank you for your understanding!” repetido × 4609
  • “Por favor, que nadie le dé a Reply-All.”
    Esto no es solo un problema de bots, los humanos también caen en esa trampa muy seguido

• Hace tiempo, un nuevo “experto en Salesforce” que llegó a nuestra empresa creó una regla para mejorar la cola de soporte
  Cuando el equipo de soporte recibía un correo nuevo, Salesforce creaba un ticket, y cuando el ticket se asignaba, volvía a mandar otro correo
  Al final se generó un bucle infinito de notificaciones, y como él no admitía el error, tomó bastante tiempo encontrar la causa

  • Yo también viví algo parecido. El helpdesk del cliente y nuestro helpdesk se mandaban respuestas automáticas entre sí y se desató una avalancha de tickets
    En una hora se crearon cientos de tickets
  • Usé Salesforce una vez y nunca entendí por qué a alguien le podría gustar
    Me dio la impresión de que sería mejor administrarlo todo en Excel
  • Cuando era estudiante, una vez configuré reglas en el servidor de correo como broma, y terminé tirando el servidor de toda la escuela
    Las reglas de respuesta automática se engancharon entre sí, se acumularon miles de correos y al final hasta el sistema de login quedó paralizado
    Me prohibieron usar computadoras durante 6 meses, y después de eso en el departamento de TI monitoreaban mi pantalla en tiempo real
    Un año después, cuando volvió a surgir otro problema, el equipo de TI salió corriendo a mi salón y me sacó de ahí
  • Me identifiqué totalmente con eso de que “tomó una eternidad encontrar dónde estaba escondida esa regla”
    Salesforce de verdad es un sistema monstruoso
  • Estas historias dan risa, pero al mismo tiempo provocan esa sensación ambivalente de “¿cómo pudo pasar eso?” y “bueno, igual lo entiendo”

• La semana pasada hubo un incidente parecido de auto-discusión entre bots de IA en el mismo repositorio
  Alguien bromeó diciendo “por esto la RAM cuesta 800 dólares”

  • El hilo relacionado está aquí

• Yo soy el autor de este script :-)
  Chocaron dos workflows de GitHub Action
  (1) un workflow que quita la etiqueta need-triage bajo ciertas condiciones
  (2) un workflow que vuelve a agregar la etiqueta si alguien que no es project maintainer la quita
  Lo mandé entre las 10 y las 11 de la noche y me fui a dormir, y cuando desperté había miles de mensajes
  La causa fue que en (2) también había que tratar como excepción a otros bots o automatizaciones, y lo corregí apenas me di cuenta

  • Sentí demasiada empatía con la parte de “lo mandé entre las 10 y las 11 de la noche y me fui a dormir”
    Por suerte no hubo un daño grave, y cuando lo vi por primera vez me dio risa

• Este fue el incidente en el que Gemini-cli[bot] estuvo peleando consigo mismo, agregando y quitando etiquetas más de 4600 veces

  • No me molesta que no existan los autos voladores, pero sí me decepciona este tipo de estupidez del futuro

• Por fin un caso en que la IA hizo algo útil
  Pensar que una persona tuviera que agregar y quitar una etiqueta 4500 veces sería espantoso

  • Ahora la profesión de etiquetador de GitHub ha desaparecido
    Queda demostrada la utilidad práctica de la AGI (mitad broma, mitad en serio)

• Me pregunto si aquí realmente intervino la IA
  Más bien parece que solo chocaron dos reglas de automatización. Se siente como un bug que ya era posible en 2015

  • Irónicamente, se dice que la IA es inteligente, pero ni siquiera puede reconocer este tipo de bucles
    Todavía estamos muy lejos de la AGI; de hecho, a la IA en general todavía le falta mucho camino

• Es un caso del típico bug de CI con un ligero aroma a LLM
  A nosotros también nos pasó algo parecido hace unas semanas en una merge queue personalizada

  • Dicen que es un “bug clásico de CI”, pero nunca había oído de bots entrando en un bucle infinito de conversación entre ellos
    Cuando antes hacía bots de IRC, el segundo paso era “evitar que se respondan a sí mismos”
    Así que esto se siente menos como un bug de CI y más como un error de diseño

• Parece un PR, pero en realidad es un reporte de issue
  Me preguntaba dónde estaba el parche de corrección, y resulta que este repositorio exige un issue vinculado para todos los PR
  Pero en este caso ni siquiera estaban vinculados entre sí

• Siento que pronto vamos a ver cosas así en seguridad social, planes de tratamiento contra el cáncer, logística aérea y configuraciones de ruteo de ISP
  Se vienen tiempos realmente interesantes