Netflix acelera agentes de IA em Java: motor do IntelliJ rende economia de 20–30%, até 65% no melhor caso

Equipes da Netflix (Application Development Platform, GenAI Platform e Agentic SDLC) avaliaram quanto custa o fato de os agentes de IA não entenderem bem o código. Elas conectaram ao Claude Code e ao Codex a versão headless do motor de análise de código da JetBrains, o mesmo que sustenta o IntelliJ IDEA. Em tarefas reais, os agentes gastaram 20–30% menos tokens e tempo, e no melhor caso a economia chegou a cerca de 65%. A correção do resultado não caiu em nenhuma medição. Os testes foram feitos em julho–agosto de 2026.

O problema: os JARs em que o agente fica cego

Em projetos JVM, as bibliotecas costumam vir como arquivos JAR sem o código-fonte. O agente precisa descompactar os arquivos por conta própria, adivinhando quais importam, decompilar os arquivos class quando necessário e só então buscar com grep nesse recorte incompleto. A busca fica lenta e pouco confiável, e os tokens são gastos em tentativas às cegas. Paul Bakker, Staff Software Engineer na Netflix, descreve a situação assim: agentes como o Claude Code são lentos e pouco confiáveis na navegação em Java/Kotlin, especialmente nas fronteiras entre bibliotecas.

Há anos a JetBrains constrói um índice determinístico do código-fonte do projeto junto com todas as bibliotecas. Agora ele está disponível via LSP, inclusive em editores compatíveis com o VS Code. Mas o LSP em si não está pronto para o agente: é um servidor com um protocolo que o agente não consegue simplesmente chamar e, além disso, não há gerenciamento de processos para reaproveitar uma instância já em execução.

Um daemon que mantém o índice aquecido

Construir o índice leva um tempo perceptível, como na primeira abertura de um projeto grande no IntelliJ IDEA. O agente, por sua vez, aciona o LSP em vários passos pequenos, e uma única tarefa exige várias dessas chamadas. Se cada uma sobe um novo servidor, cada uma paga um cold start de vários segundos, mesmo que o índice tenha sido construído um minuto antes.

No momento da avaliação, a JetBrains ainda não havia lançado o daemon, então a Netflix escreveu o seu próprio:

• cada chamada de ferramenta é de curta duração e sem estado, e apenas acessa a CLI;
• o gerenciador de sessões do daemon roteia a chamada, pela raiz do projeto, ao processo de servidor correto, que mantém o índice na memória;
• uma chamada repetida ao mesmo projeto pula a indexação e vai ao servidor "aquecido" via stdio;
• o daemon e a CLI são escritos em Java e distribuídos como executável GraalVM, de modo que não há overhead de JVM na inicialização.

Como foi a medição e o que saiu dela

O esquema era simples: um modelo, uma tarefa, uma base de código, e uma única variável, a de o agente ter ou não acesso ao motor da JetBrains. Foram usadas duas bases de código reais:

• um serviço interno de produção de porte médio, em Spring Boot 4 e Gradle;
• o DGS Framework, de código aberto da Netflix, um framework GraphQL misto de Kotlin/Java.

As tarefas se dividiam em dois tipos. O primeiro era de pequenas tarefas de navegação: onde uma interface é usada, quais são suas implementações, qual é a estrutura de uma classe. O segundo era de tarefas de ponta a ponta: implementar uma funcionalidade, refatorar uma classe, remover código. As configurações de agentes e modelos:

• Claude Code com Opus 5 (esforço medium/high);
• Claude Code com Sonnet 5 (esforço medium/high);
• Codex com GPT-5.6 Sol (esforço medium/high).

As principais métricas foram o consumo de tokens e o tempo de execução. A correção foi avaliada por um LLM como juiz: nas tarefas de ponta a ponta, com base em um conjunto de referência de alterações; nas de navegação, por uma métrica determinística. Tarefas que falharam, estouraram o limite de orçamento ou entraram em loop em pelo menos um dos grupos foram excluídas de ambos, para que uma única falha não distorcesse a comparação. Os testes foram repetidos várias vezes.

Nas tarefas de navegação, todos os modelos e níveis de esforço gastaram menos tokens, e o modelo mais forte foi o que mais ganhou. Na maioria das execuções, a correção ficou igual; em duas, aumentou, e em nenhuma caiu. A única anomalia: uma combinação de ferramenta e modelo agrupa várias buscas em um único comando e faz uma só chamada, com ou sem o motor.

Para ela, acessar o motor é um pouco mais lento, então não há ganho de tempo ali, e a Netflix não considera esse ponto representativo do trabalho real. É mais seguro olhar as tarefas de ponta a ponta, em que o motor foi mais rápido para todos os modelos e agentes, e parte do efeito se explica pelo menor número de chamadas de ferramentas para chegar às mesmas conclusões.

O maior ganho veio dos modelos fortes com alto nível de esforço. Eles são mais caros, então a economia neles vale mais, e eles lidam melhor com o índice. A Netflix ressalta que os números são um retrato do momento: cada novo modelo muda a forma como os agentes buscam, raciocinam e chamam ferramentas.

O que foi descartado e para onde ir

Antes da decisão final, a Netflix descartou duas opções. A primeira foi uma CLI interna própria, conectada a um IntelliJ IDEA em execução: ela exige uma IDE aberta e não serve para ambientes headless como Otto, Bitbot, ferramentas de refatoração distribuída e CI. A segunda foi o Eclipse LSP, usado para Java no VS Code: com o build Gradle da Netflix, ele simplesmente não funcionou.

A seguir, a empresa vai aplicar a mesma metodologia a Python, TypeScript/JavaScript e Go, onde os agentes enfrentam problemas parecidos, embora a mecânica de carregamento de bibliotecas nesses ecossistemas seja diferente. A JetBrains já lançou a inteligência de Java testada pela Netflix como parte da extensão Java & Kotlin by IntelliJ IDEA, e continua experimentando com a abordagem LSP+CLI.

Aleksei Stukalov, chefe da área de IDEs da JetBrains, aponta um ponto fraco do próprio LSP: sua primitiva básica é a posição do cursor no texto, enquanto os agentes pensam em símbolos, diagnósticos, relações entre testes e comportamento em tempo de execução. A posição no texto é frágil: ela se desloca com uma única letra inserida. Segundo ele, os agentes não precisam de um editor virtual, e sim de um motor de código com operações precisas sobre a estrutura do programa.

Para equipes que já pagam por agentes em JVM, a conclusão é prática. Se os tokens de modelos fortes representam uma despesa relevante, uma camada determinística de análise de código ao lado do agente se paga mais rápido do que um upgrade de modelo. Mas ainda não existe um daemon pronto para uso: será preciso montá-lo por conta própria, seguindo o esquema da Netflix, ou esperar o lançamento da JetBrains.