Nick Frolov

We connected IntelliJ IDEA’s code intelligence to Claude Code and Codex, then tested the setup with Netflix. The first public results are out. Typical efficiency gains: 20–30%. Best code-navigation case: ~65%. These results come from two real codebases. The efficiency metric averages token savings and time savings. Correctness stayed stable or improved. Here’s what we actually built. The code engine behind IntelliJ IDEA ran headlessly, giving agents access to its capabilities through a CLI backed by a daemon. LSP alone wasn’t sufficient. Agents needed a convenient way to invoke the tools. The backend also needed to stay running and keep the project index warm between calls. The idea is straightforward. An IDE has already mapped the structure of your code and its dependencies — including what’s inside compiled libraries. An agent can use that knowledge instead of spending time and tokens reconstructing it. But the most interesting finding was which models benefited most. The strongest models saw the biggest gains. Especially at higher reasoning effort. In these experiments, more capable models were also better at taking advantage of code intelligence. My takeaway: better models and better tools aren’t competing bets. You don’t have to choose between investing in model intelligence and giving agents better access to your codebase. The two can reinforce each other. Huge thanks to @pbakker and the Netflix team for working with us on this!

We've reimagined JetBrains IDEs to become the ultimate agentic workbench. Air is an open hub for agents inside your IDE: -Any agents to run (Claude, Codex & many more) -Agents are more efficient with IDE intelligence -Free Junie Lite agent bundled -Cloud runs via Air Teams ⬇️

JetBrains takes its first step toward Local AI. MacBook M5 users can set up Junie Local in one click and get a solid agentic experience. Unlimited & Fully local. Folks also had some fun presenting it on a plane :) Check it out & stay tuned for more: junie.jetbrains.com/local

We are defaulting Gemini3.7 Flash in Junie and giving a solid discount for it. blog.jetbrains.com/junie/202…

The observation: a cost discrepancy Our preliminary data shows a significant gap in monthly spend among heavy, all-day AI coding users: Junie users: ~$2,000/month Claude Code / Codex users: ~$5,000/month We are now running a formal study to verify these numbers. The core question is simple: Is Junie cheaper because it is genuinely more cost-efficient — or are users spending more in other tools because they feel more productive there and use them more? Our working theory is that a big part of the gap comes from inference economics, especially context management and token caching. 1. Context compaction strategy Junie aggressively auto-compacts conversation history. In practice, a Junie conversation does not keep growing indefinitely and never exceeds ~150k tokens. Other tools tend to compact only when the conversation approaches a high threshold of the available context window. That sounds fine in theory. But in real developer workflows, it can become expensive. 2. The cache problem At first glance, constant compaction looks counterintuitive: changing the context can invalidate token cache benefits. But token caches are short-lived. In many real workflows, developers switch tabs, jump between conversations, write code, review diffs, get interrupted, and come back later. By the time they send the next message, the cache may already be gone. So if the conversation history has grown very large, the user can end up repeatedly paying for a huge amount of context that is no longer cached and often no longer useful. 3. The practical result Junie’s aggressive auto-compaction may save a lot of tokens specifically because real development work is interrupted, non-linear, and multi-threaded. This is the part that matters: cost efficiency is not only about model price. It is also about how intelligently the product manages context over time. There is also a strategic angle here. Companies that monetize primarily through token consumption are not naturally incentivized to minimize token usage as aggressively as an IDE vendor trying to deliver the best AI experience at the lowest sustainable cost. That may become one of the biggest differences between standalone AI coding tools and deeply integrated AI inside IDEs.