Antes de trocar o modelo, dê ao agente um índice de código que permaneça aquecido

A Netflix conectou a inteligência de código do IntelliJ IDEA a agentes como Claude Code e Codex, sem manter uma IDE aberta.[7] O trabalho mirou navegação em Java e Kotlin, incluindo dependências distribuídas como JARs, nas quais buscas e extrações manuais consumiam tempo e contexto.[7] Segundo o relato conjunto com a JetBrains, os ganhos típicos combinando tempo e tokens ficaram entre 20% e 30%.[7]

O que muda para quem desenvolve

O LSP foi usado como acesso à inteligência, mas a solução também ganhou uma CLI e um daemon.[7] O daemon mantém o servidor associado à raiz do projeto e o índice em memória; as chamadas curtas da CLI reutilizam essa sessão aquecida.[7] CLI e daemon foram desenvolvidos em Java e distribuídos como executáveis GraalVM.[7]

Minha leitura é que o ponto decisivo está no ciclo de vida da ferramenta. Não basta expor uma consulta semanticamente melhor se cada chamada repetir uma preparação cara. O agente precisa de uma interface pequena, enquanto o serviço preserva o estado necessário para responder bem.

Isso sugere um critério para avaliar integrações: quanto trabalho útil cada consulta entrega e quanto estado precisa ser reconstruído? A escolha do modelo vem depois dessa pergunta, não necessariamente antes.

Como aplicar

Escolha um projeto e um conjunto fixo de tarefas: localizar implementações, seguir referências entre módulos e fazer pequenas mudanças verificadas por testes. Compare a busca textual atual com a navegação semântica, mantendo modelo, orçamento e critérios de aceite iguais.

Separe a primeira execução das seguintes. Registre tempo de preparação, latência das consultas, tokens e alterações aprovadas. Um índice aquecido pode ser vantajoso em sessões longas e menos atraente em execuções raras; o experimento deve revelar esse custo, não escondê-lo.

A avaliação publicada usou um serviço interno Spring Boot 4 com Gradle e o framework aberto DGS, com tarefas de navegação e alterações completas.[7] Para adaptar a ideia, preserve também tarefas difíceis e resultados malsucedidos na análise. Se houver exclusões, documente o motivo antes de calcular a comparação.

O resultado desejado é custo por mudança correta, não apenas menos chamadas de ferramenta. Uma resposta rápida que aponta para um símbolo errado economiza a métrica e desperdiça a entrega.

Cuidados e limites

O ganho chegou a aproximadamente 65% em uma configuração de navegação, mas nas tarefas completas a faixa relatada foi de cerca de 10% a 30%, sem mudança na correção medida.[7] Houve também uma configuração sem melhora de tempo na navegação.[7]

A avaliação usou métricas determinísticas para navegação e um juiz LLM para alterações completas; casos que quebravam ou excediam orçamento de um lado eram retirados dos dois.[7] É um estudo dos envolvidos, não uma garantia independente para qualquer repositório. Copie a hipótese e a disciplina de medição, não o percentual da apresentação.

Fonte

[7] Fonte: JetBrains Blog