{"id":6128,"date":"2026-10-16T03:38:27","date_gmt":"2026-10-16T06:38:27","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/16\/how-netflix-made-ai-coding-agents-more-efficient-with-jetbrains-ide-intelligence\/"},"modified":"2026-10-16T03:38:27","modified_gmt":"2026-10-16T06:38:27","slug":"how-netflix-made-ai-coding-agents-more-efficient-with-jetbrains-ide-intelligence","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/16\/how-netflix-made-ai-coding-agents-more-efficient-with-jetbrains-ide-intelligence\/","title":{"rendered":"How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence"},"content":{"rendered":"
\n
\n
\n
\n

Agentic AI<\/a> AI<\/a> Customer Stories<\/a> Java<\/a> Use Case<\/a><\/p>\n

How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence<\/h2>\n

Netflix plugged JetBrains\u2019 headless code-intelligence engine \u2013 the same one behind IntelliJ IDEA \u2013 into Claude Code and Codex, then benchmarked it against a variety of scenarios. The details and numbers are available below.<\/p>\n

<\/figure>\n

At a glance<\/h2>\n
\n\n\n\n\n\n\n\n\n
Company<\/strong><\/td>\nNetflix \u2013 Application Development Platform (ADP), GenAI Platform, and Agentic SDLC teams<\/td>\n<\/tr>\n
Challenge<\/strong><\/td>\nCoding agents were struggling to navigate Java\/Kotlin code, especially across compiled library (JAR) boundaries<\/td>\n<\/tr>\n
Technology<\/strong><\/td>\nJetBrains IDE code intelligence for Java<\/a>, built on the same code-indexing engine that powers IntelliJ IDEA, run headlessly with no IDE open.<\/td>\n<\/tr>\n
Netflix\u2019s role<\/strong><\/td>\nBuilt the daemon and CLI needed to make the LSP callable by an agent \u2013 infrastructure that JetBrains hadn\u2019t shipped yet<\/td>\n<\/tr>\n
Result<\/strong><\/td>\nTypically 20\u201330% more efficient (fewer tokens, less time), and up to about 65% in the best case, on real programming tasks \u2013 the size of the gain depends on the model, the agent, and the task, generally larger for stronger models and higher effort settings<\/td>\n<\/tr>\n
Evaluated on<\/strong><\/td>\nTwo real codebases \u2013 an internal production service and Netflix\u2019s open-source DGS Framework \u2013 across several current coding agents and models, July\u2013August 2026<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The goal: Increase agent ROI<\/h2>\n

JetBrains and Netflix set out to give coding agents accurate, IntelliJ IDEA-grade code understanding in headless environments \u2013 with no IntelliJ IDEA instance running.<\/p>\n

\n

\u201cCoding agents like Claude Code are slow and unreliable at navigating Java\/Kotlin code, especially across library (JAR) boundaries. We integrated a headless JetBrains IDE\u2019s 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\u2019s code engine, agents are consistently more efficient \u2013 using fewer tokens and less time, with the exact gain depending on the model.\u201d<\/p>\n

\u2014 Paul Bakker, Staff Software Engineer, Netflix<\/cite><\/p><\/blockquote>\n

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.<\/p>\n

The solution: JetBrains IDE intelligence<\/h2>\n

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<\/a>. Netflix worked with a headless build of that engine.<\/p>\n

The LSP alone isn\u2019t enough for a coding agent to use directly: It\u2019s 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.<\/p>\n

Architecture in detail: Keeping the index warm<\/h2>\n

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 \u2013 even on a project whose index had already been built a minute earlier.<\/p>\n

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:<\/p>\n

    \n
  1. Each tool call was short-lived and stateless \u2013 it just shelled out to the CLI.<\/li>\n
  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\u2019s index in memory.<\/li>\n
  3. A second call against the same project skips indexing entirely and goes straight to a warm server over stdio.<\/li>\n
  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.<\/li>\n<\/ol>\n

    How Netflix measured the ROI of JetBrains IDE intelligence<\/h2>\n

    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 \u2013 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.<\/p>\n

    Evaluation environment and approach:<\/p>\n

    \n\n\n\n\n\n\n\n
    Datasets<\/strong><\/td>\nTwo real codebases: An internal service (medium-size project) using Spring Boot 4 and Gradle.
    Netflix\u2019s own open-source DGS Framework<\/a> \u2013 a public, mixed Kotlin\/Java GraphQL framework.<\/td>\n<\/tr>\n
    Tasks<\/strong><\/td>\nTwo task types:
    Small\/focused tasks where the agent attempts to understand specifics in the codebase, e.g. \u201cwhere is this interface used in the project\u201d, \u201cwhat implementations exist of this interface\u201d, \u201cwhat is the structure of this class\u201d.
    Full end-to-end tasks, such as implementing a new feature, refactoring a class, or removing code.<\/td>\n<\/tr>\n
    Models<\/strong><\/td>\nClaude Code with Opus 5 (medium\/high effort)
    Claude Code with Sonnet 5 (medium\/high effort)
    Codex with GPT-5.6 Sol (medium\/high effort)<\/td>\n<\/tr>\n
    Scoring<\/strong><\/td>\nWhile 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.<\/td>\n<\/tr>\n
    Outlier handling<\/strong><\/td>\nA task that crashed, hit a budget cap, or thrashed in either arm was excluded from both, so one blow-up couldn\u2019t skew the comparison.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

    The benchmarks were run multiple times to validate the results and see the effects of changes from new LSP releases.<\/p>\n

    Results<\/h2>\n

    Across every model, agent, and task type tested, JetBrains IDE intelligence made coding agents more efficient overall \u2013 typically 20\u201330%<\/strong> more efficient, and up to about 65%<\/strong> 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.<\/p>\n

    \n

    Efficiency gain per configuration, combining token and time savings. Each comparison runs the same task, model, and codebase twice \u2013 once with JetBrains IDE intelligence available, once without it. <\/p>\n

    \n
    \n

    ~25%<\/p>\n

    Average gain<\/p>\n<\/p><\/div>\n

    \n

    20\u201330%<\/p>\n

    Typical range<\/p>\n<\/p><\/div>\n

    \n

    ~65%<\/p>\n

    Best case<\/p>\n<\/p><\/div>\n<\/p><\/div>\n

    \n\n\n\n\n\n\n\n\n
    Configuration<\/th>\nCode navigation<\/th>\nEnd-to-end<\/th>\n<\/tr>\n<\/thead>\n
    Strongest model, high effort<\/td>\n~65%<\/td>\n~24%<\/td>\n<\/tr>\n
    Mid model, high effort<\/td>\n~29%<\/td>\n~30%<\/td>\n<\/tr>\n
    Mid model, medium effort<\/td>\n~24%<\/td>\n~22%<\/td>\n<\/tr>\n
    Lighter configuration, high effort<\/td>\n~17%*<\/td>\n~21%<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n

    Efficiency is the average of token and time savings for each configuration. Correctness held steady or improved in every run. *Tokens only: this configuration\u2019s batched search calls made the code-navigation time comparison unrepresentative \u2013 see the article text. Figures are a snapshot and will shift with new model releases. <\/p>\n<\/p><\/div>\n

    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 \u2013 which is why this write-up reports ranges rather than per-model results. What held up across Netflix\u2019s 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.<\/p>\n

    Code-navigation tasks: More efficient across the board, correctness held or improved<\/h3>\n

    Every model and effort level tested used fewer tokens with JetBrains IDE intelligence \u2013 no exceptions there \u2013 with savings ranging from roughly 15% to 60%<\/strong>. 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 \u2013 it never dropped.<\/p>\n

    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 \u2013 which is what produced the clear lack of time benefit for that combination, not a fair reflection of real-world use. That\u2019s 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.<\/p>\n

    End-to-end tasks: Consistently more efficient, correctness unaffected<\/h3>\n

    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\u201330%<\/strong> 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.<\/p>\n

    Other evaluated alternatives<\/h2>\n

    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\u2019t fit headless agents for environments like Otto, Bitbot, distributed refactoring tooling, CI, etc.<\/p>\n

    Second, an existing Eclipse LSP, which is used for Java in VS Code, was considered. But for Netflix\u2019s build system (Gradle-based), it just didn\u2019t work.<\/p>\n

    What\u2019s next<\/h2>\n

    Where Netflix goes from here<\/h3>\n

    After the test, Netflix concluded that \u201cthe benchmarks show that there is a benefit to having a deterministic intelligence layer alongside your agent\u201d. Of course, it doesn\u2019t cut every coding-agent task by a fixed percentage. But for this specific problem \u2013 resolving real structure across JAR boundaries \u2013 the benefit is large, holds across models, and doesn\u2019t cost anything in correctness.<\/p>\n

    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.<\/p>\n

    JetBrains\u2019 take: The LSP is just one step, not the destination<\/h3>\n

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

    The LSP\u2019s basic primitive is a position in a text document. The specification defines a position as \u201cbetween two characters, like an insert cursor in an editor\u201d. That\u2019s a natural primitive for a human working at a keyboard. But agents don\u2019t really think in terms of cursor locations. They ask questions about the program, like \u201cWhy is this call inside createUser()<\/code> unresolved?\u201d and \u201cWhich tests are covering this method?\u201d, etc. It\u2019s about understanding relationships between parts of the code rather than looking at cursor positions. And a text position is a fragile identity \u2013 inserting one character before any given position causes that position to move.<\/p>\n

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

    \n

    \u201cThat\u2019s 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 \u2013 one that returns enough context to actually reason about the result. LSP is useful, but it shouldn\u2019t 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.\u201d<\/p>\n

    \u2014 Aleksey Stukalov, IDE Division Lead, JetBrains<\/cite><\/p><\/blockquote>\n

    The Netflix numbers prove code intelligence is worth paying for. Deciding what shape that intelligence takes is the challenge that lies ahead.<\/p>\n<\/p><\/div>\n

    <\/a> <\/section>\n

    \n

    Discover more<\/h2>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n

    Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Agentic AI AI Customer Stories Java Use Case How Netflix Made AI Coding Agents More Efficient with JetBrains IDE Intelligence Netflix plugged JetBrains\u2019 headless code-intelligence engine \u2013 the same one behind IntelliJ IDEA \u2013 into Claude Code and Codex, then benchmarked it against a variety of scenarios. The details and numbers are available below. At […]<\/p>\n","protected":false},"author":1,"featured_media":6127,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"webixso_pending_account_ids":""},"categories":[46],"tags":[],"class_list":["post-6128","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-jetbrain"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/6128","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=6128"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/6128\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/6127"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=6128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=6128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=6128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}