Netflix acelera sus agentes de IA en Java: el motor de IntelliJ ahorra entre 20–30%, y hasta un 65% en el mejor caso

Los equipos de Netflix (Application Development Platform, GenAI Platform y Agentic SDLC) han medido cuánto cuesta que los agentes de IA no entiendan bien el código. Conectaron a Claude Code y Codex la versión headless del motor de análisis de código de JetBrains, el mismo que sustenta IntelliJ IDEA. En tareas reales, los agentes consumieron 20–30% menos de tokens y de tiempo, y en el mejor caso el ahorro llegó a aproximadamente 65%. La corrección del resultado no cayó en ninguna medición. Las pruebas se realizaron en julio y agosto de 2026.

El problema: los JAR en los que el agente se queda ciego

En los proyectos JVM, las bibliotecas suelen distribuirse como archivos JAR sin código fuente. El agente tiene que descomprimirlos por su cuenta, sin saber cuáles importan, decompilar los archivos class cuando hace falta y después buscar con grep en ese recorte incompleto. La búsqueda resulta lenta y poco fiable, y los tokens se gastan en divagar. Paul Bakker, Staff Software Engineer de Netflix, lo describe así: agentes como Claude Code son lentos y poco fiables al navegar por Java/Kotlin, sobre todo en las fronteras de las bibliotecas.

JetBrains lleva años construyendo un índice determinista del código fuente del proyecto junto con todas sus bibliotecas. Ahora ese índice está disponible a través de LSP, también en editores compatibles con VS Code. Pero el LSP por sí solo no está listo para un agente: es un servidor con un protocolo que el agente no puede invocar sin más y, además, carece de gestión de procesos para reutilizar una instancia que ya está en marcha.

Un daemon que mantiene el índice «caliente»

Construir el índice lleva un tiempo considerable, como la primera apertura de un proyecto grande en IntelliJ IDEA. El agente, en cambio, llama al LSP en muchos pasos pequeños, y una sola tarea requiere varias de esas llamadas. Si cada una levanta un servidor nuevo, cada una paga un arranque en frío de varios segundos, incluso cuando el índice se construyó un minuto antes.

JetBrains aún no había publicado el daemon en el momento de la evaluación, así que Netflix lo escribió por su cuenta:

• cada llamada a la herramienta es efímera y sin estado, y simplemente se dirige al CLI;
• el gestor de sesiones del daemon enruta la llamada, según la raíz del proyecto, al proceso servidor adecuado, que mantiene el índice en memoria;
• una segunda llamada sobre el mismo proyecto se salta la indexación y va al servidor «caliente» por stdio;
• el daemon y el CLI están escritos en Java y se distribuyen como ejecutable de GraalVM, de modo que el arranque no soporta la sobrecarga de la JVM.

Cómo se midió y qué resultó

El esquema era sencillo: un modelo, una tarea, una base de código y una sola variable, si el agente tenía o no acceso al motor de JetBrains. Se usaron dos bases de código reales:

• un servicio de producción interno de tamaño medio, con Spring Boot 4 y Gradle;
• el DGS Framework abierto de Netflix, un framework GraphQL mixto de Kotlin y Java.

Las tareas se dividieron en dos tipos. El primero, tareas de navegación pequeñas: dónde se usa una interfaz, qué implementaciones tiene, cuál es la estructura de una clase. El segundo, tareas de extremo a extremo: implementar una funcionalidad, refactorizar una clase, eliminar código. Las configuraciones de agentes y modelos fueron estas:

• Claude Code con Opus 5 (medium/high effort);
• Claude Code con Sonnet 5 (medium/high effort);
• Codex con GPT-5.6 Sol (medium/high effort).

Las métricas principales fueron el consumo de tokens y el tiempo de ejecución. La corrección la evaluó un LLM como juez: en las tareas de extremo a extremo, contra un conjunto de cambios de referencia; en las de navegación, con una métrica determinista. Las tareas que fallaron, alcanzaron el límite de presupuesto o entraron en bucle en al menos uno de los grupos se excluyeron de ambos, para que un solo fallo no distorsionara la comparación. Las ejecuciones se repitieron varias veces.

En las tareas de navegación, todos los modelos y niveles de esfuerzo gastaron menos tokens, y el modelo más potente fue el que más ganó. La corrección se mantuvo igual en la mayoría de las ejecuciones, mejoró en dos y no empeoró en ninguna. Hubo una única anomalía: una combinación de herramienta y modelo agrupa varias búsquedas en un solo comando y hace una única llamada tanto con el motor como sin él.

Para ella, acudir al motor es algo más lento, por lo que no hay ganancia de tiempo, y Netflix no considera ese punto representativo del trabajo real. Es más fiable fijarse en las tareas de extremo a extremo, donde el motor resultó más rápido con cada modelo y agente, y parte del efecto se explica porque se hacen menos llamadas a herramientas para llegar a las mismas conclusiones.

La mayor mejora la obtuvieron los modelos potentes con un nivel de esfuerzo alto. Son más caros, así que el ahorro en ellos vale más, y además saben aprovechar mejor el índice. Netflix subraya que las cifras son una instantánea: cada nuevo modelo cambia la forma en que los agentes buscan, razonan y llaman a las herramientas.

Qué se descartó y hacia dónde ir

Antes de la decisión final, Netflix descartó dos opciones. La primera fue un CLI interno propio que se conectaba a una IntelliJ IDEA en ejecución: exige un IDE abierto y no sirve para entornos headless como Otto, Bitbot, las herramientas de refactorización distribuida y la CI. La segunda fue Eclipse LSP, que se usa para Java en VS Code: con la compilación Gradle de Netflix, simplemente no funcionó.

A continuación, la compañía aplicará la misma metodología a Python, TypeScript/JavaScript y Go, donde los agentes tienen problemas parecidos, aunque la mecánica de carga de bibliotecas es distinta en esos ecosistemas. JetBrains ya ha publicado la inteligencia para Java que probó Netflix dentro de la extensión Java & Kotlin by IntelliJ IDEA, y sigue experimentando con el enfoque LSP+CLI.

Alexéi Stukálov, responsable de la línea de IDE de JetBrains, señala el punto débil del propio LSP: su primitiva básica es la posición del cursor en el texto, mientras que los agentes piensan en símbolos, diagnósticos, relaciones entre tests y comportamiento en runtime. La posición en el texto es frágil: se desplaza con una sola letra insertada. Según él, los agentes no necesitan un editor virtual, sino un motor de código con operaciones precisas sobre la estructura del programa.

Para los equipos que ya pagan por agentes sobre JVM, la conclusión es práctica. Si los tokens de los modelos potentes suponen una partida de gasto apreciable, una capa determinista de análisis de código junto al agente se amortiza más rápido que una actualización de modelo. Pero todavía no existe un daemon listo para usar: habrá que montarlo uno mismo siguiendo el esquema de Netflix o esperar a que JetBrains lo publique.