How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence

Agentic AI AI Customer Stories Java Use Case

How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence

Netflix plugged JetBrains’ headless code-intelligence engine – the same one behind IntelliJ IDEA – into Claude Code and Codex, then benchmarked it against a variety of scenarios. The details and numbers are available below.

At a glance

Company	Netflix – Application Development Platform (ADP), GenAI Platform, and Agentic SDLC teams
Challenge	Coding agents were struggling to navigate Java/Kotlin code, especially across compiled library (JAR) boundaries
Technology	JetBrains IDE code intelligence for Java, built on the same code-indexing engine that powers IntelliJ IDEA, run headlessly with no IDE open.
Netflix’s role	Built the daemon and CLI needed to make the LSP callable by an agent – infrastructure that JetBrains hadn’t shipped yet
Result	Typically 20–30% more efficient (fewer tokens, less time), and up to about 65% in the best case, on real programming tasks – the size of the gain depends on the model, the agent, and the task, generally larger for stronger models and higher effort settings
Evaluated on	Two real codebases – an internal production service and Netflix’s open-source DGS Framework – across several current coding agents and models, July–August 2026

The goal: Increase agent ROI

JetBrains and Netflix set out to give coding agents accurate, IntelliJ IDEA-grade code understanding in headless environments – with no IntelliJ IDEA instance running.

“Coding agents like Claude Code are slow and unreliable at navigating Java/Kotlin code, especially across library (JAR) boundaries. We integrated a headless JetBrains IDE’s code engine to give agents IntelliJ IDE-grade code intelligence in headless environments, with no IDE running. We created a benchmark with real programming tasks, which shows that with the JetBrains IDE’s code engine, agents are consistently more efficient – using fewer tokens and less time, with the exact gain depending on the model.”

— Paul Bakker, Staff Software Engineer, Netflix

The JAR problem Netflix is trying to solve that Paul describes above: JVM projects typically ship libraries as JAR files only, never as source. Agents have to unzip the JARs (guessing which ones matter), potentially decompile class files, then grep through that incomplete view.

The solution: JetBrains IDE intelligence

JetBrains has spent years building the code intelligence engine behind IntelliJ IDEA. It is based on a deterministic index of your project source files, including all libraries. This intelligence is now exposed via an LSP and available in VS Code-compatible editors. Netflix worked with a headless build of that engine.

The LSP alone isn’t enough for a coding agent to use directly: It’s just a server speaking a protocol, with no easy way for an agent to call it and no built-in process management to reuse a running instance between calls. Netflix closed that gap themselves using the daemon and CLI described in the next section.

Architecture in detail: Keeping the index warm

Building an index for a project takes real time, just as opening a large project in IntelliJ IDEA for the first time does. A coding agent calls the LSP in many small, fine-grained steps, and a realistic task needs several such calls. If each one spun up a fresh LSP server, every single call would incur a multi-second cold-start cost – even on a project whose index had already been built a minute earlier.

A daemon process is required to avoid the overhead of cold-starting the LSP server process on repeated calls. JetBrains is working on delivering a daemon, but no daemon was available by the time of evaluation, so Netflix has built one for their own needs:

1. Each tool call was short-lived and stateless – it just shelled out to the CLI.
2. The daemon is the part that stays up: Its session manager routes each call by project root to the matching server process, which holds that project’s index in memory.
3. A second call against the same project skips indexing entirely and goes straight to a warm server over stdio.
4. Both the daemon and CLI are developed in Java and distributed as a GraalVM executable, so there is no startup or runtime overhead from the JVM.

How Netflix measured the ROI of JetBrains IDE intelligence

To understand if (and to what extent) JetBrains IDE intelligence improves the performance of a coding agent, a benchmark suite was developed. Same model, same task, same codebase – the only variable was whether the agent could invoke the JetBrains IDE intelligence. Results are reported as the performance difference between runs with JetBrains IDE intelligence versus runs without it.

Evaluation environment and approach:

Datasets	Two real codebases: An internal service (medium-size project) using Spring Boot 4 and Gradle. Netflix’s own open-source DGS Framework – a public, mixed Kotlin/Java GraphQL framework.
Tasks	Two task types: Small/focused tasks where the agent attempts to understand specifics in the codebase, e.g. “where is this interface used in the project”, “what implementations exist of this interface”, “what is the structure of this class”. Full end-to-end tasks, such as implementing a new feature, refactoring a class, or removing code.
Models	Claude Code with Opus 5 (medium/high effort) Claude Code with Sonnet 5 (medium/high effort) Codex with GPT-5.6 Sol (medium/high effort)
Scoring	While the most important metrics in the experiment were token consumption and time to completion, LLM as a judge was implemented for checking correctness. It works against a reference change set for end-to-end tasks and applies deterministic scoring metric for navigation tasks.
Outlier handling	A task that crashed, hit a budget cap, or thrashed in either arm was excluded from both, so one blow-up couldn’t skew the comparison.

The benchmarks were run multiple times to validate the results and see the effects of changes from new LSP releases.

Results

Across every model, agent, and task type tested, JetBrains IDE intelligence made coding agents more efficient overall – typically 20–30% more efficient, and up to about 65% in the best case, depending on the specific model, agent, and task. The stronger models, with higher effort, saw the largest gains. These models are more expensive, so efficiency improvements matter more, but these models are also better at using indexes effectively.

These numbers are a snapshot, not a fixed benchmark result. Every new model release changes how agents search, reason, and use tools, so the exact percentages will keep moving – which is why this write-up reports ranges rather than per-model results. What held up across Netflix’s runs is the general shape: every model and agent tested became more efficient, the largest gains came from the strongest model at a high-effort setting, and the size of the gain differed noticeably from one model to the next.

Code-navigation tasks: More efficient across the board, correctness held or improved

Every model and effort level tested used fewer tokens with JetBrains IDE intelligence – no exceptions there – with savings ranging from roughly 15% to 60%. The size of the gain depended mostly on the model: the strongest model saw by far the largest improvements, while lighter-weight configurations landed at the lower end of both ranges. Correctness held steady in most runs and improved in two – it never dropped.

For the code-navigation tasks specifically, one tool/model combination already batches multiple search calls into a single command, so both with and without JetBrains IDE intelligence, it only makes one tool call there. Calling into JetBrains IDE intelligence is a little slower for that one call than the batched search command – which is what produced the clear lack of time benefit for that combination, not a fair reflection of real-world use. That’s why the broader end-to-end task suite is the more reliable read on time instead, where JetBrains IDE intelligence was faster across every model and agent tested.

End-to-end tasks: Consistently more efficient, correctness unaffected

On the expanded end-to-end run, correctness held steady everywhere across every model and agent tested, so the benefit shows up entirely in efficiency, not in whether the task got done. Every model and agent combination was roughly 10–30% more efficient with JetBrains IDE intelligence, looking at time to completion and token spend. A lot of this is explained by requiring fewer tool calls to come to the same conclusions.

Other evaluated alternatives

Before committing to the described approach, Netflix ruled out two others. The first rejected was a homegrown internal CLI that connected to a running IntelliJ IDEA instance to get access to a project index. The process is similar to what this article describes, but it requires an IDE to be running. This approach didn’t fit headless agents for environments like Otto, Bitbot, distributed refactoring tooling, CI, etc.

Second, an existing Eclipse LSP, which is used for Java in VS Code, was considered. But for Netflix’s build system (Gradle-based), it just didn’t work.

What’s next

Where Netflix goes from here

After the test, Netflix concluded that “the benchmarks show that there is a benefit to having a deterministic intelligence layer alongside your agent”. Of course, it doesn’t cut every coding-agent task by a fixed percentage. But for this specific problem – resolving real structure across JAR boundaries – the benefit is large, holds across models, and doesn’t cost anything in correctness.

Netflix plans to run the same benchmark methodology against Python, TypeScript/JavaScript, and Go. Coding agents for those languages have similar problems. But of course, the ways libraries are downloaded in a project vary by language, so the mechanics of the issues and possible solutions differ. JetBrains plans to continue the collaboration and support this evaluation further.

JetBrains’ take: The LSP is just one step, not the destination

JetBrains IDE intelligence for Java has been tested by Netflix and is now shipped as part of the Java & Kotlin by IntelliJ IDEA extension. JetBrains also continues experiments with the LSP+CLI approach and will report the results once ready.

The LSP’s basic primitive is a position in a text document. The specification defines a position as “between two characters, like an insert cursor in an editor”. That’s a natural primitive for a human working at a keyboard. But agents don’t really think in terms of cursor locations. They ask questions about the program, like “Why is this call inside createUser() unresolved?” and “Which tests are covering this method?”, etc. It’s about understanding relationships between parts of the code rather than looking at cursor positions. And a text position is a fragile identity – inserting one character before any given position causes that position to move.

What an agent needs isn’t a sharper cursor, but a layer that provides answers formulated in the same way as the tasks themselves – i.e. in terms of symbols, diagnostics, test relations, runtime behavior – and returns enough context to reason about the answer, not just locations in a text document.

“That’s what I mean by a code engine: not another protocol that lets an agent imitate editor interaction, but a set of precise operations over program structure and execution – one that returns enough context to actually reason about the result. LSP is useful, but it shouldn’t define the final agent-facing abstraction. Build agent tooling as if the agent were a tiny human at an editor, and you force it to speak in cursor coordinates. Agents need a code engine, not a virtual editor.”

— Aleksey Stukalov, IDE Division Lead, JetBrains

The Netflix numbers prove code intelligence is worth paying for. Deciding what shape that intelligence takes is the challenge that lies ahead.