JetBrains just published the tool-adoption findings from its Developer Ecosystem Survey 2026, fielded across more than 15,000 professional developers worldwide in May, June and July. Cross-referenced against its January 2026 AI Pulse survey of over 10,000 developers, the two show weekly use of Claude Code going from 18% to 39% in about five months, more than doubling and pulling it well ahead of GitHub Copilot, whose own adoption fell from 29% to 21% over the same window. If your engineering team wrote down an AI-coding-tool policy any time before this summer, the tool it named is very likely not the one most of your engineers reach for now.
What actually moved between January and July
JetBrains runs two studies that, read together, show how fast the top of this market reshuffled in a single year: a quarterly AI Pulse survey and the annual Developer Ecosystem Survey, now in its tenth year. Lined up against each other, January to July 2026 looks like this:
| AI coding tool | Jan 2026 | May-Jul 2026 | Change |
|---|---|---|---|
| Claude Code | 18% | 39% | +21 pts |
| OpenAI Codex | 3% | 16% | +13 pts |
| GitHub Copilot | 29% | 21% | -8 pts |
| Cursor | 18% | 12% | -6 pts |
The two surveys use different sample sizes and JetBrains' own methodology notes flag a statistical reweighting by region, employment status and language between them, so treat the exact point counts as directional rather than to the decimal. The direction itself isn't in question: Codex's growth is the sharpest in percentage terms, a little over five times its January share, and its awareness among developers worldwide jumped from 27% to 65% in the same window, so the growth wasn't limited to developers who already knew the product going in.
Awareness isn't the same as adoption
Copilot still leads on brand recognition: 79% of developers worldwide know it, rising to 86-90% in Europe, the UK and the US, per the same 2026 survey, the highest awareness of any tool JetBrains tracked. What it no longer has is the adoption to match. Cursor tells the same story from the other direction: its awareness actually rose, from 69% to 75% worldwide, while its usage fell from 18% to 12% over the same five months, with the steepest drop in China, down from 28% to 16%. A developer recognizing a tool's name isn't the same as a team having standardized on it, and that gap is exactly where a procurement decision made on reputation alone goes wrong. It's the same distinction Stack Overflow's own 2025 developer survey drew a different way, finding that most developers who use an AI tool still don't fully trust its output: usage, awareness and trust are three separate numbers, and a policy built on only one of them is guessing at the other two.
What tool churn costs an engineering team
Claude Code's own numbers show the difference between a trial and a real switch: it's now the single most-used tool for 31% of developers, an 80% conversion rate from regular weekly use to being someone's primary tool, in JetBrains' own framing. That's not noise in a download count. It's engineers who tried an agent and moved their actual workflow onto it inside a few months, taking their editor setup, their prompt habits and, in an agent-first workflow, meaningful unsupervised access to the codebase with them.
Every one of those moves is a decision an engineering org didn't necessarily make on purpose. Each agent handles source code, credentials and internal documentation differently: some run against a local repo clone, some route everything through a vendor's cloud, some read further into a monorepo than a reviewer would expect going in. A security or data-handling review done in January, when Cursor and Claude Code were tied at 18% and Codex barely registered at 3%, reviewed a different market than the one your engineers are actually using five months later.
Why standardizing on one tool doesn't hold
The obvious fix, mandate one tool company-wide, doesn't survive data moving this fast. A twelve-month enterprise contract signed against January's numbers locks in a tool that may already be the market's second or third choice by the time it's up for renewal, and pulling it mid-contract means re-running the access review, the credential setup and the retraining all over again for whatever replaces it. The tool name is the wrong thing to standardize on. What holds up better is the criteria a tool has to clear before anyone points it at production code: how it handles source code and credentials, what it costs per seat at the volume your team actually generates, and whether it's agentic, acting across multiple steps with less human confirmation per step, or a narrower autocomplete. Those questions are far more stable than any single vendor's adoption curve, and they're what a security review or a budget line actually needs answered.
What a policy built for this actually checks
A policy that survives the next adoption chart looks less like an approved-vendor list and more like a short, standing checklist run on a quarterly cadence instead of an annual one: where does this tool's traffic go (local, or a vendor's cloud), what does it read beyond the file a developer has open, what's the all-in cost per seat at the team's real usage, and is there a named exception path for an engineer to pilot something new without waiting for the next renewal date. None of that requires predicting which tool wins next quarter. It requires the review to be about the tool's behavior rather than its name, which is the one thing in this data set that keeps not surviving five months.
A worked example, and what it means for your team
Picture a 45-person Series B company that signed an annual GitHub Copilot enterprise license in December 2025, when it was still the obvious default. By July, most of its senior engineers were running Claude Code or Codex on the side, unofficially, because that's genuinely what they reached for to get agentic work done, and the company's actual security review covered none of it. Nobody made a bad decision in December. The market underneath the decision moved twice in five months, and the review never got a second pass.
The fix isn't re-signing a contract every quarter. It's writing the policy around what a tool has to prove before it touches production code, then running that review quarterly instead of annually. That's the kind of process gap staff augmentation tends to close well: a senior engineer who has already built this kind of review somewhere that lived through the same churn, brought in to write it down properly instead of leaving it in one person's head. It's a weaker fit if the actual blocker is a budget call only your own CTO can make, since a contractor can help scope the review, not sign the check.
None of this is a reason to wait on AI coding tools until the market settles, because JetBrains' own numbers say it isn't settling this year. It's a reason to build the review once, at the level of what a tool does rather than what it's called, instead of re-litigating a tool choice every time an adoption chart moves. The same discipline shows up in what happens to incident rates when a rollout outpaces a team's review process and in why the refactoring work behind AI-generated code keeps falling behind; this is the market-share version of the same problem. If your engineering team is past picking a tool by reputation and needs that review built properly, our Silicon Valley team can scope the conversation. Talk to us about what a quarterly AI-tool review should actually check for a team your size.
Sources
- JetBrains: AI Coding Agents: Adoption Trends (published August 18, 2026; Developer Ecosystem Survey 2026, fielded May-July 2026 across 15,000+ professional developers worldwide)
- JetBrains: Which AI coding tools do developers actually use at work? (published April 2026; AI Pulse survey, fielded January 2026 across 10,000+ professional developers)
- JetBrains: Developer Ecosystem Survey methodology