This week two announcements landed within a day of each other, and they say the same thing from opposite ends of the market.

JetBrains opened an early access program for Air, an agentic development system that plugs into its IDEs. It works with agents like Codex and GitHub Copilot, and you can use the subscriptions you already pay for. You don't need a JetBrains AI license. IBM, meanwhile, shipped a self-hosted version of Bob, its agentic development platform, that runs on-prem, in a private or sovereign cloud, or fully air-gapped.

One company says "bring any agent." The other says "run it where your code lives." Put them together and the picture is pretty clear.

The agent is becoming the swappable part

Look at what JetBrains is actually selling. Not the agent. The IDE tooling underneath it: debugging, performance profiling, database exploration, semantic code search. The pitch is that an agent with access to real tools produces better results and burns fewer tokens than one grepping through files blind.

That's a quiet but big shift. For two years teams have debated which agent to standardise on. Meanwhile the agents have been converging on the same basic abilities. The thing that differs, and the thing you can actually control, is what the agent can reach.

If you've ever watched an agent spend 40 minutes rediscovering how your test suite runs, you already know this. The model wasn't the problem. The environment was.

Where the code lives is a product decision

IBM's move is the other half. Plenty of companies can't send source code to an external service. Regulated industries, defence suppliers, anyone with data residency rules. For them, "just use the cloud agent" was never an option, and they've been watching the AI coding wave from the sidelines.

Self-hosting removes that excuse. It also means governance stops being a slide in a security review and becomes something you can configure. Which matters, because a recent industry study quoted alongside Qodo's 3.0 launch found 91% of engineering leaders worry about losing control of their codebase. Nearly 30% named governance as the top concern.

You can't fix that fear with a better model. You fix it with boundaries you own.

What we'd do with this

If you're a founder or engineering lead, here's the practical version.

Stop treating the agent choice as a long-term bet. Pick one, run it, and assume you'll change it within a year. Keep your config, prompts and conventions in the repo so switching costs you an afternoon.
Invest in the tooling the agent touches. Fast tests, a one-command dev setup, readable error output, a documented architecture. These pay off for every agent you'll ever try.
Decide where code is allowed to go before someone decides for you. Write down which repos can talk to external agents and which can't. It's a short document and it saves a painful conversation later.
Measure tokens per finished task, not tokens per seat. Better tools mean fewer wasted tokens, and that's the number that shows up on the invoice.

None of this is glamorous. It's plumbing. But the teams who get the plumbing right will swap agents the way they swap CI providers, with a bit of grumbling and no drama.

The takeaway

The agent war is a distraction. The durable advantage sits in your environment: the tools, the guardrails, the context and the rules about where code can go. Build that, and every new agent that ships is an upgrade you can adopt in a week instead of a migration you dread.

We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!