Where AI Coding Tools Are Headed in 2026
The JetBrains Gap
A data-driven look at the IDE landscape, the rise of agentic AI, and an underserved frontier worth paying attention to.
Note that this post is written in March 2026, since AI space is moving so fast, it's good to keep in mind.
Starting Point: The IDE Landscape
Before talking about AI tooling, we need to understand the foundation — where developers actually live and work. Using the StackOverflow Developer Survey 2025 as our data source, here's the raw picture:
All Respondents
┌──────┬────────────────────┬───────┐
│ Rank │ IDE / Tool │ Usage │
├──────┼────────────────────┼───────┤
│ 1 │ Visual Studio Code │ 75.9% │
│ 2 │ Visual Studio │ 29.0% │
│ 3 │ Notepad++ │ 27.4% │
│ 4 │ IntelliJ IDEA │ 27.1% │
│ 5 │ Vim │ 24.3% │
│ 6 │ Cursor │ 17.9% │
│ 7 │ PyCharm │ 15.0% │
│ 8 │ Android Studio │ 15.0% │
│ 9 │ Jupyter Notebook │ 14.1% │
│ 10 │ Neovim │ 14.0% │
│ 14 │ Claude Code │ 9.7% │
│ 21 │ Windsurf │ 4.9% │
│ 25 │ Cline/Roo │ 2.2% │
└──────┴────────────────────┴───────┘Note: StackOverflow uses multi-select, so percentages sum past 100%. JetBrains' own ecosystem reports are worth cross-referencing for more precise segmentation.
Categorized more meaningfully:
IDE Market Share 2025 (Grouped)
| Category | Combined Share | Examples |
|--------------------|-----------------|-----------------------------------|
| VS Code (Microsoft)| ~75% | VS Code, VSCodium |
| JetBrains Suite | ~30–35% | IntelliJ, PyCharm, WebStorm, etc. |
| Generic Editors | ~10–25% | Vim/Neovim, Sublime, Nano |
| Mobile IDEs | ~15–18% | Android Studio, Xcode |
| AI-Native IDEs | <10% | Cursor, Windsurf |Four clear camps emerge: the Microsoft/VS Code world, the JetBrains professional suite, classic text editors, and a nascent wave of AI-native IDEs.
How Developers Are Using AI Today
The more interesting question isn't which IDE developers use — it's how they're incorporating AI into their workflow. The options vary significantly by camp.
For VS Code users, the ecosystem is rich and fragmented:
Methods to Use AI in VS Code
| Method | Type | Pricing |
|---------------------|---------------|----------------------|
| GitHub Copilot | Autocomplete | $10–19/mo |
| Cursor | AI-native IDE | Free tier / $20/mo |
| Cline | Agentic agent | Free (BYO API key) |
| RooCode | Agentic agent | Free (BYO API key) |
| Codeium | Autocomplete | Free / $15/mo Pro |
| Tabnine | Autocomplete | Free / $12/mo Pro |
| Continue.dev | Multi-modal | Free |
| Amazon CodeWhisperer| Enterprise | Free |
| Gemini Code Assist | Enterprise | Free tier |These methods fall into two meaningful buckets. First, autocomplete and assistant tools — where you still write code yourself and AI fills in the gaps or answers questions. Second, agentic tools — where the AI takes autonomous actions: reading files, running commands, making multi-step edits, and iterating on your behalf.
We believe a paradigm shift is underway. Agentic AI represents the higher-leverage path for developer productivity — not by replacing thought, but by collapsing the distance between intent and execution. Tools like Claude Code, Cursor, and Cline are early signals of this direction, and usage patterns bear it out.
This focuses our attention on the agentic tier: Cline, RooCode, KiloCode, Cursor, and Windsurf. Of these, Cursor and Windsurf require migrating away from VS Code entirely — which explains why the majority of developers surveyed are still on plain VS Code. VS Code-native plugins have a structural head start because they require zero migration.
The CLI Contenders
One category the IDE-centric framing misses entirely is the CLI agent — tools that don't live inside an IDE at all, but operate from the terminal alongside whatever editor you happen to have open.
Claude Code is the current standout here, sitting at 9.7% usage in the StackOverflow survey — remarkable for a tool that launched relatively recently and requires no GUI. Others in this tier include Codex CLI (OpenAI), Gemini CLI (Google), and KiloCode CLI.
The CLI approach has some genuine structural advantages:
IDE-agnostic by design. CLI agents work the same whether you're in IntelliJ, VS Code, Vim, or nothing at all. For polyglot teams or developers who switch contexts frequently, this is a real benefit — you don't need a plugin for every environment.
Unrestricted tool access. Without the sandbox constraints of a plugin environment, CLI agents can freely run build systems, test runners, git operations, web searches, and arbitrary shell commands. The agentic loop is tighter because there's no bridge layer between the AI and the system.
Context at the project level. Rather than inferring context from what's visible in an editor, a CLI agent can scan an entire repository, read config files, inspect CI output, and reason about the full project state. This often produces better multi-file edits than editor-constrained tools.
The tradeoff is real though. CLI agents sacrifice the IDE's semantic understanding — no inline error highlighting, no refactoring suggestions anchored to your current cursor, no awareness of what you're actively looking at. For exploratory work, debugging, or large-scale refactors across a codebase, CLI is often faster. For tight feedback loops during active development — where you want the AI to know your immediate context — an in-IDE tool wins.
Feature Snapshot: Cline vs. KiloCode vs. Cursor
A quick comparison on one key differentiating feature — RAG (Retrieval-Augmented Generation) — illustrates where each tool sits:
| Feature | Cline | RooCode | KiloCode | Cursor |
|---|---|---|---|---|
| RAG | ❌ | ✅ (experimental) | ✅ (experimental) | ✅ (built-in) |
| Setup effort | None | High | High | None |
| Persistent memory | ❌ | ❌ | ✅ Memory Bank | ✅ Memories |
| Team sharing | ❌ | ❌ | ❌ | ✅ Index sharing |
| Accuracy boost | — | Unknown | Unknown | +12.5% |
Cline made a deliberate choice not to support RAG, which is a principled stance but a real gap for users who want that feature. KiloCode, as a downstream fork, inherits and extends the best of what Cline and Roo built — while carving its own roadmap from there.
The JetBrains Problem (and Opportunity)
Here's where things get interesting.
JetBrains users are often dismissed in market-share charts because their raw numbers trail VS Code. But raw percentage is a misleading lens. JetBrains users skew heavily toward paid, professional, enterprise contexts. These developers are not casual hobbyists — they're engineers at organizations who pay for their tools and have real productivity budgets.
And the language-specific story is stark:
Java/Kotlin:
| IDE | Java Share | Kotlin Share | Key Use Case |
|---|---|---|---|
| IntelliJ IDEA | 84% | ~70–75% | Enterprise Java, Spring |
| Android Studio | N/A | ~20–25% | Android development |
| VS Code | 31% | ~5–10% | Multi-language, lightweight |
JavaScript/TypeScript:
| Language | #1 | #2 | #3 |
|---|---|---|---|
| JavaScript | VS Code (~82%) | WebStorm (~12%) | Vim (~12%) |
| TypeScript | VS Code (~82%) | WebStorm (~12%) | Cursor (~18%) |
Python:
| Language | #1 | #2 | #3 |
|---|---|---|---|
| Python | VS Code (~42%) | PyCharm (~32%) | Jupyter (~28%) |
For certain languages and domains — particularly Java, Kotlin, and Android — JetBrains IDEs aren't just preferred, they're effectively mandatory. VS Code users working in these stacks are often doing so on multi-language codebases, not because IntelliJ is worse.
What JetBrains Developers Are Actually Using for AI
The JetBrains State of Developer Ecosystem 2025 (24,534 developers, 194 countries) paints a telling picture:
AI Tool Adoption — JetBrains Developers
┌──────────────────────────────────────┬──────┐
│ Use AI tools regularly │ 85% │
│ Use at least one AI coding assistant │ 62% │
│ Have not adopted AI at all │ 15% │
│ Anticipate AI becoming job-required │ 68% │
└──────────────────────────────────────┴──────┘And the tools they're reaching for:
AI Tools Used (JetBrains Survey 2025)
┌──────┬──────────────────────────┬───────┐
│ Rank │ Tool │ Usage │
├──────┼──────────────────────────┼───────┤
│ 1 │ ChatGPT │ 41% │
│ 2 │ GitHub Copilot │ 30% │
│ 3 │ Cursor │ 13% │
│ 4 │ JetBrains AI Assistant │ 13% │
│ 5 │ DeepSeek (local/hosted) │ 10% │
│ 8 │ JetBrains Junie │ 5% │
│ 9 │ Claude Code │ 4% │
│ 14 │ Windsurf │ 2% │
└──────┴──────────────────────────┴───────┘Read that carefully. Cursor shows up at 13% — meaning a meaningful chunk of JetBrains developers are opening a second IDE alongside their primary one just to get better AI. That's a strong signal: demand is there, but it's not being met inside the JetBrains ecosystem itself.
The top choices — ChatGPT (primarily a web assistant, not IDE-integrated) and GitHub Copilot (autocomplete-first) — are not agentic tools. The JetBrains user base has adopted AI broadly, but the agentic, context-aware, multi-step coding assistant that's become table stakes on VS Code simply doesn't have a dominant equivalent in-IDE on JetBrains.
The Market Gap: No De Facto Agentic JetBrains Plugin
The closest thing to a purpose-built agentic JetBrains plugin is Firebender, a YC-backed startup that's done impressive work — but has positioned itself specifically as "the best AI for Android," not a general JetBrains tool. Its feature set reflects that focus: LogCat access, emulator integration, Figma connections. Strong for Android teams, but not a general answer.
JetBrains Junie was promising, but its credit-based pricing model created real friction: users would get excited during a free trial, burn through credits inside days, and hit a wall. Even the recent BYOK (bring-your-own-key) addition doesn't fully resolve this, because it still sits on top of a subscription credit layer. The user sentiment pattern: "Junie is amazing for a few days... then what?"
This is the gap. A truly capable, agentic, open-source-friendly plugin that works natively inside JetBrains IDEs — with proper understanding of PSI (JetBrains' Program Structure Interface, the deep semantic layer that makes IntelliJ refactoring so powerful) — does not yet exist as a polished, widely-adopted product.
JetBrains Users: What's the Best Bet Right Now?
Given all of the above, what should a JetBrains developer actually do today if they want serious agentic AI in their workflow?
The honest answer is: run a CLI agent alongside your IDE. It's an awkward two-window setup, but it's currently the highest-capability option. Claude Code in particular integrates well with JetBrains projects because it reads the project structure directly from disk — it doesn't need IDE integration to understand a Maven/Gradle project, a Kotlin module hierarchy, or an Android build config. You write code in IntelliJ, and when you need the AI to do something substantive, you drop to the terminal.
For in-IDE usage, the options today are:
JetBrains AI Assistant — reasonable for code completion and chat-style assistance, but not truly agentic. Good starting point if you want something officially supported.
JetBrains Junie — the closest to agentic within the ecosystem, and the quality is real when it works. The pricing model remains the biggest obstacle; understand the cost structure before committing. The recent BYOK addition makes it more viable for teams with existing model contracts.
Firebender — if you're on Android, this is the strongest in-IDE agentic option available right now. Its Android-specific integrations (LogCat, emulator control, Figma access) are genuinely useful. Less relevant outside Android.
KiloCode JetBrains Plugin — early stage, actively developed, and worth watching. It brings the full VS Code KiloCode feature set into JetBrains through a bridge architecture, which means you get the breadth of a mature agentic tool. The bridge approach has real limitations (it's not PSI-native), but for teams already invested in the KiloCode ecosystem, it's a natural extension.
The pragmatic short-term stack: JetBrains IDE + Claude Code CLI for heavy lifting, with an in-IDE assistant (Junie or AI Assistant) for lighter, context-sensitive tasks. It's not elegant, but it's what actually works well today.
The Architecture Reality
Building properly for JetBrains isn't the same as porting from VS Code. The two platforms are built on fundamentally different philosophies:
- VS Code uses the Language Server Protocol (LSP) — a language-agnostic, lightweight layer.
- JetBrains uses PSI — a deep, structured, semantically-rich AST that understands code at a level LSP doesn't approach.
A JetBrains plugin that merely wraps VS Code behavior through a bridge will work — but it won't be good. It misses the native IDE features that make JetBrains worth paying for in the first place. The real value for AI tooling in this ecosystem comes from plugins that speak PSI natively: understanding refactoring semantics, project structure, cross-module dependencies, and build system context at the level JetBrains developers expect.
That's a harder problem. But it's also why the opportunity is still open.
Will CLI Win the War?
The question comes up a lot: as CLI agents get more capable, does the IDE plugin become irrelevant? The short answer is no — and the more interesting answer is that the three formats (CLI, plugin, AI-native IDE) are converging toward their own natural equilibrium rather than one winner eliminating the others.
Here's why each format survives:
CLI agents own the "big task" moment. When you need to refactor an entire module, add a new feature end-to-end, or debug a complex system interaction, a CLI agent with full filesystem and shell access is the right tool. It doesn't care which IDE you use. Claude Code's rapid adoption (9.7% in the survey, from a standing start) is evidence that developers will happily leave their IDE for the right kind of task.
In-IDE plugins own the "I'm actively coding" moment. When you're in flow — in the middle of writing a function, reading an error message, tracing a stack — you want the AI where your eyes are. The semantic context an IDE has (what file you're in, what the type signature says, what the error is pointing to) is not easily replicated by a CLI agent that's reading from disk. Plugins that leverage that context well will always have a place.
AI-native IDEs own the "I just want it to work" moment. Cursor and Windsurf grew by packaging everything together and removing setup friction. For developers who don't want to configure API keys, manage context windows, or stitch together a CLI + plugin workflow, an opinionated full-IDE experience wins.
The trajectory isn't winner-take-all — it's specialization. Expect developers to maintain 2–3 tools in their AI stack long-term, chosen by context. The analogy to search is apt: we didn't stop using Google when Notion launched, or stop using Notion when ChatGPT launched. Each tool settled into the job it does best.
What this means practically: the race isn't "which format wins," it's "which tool within each format becomes the default." CLI has Claude Code as a strong front-runner. AI-native IDE has Cursor. The in-IDE plugin space for JetBrains, as we've argued, is still wide open.
The Open Source Angle: BYOK, No Markup, and the Road to Self-Hosted
There's a deeper economic story underneath the tooling landscape, and it's one where open source has a structural advantage.
Most commercial AI coding tools follow a similar model: they sit between the developer and the underlying model provider, add a margin, and either hide the model cost entirely (subscription) or surface it with markup. This works fine when models are expensive and developers don't want to manage API keys — but both of those conditions are changing fast.
KiloCode's position here is notable. As a fully open-source tool with a genuine BYOK approach — no markup, no credit system, you pay the model provider directly and nothing else — it sits outside the rent-extraction layer entirely. You bring your Anthropic or OpenAI key, or point it at a local model, and KiloCode is just the tool. This is a meaningful philosophical choice, not just a pricing tactic.
The Cost Is Collapsing — Faster Than Most People Realize
Three data points from the past year illustrate the velocity of this shift:
DeepSeek (January 2025) — the training cost shock. DeepSeek trained its V3 model — GPT-4-class performance — for approximately $5.9 million in direct compute costs (2,048 Nvidia H800 GPUs over 55 days). GPT-4 reportedly cost over $100 million. Meta's comparable Llama 3.1 used roughly 10x the compute. The "$6M" figure needs context: it excludes prior research, failed experiments, and hardware ownership costs, which SemiAnalysis estimated at "well above $500 million" over DeepSeek's full history. But the core insight still holds — the algorithmic gap between "frontier" and "affordable" collapsed dramatically. Nvidia lost $589 billion in market cap in a single day when the market absorbed the implications. On inference, the cost gap is even more striking: DeepSeek's API runs at roughly $0.27 per million input tokens vs. GPT-4o's ~$3.00 — about 10x cheaper, with OpenAI's CEO himself noting it runs 20–50x cheaper than their comparable model.
MiniMax (2025) — the inference architecture breakthrough. While DeepSeek made the training cost story visible, MiniMax has been quietly redefining what inference efficiency looks like. Their M1 model introduced "Lightning Attention" — a hybrid architecture that reduces FLOPs for long-sequence generation to 25% of traditional transformer models. The result: their M2 model (released October 2025) runs at 8% of Claude Sonnet's cost at nearly double the inference speed. Their M2.5 (February 2026) matches Claude Opus 4.6 on coding benchmarks (80.2% on SWE-Bench Verified) at 1/20th the cost. The MiniMax CEO stated at the 2025 World AI Conference that inference costs had already dropped an order of magnitude over the prior year — and predicted another order-of-magnitude drop within the next two years. The underlying driver isn't just competitive pricing strategy: it's Mixture-of-Experts (MoE) architectures that activate only a fraction of parameters per inference (MiniMax M2.5 activates just 4% of its 230B parameters per forward pass), meaning the compute bill per token keeps falling as architectures get smarter.
Z.ai / Zhipu AI (January 2026) — hardware independence. Perhaps the most strategically significant data point: Z.ai (formerly Zhipu AI, rebranded internationally in 2025, makers of the GLM series) became the first company to train a top-tier LLM entirely on non-Nvidia hardware. Their GLM-Image model and subsequently GLM-5 (a 745B parameter MoE) were trained end-to-end on Huawei's Ascend Atlas 800T A2 chips using the MindSpore framework — zero Nvidia dependency. This was partly forced by US export restrictions placing Zhipu on the Entity List, cutting them off from H100s and A100s. But the outcome proves something important: the assumption that frontier AI development requires Nvidia hardware is no longer true. Huawei's Ascend ecosystem is viable for training competitive models. This matters enormously for enterprises thinking about self-hosted inference — Nvidia's GPU scarcity and pricing is no longer the only path.
Worth noting: there's also a Jevons Paradox at work here. MiniMax's CEO acknowledged it directly — as cost per token falls, total token consumption is skyrocketing. A year ago a chatbot interaction used thousands of tokens; today a single agentic workflow can consume millions. So the total spend on inference may not fall as fast as the per-token price would suggest. But for AI coding tools specifically, where individual developers control their own usage, cost-per-token is what matters — and that's the number in freefall.
What This Means for the "Which Model" Question
Here's where the narrative gets more nuanced than "all models become the same." Quality convergence doesn't mean models become interchangeable — it means the easy tasks become commoditized, freeing up a more interesting question about the hard ones.
Think of it this way: as GLM-5, Llama 4, Claude 5, GPT-5, and their descendants all become capable of handling 80% of everyday coding tasks competently, a developer stops caring which model writes a CRUD endpoint or fixes a null pointer exception. Cost and speed become the deciding factors at that layer. But for the remaining 20% — deep architectural decisions, debugging subtle concurrency issues, reasoning about unknown unknowns in a complex system — you don't just want any capable model. You want different perspectives.
This is where model decoupling becomes genuinely interesting. Imagine treating GLM-20 and Opus-20 and GPT-20 the way you'd treat three senior engineers from different backgrounds: all highly capable, all likely to solve the routine problems, but bringing different "intuitions" shaped by different training data, RLHF choices, and architectural priorities. For a hard problem where you're not sure what you're missing, you want to ask all three. The divergence in their answers is the signal.
This is already the direction power users are heading — running the same hard prompt through two or three models and comparing outputs. The tooling layer that makes this workflow seamless (model-agnostic, easy to switch, no per-tool subscriptions) is exactly the layer that BYOK, no-markup tools are positioned to enable. When your tool doesn't care which model you use, you're free to use all of them as the task demands.
The Self-Hosted Horizon
When cost-per-token collapses and hardware alternatives exist, enterprise procurement calculus changes:
The conditions for self-hosted inference at scale are:
- Task-level quality parity — for the 80% of routine coding work, an efficient open-weights model is indistinguishable from a frontier API. We're arguably already here for simpler tasks; the gap is narrowing fast for complex ones.
- Hardware accessibility — Nvidia H100s remain expensive and scarce, but MoE architectures and quantization mean acceptable inference is achievable on H20s, A800s, and increasingly on domestic alternatives like Huawei Ascend. The hardware moat is eroding.
- Operational confidence — this remains the real bottleneck. Enterprises need reliable, maintained, updated models they can trust in production. The open-source ecosystem (Llama, DeepSeek, GLM, Qwen) is maturing here, but it's still not plug-and-play for most IT teams.
When all three converge — and the trajectory suggests 2–3 years for early adopters — cost-cutting becomes the driver. Companies spending $50K+ annually in aggregate AI tool subscriptions will start doing the math on on-prem inference. For organizations with GPU resources and engineering bandwidth, the self-hosted path is already viable for non-frontier tasks.
Open source tooling is the only layer that makes this transition a configuration change rather than a platform migration. If your AI coding tool is tightly coupled to a specific model provider, you can't swap the backend. If it's model-agnostic with BYOK — whether that's KiloCode, Continue, or whatever successor emerges — switching from Claude API to a self-hosted DeepSeek derivative is a config change. That portability is worth more than it looks today.
Where This Points
Pulling it all together, a few things seem reasonably clear about the next few years:
Agentic AI is the direction, not a trend. The shift from autocomplete to autonomous agents is happening at every layer — CLI, plugin, and full IDE. Developers who've used a truly agentic tool don't go back to tab completion. The question now is which format, and which tool within that format, becomes the default for each context.
CLI, plugin, and AI-native IDE will coexist. This isn't a race to one winner. Each format has a genuine job it does best — CLI wins today on breadth and tool access, active-coding flow belongs to the plugin, zero-friction onboarding belongs to AI-native IDEs. That said, the boundaries aren't fixed: a PSI-native JetBrains plugin that truly understands a codebase's semantic graph could arguably outperform CLI on large refactors, since it reasons about code structure rather than raw files. Expect the default developer AI stack to be 2–3 tools, chosen by context — with those boundaries shifting as in-IDE tooling matures.
JetBrains is the biggest unmet market right now. VS Code is well-served. JetBrains has 30–35% of professional developers, enterprise skew, and no dominant agentic plugin. The tool that fills it with native PSI integration and clean pricing will land in a wide-open space.
The cost floor is dropping faster than most tooling vendors are accounting for. DeepSeek proved training doesn't require hundreds of millions. MiniMax proved inference efficiency is an engineering problem, not just a scaling problem. Z.ai proved Nvidia isn't the only viable hardware path. The combined effect: the total cost of running frontier-quality AI is compressing at a rate that will make today's subscription economics look expensive within 2–3 years.
Model decoupling matters more as models get better, not less. When the routine tasks are handled well by any capable model, the interesting question shifts to the hard ones — and there, having access to multiple models as distinct "principal engineers" with different perspectives becomes a genuine productivity advantage. The tooling layer that treats model choice as a config setting, not a platform commitment, is the one that stays relevant through the next several generations of model releases.
Self-hosted inference is coming for enterprise — open tooling is the unlock. The trajectory is clear even if the timeline is uncertain. Organizations building on model-agnostic, open-source tooling today are making an investment that compounds: when self-hosted inference becomes viable for their workloads, the migration is trivial. For everyone else, it's a platform re-evaluation.
The JetBrains AI story, the CLI vs. plugin equilibrium, the open source economic angle, and the coming model commoditization are all threads of the same larger story: the defaults in AI developer tooling haven't been set yet. That's what makes this an interesting moment to be paying attention.
Data sourced from the StackOverflow Developer Survey 2025 and JetBrains State of Developer Ecosystem 2025.
Data sourced from the StackOverflow Developer Survey 2025, JetBrains State of Developer Ecosystem 2025, MiniMax WAIC 2025 keynote, and public technical reports from DeepSeek and Zhipu AI.
Clap to support the author, help others find it, and make your opinion count.