Loved, Bought, Deployed: Why the Three AI Coding Winners Are Different Products

Three products lead the AI coding tools market and none of them leads the same scoreboard. Claude Code holds a 91% satisfaction score in the largest recent developer survey. Cursor sold for $60 billion. GitHub Copilot sits inside a platform used by more than 90% of the Fortune 500. Ranking them on one list hides the fact that each optimised for a different buyer.

Three scoreboards, and each has a different leader

Most comparisons of AI coding tools pick a winner. That is the wrong shape for this market, because the three published measures of success do not agree with each other.

The first measure is satisfaction. It asks whether developers who use the tool would recommend it. The second is revenue. It asks whether someone signed a purchase order. The third is deployment, which asks whether the tool made it through security, procurement and a company-wide rollout.

Those are not three views of one contest. They are three separate contests, decided by three different people inside the same company.

Figures are drawn from different sources on different dates and are not directly comparable. The Fortune 500 figure covers GitHub the platform, not paid Copilot seats. Anthropic does not publish a Claude Code seat count, so its revenue position rests on company-stated run rate rather than on user numbers.

Loved: what a 91% satisfaction score actually measures

JetBrains ran an AI Pulse survey in January 2026 across more than 10,000 professional developers in eight languages, weighted against its wider Developer Ecosystem population. Claude Code recorded a 91% CSAT and an NPS of 54, which JetBrains called the highest loyalty metrics on the market.

That result is worth reading carefully, because satisfaction scores are usually the softest number in a comparison. This one came with an unusual property. It arrived before the market share did.

The satisfaction number moved before the adoption number

Claude Code sat at roughly 3% work adoption in the middle of 2025. By January 2026 it was at 18%, level with Cursor and behind Copilot at 29%. By the May to July 2026 wave, covering more than 15,000 developers, it had reached 39% globally and 47% in the United States.

Awareness lagged the whole way. Claude Code had 57% awareness in January against Copilot's 76%. A tool that converts a minority of the people who have heard of it into a plurality of active users is not winning on marketing. It is winning on what happens after installation.

JetBrains also reported that Claude Code was the single most-used tool for 31% of developers, against 39% who use it regularly. That ratio matters more than either number alone. Roughly four in five regular users make it their primary tool, rather than one of several open tabs.

What a satisfaction score cannot tell you

Satisfaction measures the experience of the person holding the keyboard. It says nothing about whether the work got done faster, and the wider survey evidence on that point is uncomfortable.

Stack Overflow's 2025 survey of about 49,000 developers found 46% actively distrusting the accuracy of AI tools against 33% who trust them, with only 3% saying they highly trust the output. The top frustration, cited by 66%, was solutions that are almost right but not quite. Stack Overflow reported in February 2026 that trust had fallen to 29%, down 11 points from 2024, while usage climbed above 84%.

Developers love these tools and do not trust them. Both statements are true at once, and any comparison that reports only the first is selling something.

Bought: revenue rewards a different product than love does

Cursor is the clearest case in the market of revenue running ahead of affection. Its annualised revenue went from $100 million in January 2025 to $500 million in June, $1 billion by November and $2 billion by February 2026. That ramp is covered in detail in the piece on the fastest revenue ramp in software history.

None of that came from a satisfaction lead. It came from being the easiest tool for a manager to buy for a whole team.

Cursor's revenue came from teams, not from fans

By April 2026 Cursor reported more than 1 million paying customers and around 50,000 enterprise teams. Roughly 70% of the Fortune 1,000 appeared somewhere in its customer base. About 60% of revenue came from enterprise accounts.

That shape tells you what the product optimised for. Cursor shipped a familiar editor with a per-seat price and a team plan. A director could approve it without changing how anyone works. The migration cost was close to zero because the interface was one people already knew.

I think this is the most underrated product decision in the category. Cursor did not ask developers to adopt a new workflow. It asked them to install a different build of the workflow they had, which is a far smaller thing to say yes to. The pattern is the same one described in the analysis of how point tools get absorbed.

An exit price is the cleanest revenue signal available

On 16 June 2026 SpaceX agreed to acquire Anysphere in an all-stock deal reported at $60 billion. An April offer had preceded it, carrying a $10 billion break-up fee. The price is roughly 30 times the last publicly reported ARR figure, which was four months old at signing.

Read the multiple, not the headline. A buyer paying that price is not buying current revenue. It is buying a position in a market it does not otherwise hold, which is a valuation logic covered in the piece on what actually makes a wrapper defensible.

The uncomfortable fact sits next to it. In the same window that Cursor was priced at $60 billion, its share of developers using it at work fell from 18% to 12%.

Deployed: the slowest scoreboard is the stickiest

GitHub Copilot has lost the usage race and has not lost the deployment race. Those are different assets with different decay rates.

On the FY26 Q4 earnings call on 29 July 2026, Microsoft reported GitHub Copilot at 50 million users and GitHub itself at 225 million. More than 90% of the Fortune 500 sits on the platform. Microsoft also said that 1 in 3 pull requests on GitHub now involves an agent.

Copilot's numbers improve as the company gets larger

The JetBrains January data contained the detail that explains the split. Copilot sat at 29% adoption overall and 40% inside companies with 5,000 or more employees. By the mid-2026 wave its overall share had fallen to 21% while its awareness stayed highest in the market at 79%.

A tool that over-indexes on large firms is not winning on merit at those firms. It is winning on the fact that the contract already exists. Nobody in a 20,000-person company has to justify buying a GitHub add-on, because GitHub is already approved, already invoiced and already inside the compliance boundary.

That advantage is real and it is not durable in the way vendors present it. It slows the rate at which a better tool displaces you. It does not stop the displacement.

The pricing model changed underneath the seat count

In June 2026 GitHub moved Copilot to usage-based billing. Microsoft reported that Copilot revenue then accelerated by over 60% quarter over quarter.

Read that as a defensive move, not a growth one. Seat-based pricing was becoming hard to defend while a rival product billed against actual consumption, a dynamic set out in the piece on seat compression in software pricing. Charging for consumption also converts an agent that runs for an hour into revenue, where a seat licence would have captured nothing extra.

The number to watch next is not seats or users. It is whether that revenue acceleration survives a full quarter in which customers have seen a consumption bill.

Why the three scoreboards disagree

The disagreement is not a measurement error. It happens because three different people sign off, and each one is answering a question the others do not care about.

The developer asks whether the tool produces work they would ship without rewriting. The budget holder asks whether spend per head is predictable and whether the tool expands across a team. The security and platform function asks whether the vendor is already approved and where the code goes.

A product cannot maximise all three at once, because the answers pull in opposite directions. Deep autonomy raises satisfaction and raises review risk. Per-seat pricing simplifies procurement and caps revenue per user. A familiar interface speeds adoption and limits how different the product can be.

What the mid-2026 data changed, and what it did not

The tidy version of this argument would be that each tool holds its own scoreboard permanently. The data has already broken that version, and it is worth saying so plainly.

Claude Code did not stay in the satisfaction lane. It took the usage lead, reaching 39% against Copilot's 21%, which means the loved product converted love into share within about eight months. On revenue, Anthropic said in February 2026 that Claude Code was above a $2.5 billion run rate and had doubled since 1 January, with business subscriptions quadrupling.

Revenue leadership is now contested

Cursor's last disclosed figure was $2 billion in February 2026. Claude Code's was above $2.5 billion in the same month. Neither company publishes audited results and the two are not measured on the same basis, so treat that ordering as directional rather than settled. The wider revenue picture is tracked in the AI revenue leaderboard and in the analysis of Anthropic's enterprise mix.

Deployment is the one scoreboard that has not turned. Copilot's usage fell by roughly a quarter in six months and its Fortune 500 presence did not move at all. That asymmetry is the finding. Preference re-ranks in quarters, procurement re-ranks in years, and anyone modelling this market on usage alone will be early by a long way.

Where this argument is weakest

Three problems, and the first one undermines the headline.

Surveys measure enthusiasm, not output

Every satisfaction figure in this post is self-reported. METR's randomised trial, using tools available between February and June 2025, found that experienced open-source developers were around 20% slower when allowed to use AI tools, while believing they had been sped up.

METR's own February 2026 update is more interesting than the headline. It says the team believes developers are more sped up now than in early 2025, and calls its evidence for the size of that increase very weak. It also reports that 30% to 50% of developers declined to submit tasks because they did not want to work without AI.

That refusal rate is the most honest measure of attachment in the whole category, and it also wrecks the experiment. The broader question of whether any of this shows up in output is taken up in the piece on the AI productivity paradox.

The categories are not clean

Claude Code, Cursor and Copilot are not three versions of one product. One is a terminal agent, one is an editor and one is a platform feature that now also bills by consumption. Comparing their adoption percentages assumes developers pick one, and most of them do not.

The JetBrains figures also come from a population weighted against JetBrains' own user base. That is disclosed and methodologically reasonable, and it is still a population that skews toward professional IDE users. Copilot's numbers would very likely look different in a Visual Studio Code sample.

One more caveat that cuts against my own framing. Model access, not product design, may explain much of the satisfaction gap. If a competing product ships the same underlying model, part of the loyalty advantage travels with the model rather than staying with the tool. That is the argument made in the piece on where integration depth becomes a moat.

How to run the three tests on your own team

Vendor comparison pages will not settle this for you, because they are each written against the scoreboard their sponsor leads. Run your own version instead. It takes two weeks and needs no tooling.

For the loved test, ask your engineers one question with a number in it. What share of the code this tool produced did you ship without substantive rewriting last week? Anything under half is a signal, whatever the satisfaction survey says.

For the bought test, pull three months of invoices and divide by active engineers. Do this after any pricing model change, not before. A consumption bill and a seat bill behave differently under the same usage, and the difference shows up in month two.

For the deployed test, ask your platform lead one question. If we picked the tool the developers prefer, how many weeks does approval take? That number is the real switching cost, and it is usually the reason the incumbent is still there.

If you are choosing between building your own agent layer and buying one of these, the trade-offs are set out in the build versus buy analysis for coding agents.

Frequently asked questions

Where to start this week

Start with the invoice, not the survey. Pull the last three months of spend on coding assistants, divide by the number of engineers who opened one, and write the figure down. Most teams have never calculated it, and it is usually the only number in this debate that belongs to you.

Then ask your platform lead how long approval would take for the tool your developers say they want. If the answer is longer than a quarter, your tooling decision is being made by procurement, and no comparison post will change that. Fix the approval path first and the tool choice becomes easy.

Related reading