Would a JetBrains Loss Really Spell Trouble for Paid IDEs?

Key takeaways

• A JetBrains net loss for 2025 would not, by itself, establish declining demand for paid IDEs.
• Revenue needs to be read alongside paying customer counts, renewal rates, and revenue per customer.
• Building AI features and paying for customers to use them create different financial pressures.
• AI features need to earn their keep through customer growth, retention, and revenue that covers delivery costs.

If AI writes the code, why keep paying for the workbench? That question puts pressure on paid integrated development environments, or IDEs, such as JetBrains’ tools. But even if JetBrains posted a net loss for 2025, that would not settle the argument.

A loss tells you the result, not the cause

An IDE brings code editing, debugging, and running software into one workspace. Selling that workspace can become unprofitable for several reasons.

Customers might spend less. Costs might grow faster than sales. Those are different problems, even if they produce the same disappointing bottom line.

Start by separating operating profit from net income. Operating profit reflects revenue and expenses from the core business. Net income also incorporates items such as financing gains or losses and corporate taxes. A company can therefore earn an operating profit and still report a net loss.

For JetBrains, the useful question would be how revenue, operating expenses, and those other items connect. The final number cannot tell you whether developers stopped renewing their subscriptions.

Nor does it establish that AI caused the loss. That explanation needs evidence about where spending increased.

Revenue can rise while customers leave

Growing revenue is encouraging. It is not a complete customer health report.

Subscription revenue depends roughly on the number of paying customers and how much each spends. A price increase can lift revenue even as the customer base shrinks. Discounts or changes to product bundles can produce the reverse: more customers, with little additional revenue.

That makes renewal rates essential. Winning new accounts can conceal a steady stream of existing customers heading for the exit.

Even then, the reason matters. A business buying fewer developer seats after reducing headcount is different from developers switching to a competing tool. Both can reduce sales, but only the second directly supports an argument about product substitution.

To argue that AI coding tools are replacing paid IDEs, you would need to know whether customers are leaving and where they are going.

Developers might also keep their IDE subscriptions and pay separately for an AI assistant. In that scenario, AI complements the existing workspace. Two subscriptions on an expense report do not automatically mean one is about to disappear.

Building AI and serving AI are different bills

“Investing in AI” sounds like a plausible explanation for lower profits. It is also broad enough to obscure the economics.

One bill is for building the features: research and development staff, product integration, and quality evaluation. Spending can arrive before the resulting revenue does. If those features later attract enough paying customers, profitability may improve.

The other bill is for serving the features. Model calls and computation cost money when customers ask questions or request code. More usage can mean a larger bill.

That distinction changes what growth can fix. Spreading development costs across more subscribers may help. Adding subscribers whose usage costs too much to support does not necessarily help at all.

Flat-rate subscriptions make this especially important. Generous AI allowances appeal to customers. The provider still has to price the subscription so it can afford the usage.

None of this establishes what happened at JetBrains. Higher total expenses alone would not show how much went into AI development, how much went into serving requests, or how much had nothing to do with AI.

The subscription has to earn its place

The strongest case for a paid IDE is not how much code it can generate. It is how reliably it helps a developer finish the job.

Writing code is one part of that job. Developers also need to understand an existing codebase, check that changes have not broken something else, trace bugs, and work within a team’s conventions.

An IDE that connects AI effectively to those tasks has a reason to charge. If another tool makes the whole job easier, customers have a reason to reconsider.

An AI launch, then, is only the beginning of the business case. Does it bring in paying customers? Do existing customers stay longer? Does the additional revenue cover the cost of providing the service?

Strong customer retention alongside rising development spending would support an investment-led explanation for a loss. Customer departures alongside deteriorating profitability would raise a different concern. Both pressures could exist at once.

A JetBrains loss would deserve scrutiny, not an obituary for paid IDEs. The durable question is whether developers still find the subscription worth paying for—and whether JetBrains can deliver that value profitably.