- Solicitação de adição de um recurso para que o Gemini CLI reconheça nativamente IDEs JetBrains
- Atualmente, a CLI aceita apenas valores de variáveis de ambiente específicas, como
TERM_PROGRAM do VS Code, então usuários do JetBrains precisam simular variáveis de ambiente para ativar o recurso
- Foi informado que há falhas na detecção de processo no Windows e no Linux, deixando explícita a necessidade de detecção de IDE baseada em variáveis de ambiente
- A mudança proposta inclui adicionar a série JetBrains em
IDE_DEFINITIONS e incluir a lógica de reconhecimento de TERMINAL_EMULATOR=JetBrains-JediTerm
- Trata-se de uma solicitação importante de melhoria para ampliar o alcance da integração de IDE do Gemini CLI e melhorar a experiência dos usuários do JetBrains
Proposta de detecção de IDEs JetBrains
- Foi registrada uma issue solicitando a adição de reconhecimento do ambiente de IDEs JetBrains ao Gemini CLI
- Antes, o valor de
TERM_PROGRAM era limitado a vscode e semelhantes, então o recurso não era ativado automaticamente nas IDEs JetBrains
- Para contornar isso, usuários do plugin para JetBrains precisavam imitar variáveis de ambiente do VS Code
- A proposta é adicionar a série de IDEs JetBrains a
IDE_DEFINITIONS e
ajustar para que o valor TERMINAL_EMULATOR=JetBrains-JediTerm seja reconhecido como ambiente oficialmente compatível
Necessidade e contexto do problema
- Há um problema em que a detecção de processo não funciona corretamente em ambientes Windows e Linux
- Casos relacionados podem ser vistos na página de revisão do plugin JetBrains e na issue #9273 do Gemini CLI
- Com base em vários feedbacks de usuários e relatos por e-mail, existe a necessidade de uma lógica de detecção baseada em variáveis de ambiente
Discussões e atividades relacionadas
- Esta proposta foi inspirada pelo PR #16083 anterior
2 comentários
Eu fiquei um bom tempo sem entender direito o que exatamente os comentários traduzidos do Hacker News estavam querendo dizer,
mas, ao olhar com mais atenção o PR no link, encontrei a resposta. Parece que era um problema um pouco pesado demais para o GN+ mesmo kkk
Comentários do Hacker News
Havia uma mensagem no meio da página dizendo "4609 remaining items"
Dois bots do gemini-cli acharam, por engano, que o outro — e não eles mesmos — tinha adicionado/removido labels e, ao tentar corrigir isso um no outro, entraram em um loop infinito
Esse repositório tem cerca de 10 contribuidores de longa data; assumindo que todos recebam notificações por e-mail, isso significa que 46.000 e-mails foram enviados em um único dia
Além disso, olhando a página do app gemini-cli, o desenvolvedor aparece como uma conta pessoal, então aparentemente não é um projeto oficial do Google
Aí fica a pergunta: quem pagou por todo esse custo de inference?
#16723, #16725, #16732, #16734
O processo de criação de apps no GitHub atualmente só funciona com contas pessoais, e é isso que causa esse tipo de problema
Já está em andamento um trabalho para permitir conceder permissão de criação de apps a membros da organização, e isso deve ser tratado como prioridade dentro de 6 meses
Quanto ao pagamento, cada organização coloca sua própria API key nos secrets do GitHub Actions, então o custo de inference é arcado por cada organização
O bot sabia qual era seu próprio nome, mas não entendia que esse nome também podia aparecer como ID de usuário, então não conseguia reconhecer a si mesmo
É preciso projetar com muito cuidado o modelo de autoconsciência com que o agente entende o mundo
Isso não é um problema só de bots; humanos também caem nessa armadilha com frequência
No passado, um novo “especialista em Salesforce” que chegou à nossa empresa criou uma regra para melhorar a fila de suporte
Quando a equipe de suporte recebia um novo e-mail, ele criava um ticket no Salesforce e, quando o ticket era atribuído, enviava outro e-mail
No fim, isso gerou um loop infinito de notificações, e como ele não admitia o erro, levou um tempão para descobrirmos a causa
Centenas de tickets foram criados ao longo de uma hora
Sinceramente, parecia melhor controlar tudo no Excel
Regras de resposta automática começaram a interagir entre si, milhares de e-mails se acumularam e até o sistema de login acabou paralisado
Fiquei proibido de usar computadores por 6 meses e, depois disso, o pessoal de TI passou a monitorar minha tela em tempo real
Um ano depois, quando surgiu outro problema, a equipe de TI correu até minha sala de aula e me arrastou de lá
O Salesforce é realmente um sistema monstruoso
Na semana passada já tinha havido um caso parecido de AI bot discutindo consigo mesmo no mesmo repositório
Alguém brincou: “é por isso que a RAM custa 800 dólares”
Eu sou o autor deste script :-)
Dois workflows do GitHub Action entraram em conflito
(1) um workflow que remove a label need-triage em certas condições
(2) um workflow que recoloca a label quando um usuário que não é gerente do projeto a remove
Eu mandei isso entre 22h e 23h e fui dormir; quando acordei, havia milhares de mensagens geradas
A causa foi que, no item (2), outros bots e automações também deveriam ter sido tratados como exceção, e corrigi isso assim que percebi
Ainda bem que não houve dano maior e, quando vi pela primeira vez, caí na risada
Foi o caso de o Gemini-cli[bot] ficar brigando consigo mesmo, adicionando e removendo labels mais de 4600 vezes
Finalmente um caso em que a IA fez algo útil
Só de imaginar um humano adicionando e removendo labels 4500 vezes manualmente já dá arrepios
A utilidade prática da AGI foi comprovada (meio brincando, meio sério)
Fico me perguntando se a IA realmente participou disso
Parece só um conflito entre duas regras de automação. Parece o tipo de bug que já era possível em 2015
Ainda estamos longe da AGI; na verdade, a própria IA ainda tem um bom caminho pela frente
É um caso clássico de bug de CI com um toque de cheiro de LLM
Tivemos algo parecido algumas semanas atrás numa fila de merge customizada
Na época em que eu fazia bots de IRC, o segundo passo já era “não responda a si mesmo”
Então isso parece menos um bug de CI e mais um erro de design
Isso parece um PR, mas na verdade é um relatório de issue
Fiquei procurando onde estava o patch de correção, até perceber que esse repositório exige uma issue vinculada para todo PR
Só que, desta vez, os dois nem estavam vinculados entre si
Parece que em breve vamos ver esse tipo de coisa acontecer em benefícios previdenciários, planos de tratamento de câncer, logística aérea e configuração de roteamento de ISP
Pelo visto, tempos realmente interessantes estão por vir