JetBrains says its IDE engine, benchmarked by Netflix in Claude Code and Codex, makes coding agents typically 20 to 30% more efficient

An agent cannot use the language server directly. The LSP is a protocol server with no easy way for an agent to call it and no process management to reuse a running instance between calls ^[4]. That matters because an agent works in many small, fine-grained steps, and a realistic task needs several of them ^[18].

Building an index takes real time, as it does when IntelliJ IDEA first opens a large project ^[5]. A fresh server per call would charge a multi-second cold start every time, even on a project indexed a minute earlier ^[6].

Netflix put a daemon in front of the servers. Each agent tool call is short-lived and stateless, and it shells out to a CLI ^[7]. The daemon's session manager routes the call by project root to the server process holding that project's index in memory ^[8]. A second call on the same project skips indexing and talks to the warm server over stdio ^[9].

Both pieces are written in Java and shipped as a GraalVM executable, so there is no JVM startup cost ^[10]. For a CLI invoked several times per task, that is the right call. JetBrains says it is working on its own daemon, but none existed when Netflix ran the evaluation ^[11]. Until one ships, we'd expect anyone copying the setup to own this layer.

The layer replaces a clumsy workflow. JVM projects typically ship libraries as JARs only, never as source, so agents unzip JARs while guessing which ones matter, may decompile class files, and then grep an incomplete view ^[12]. Paul Bakker, a staff software engineer at Netflix, said: "Coding agents like Claude Code are slow and unreliable at navigating Java/Kotlin code, especially across library (JAR) boundaries." ^[13]

The test design is clean. Each comparison kept the model, the task and the codebase fixed and changed one thing: whether the agent could call the JetBrains engine ^[14]. Results are the difference between runs with it and runs without ^[15]. The benchmarks were run multiple times ^[16].

The post reports gains of typically 20 to 30%, and up to about 65% in the best case, depending on model, agent and task ^[20]. The best case is roughly double the top of the typical range ^[19]. Each figure combines token and time savings ^[21]. The strongest models at higher effort gained most ^[2]. The post says those models cost more, so efficiency matters more there, and that they use indexes better ^[3].

This is JetBrains' blog reporting a benchmark on Netflix's tasks, and JetBrains builds the engine. The text we have ends before the per-configuration results. It does not list the tasks, the codebase, the run count or how token and time savings are weighted into one number.

For 20 to 30% to transfer, your code would have to be JVM code where agents now dig through JARs, and the index would have to stay warm across calls. We'd also expect short one-shot tasks to gain less, since they pay for indexing and amortize it over few calls. Bakker's JAR point describes where agents struggle. The text we have does not show gains broken out for JAR-crossing tasks.