The AI Runtime Lock-In Trap: Build Your Dev Workflow on MCP, Not on a Vendor

Over a weekend in late June, two of our engineers moved part of their daily workflow onto Antigravity, Google's new home for what used to be Gemini CLI. It was fast, it spoke MCP, and it slotted into how we already work. Within days the MCP connections we had wired up stopped working. The timing matched Google's move of free, Pro, and Ultra access from the standalone Gemini CLI into Antigravity CLI that same week. Antigravity's own docs describe broad MCP support today, so what we hit looks more like transition friction than a removed feature. Either way, the practical result was the same: the setup we had invested a weekend in stopped doing the one thing we adopted it for.

The reflex is to rate the tool and move on. But the thing that broke that week was ours to prevent, and it was never really the tool.

Nothing about our tools stopped working. The MCP servers we connect to still ran. The skills our team relies on were still valid. What broke was the assumption that a specific runtime would keep exposing them the way we had come to depend on. We had let a vendor's roadmap become a load-bearing part of our own.

The distinction decides what you do next. If the problem is a bad tool, you go shopping for a better one and repeat the cycle a quarter later. If the problem is a workflow coupled to one runtime, you change how you build, and the next deprecation costs you an afternoon instead of a week.

AI developer tooling is in the most volatile phase we have seen in a long time. New IDEs, CLIs, and agent runtimes ship on a near-weekly cadence. Each one adds a capability the others lack, deprecates something quietly, or changes how you connect to it between one release and the next. That churn is good for the field and hard on any team that treats such a tool as permanent.

Your workflow does not move at that speed, and it should not. The way your team plans, reviews, ships, and connects to internal systems is a slow-changing asset. When you bind that slow asset to a fast-churning runtime, the runtime's volatility becomes your volatility. A feature you built a habit around can disappear on someone else's release schedule, and you inherit the migration whether you planned for it or not.

We did not pick wrong that weekend. We built on a layer we do not control, and any single vendor would have taught us the same thing eventually.

In an AI-assisted workflow, most of the durable value does not live in the runtime at all. It lives one layer down.

The runtime is the chat window, the editor integration, the agent loop. It is the part vendors iterate on hardest and change most often. Underneath it are the Model Context Protocol servers that expose your databases, your CRM, your internal APIs, and your knowledge base to whatever model is driving. Those tool connections are what took real work to build and what actually carry your business logic.

MCP is deliberately runtime-neutral. A server you wrote against one client works against the next one, because the protocol is the contract, not the vendor. So keep the runtime thin enough to swap, and put the effort you would rather not repeat into the MCP layer. When you build that way, switching runtimes stops being a migration and becomes a config change. The tools point at a new client; the client does not own the tools.

This is the same logic that made us wary of governance controls that only cover one AI client. As we argued in our field notes on building MCP governance for enterprise, a control plane that governs a single client is a feature of that client, not a control plane. Portability has the same shape. A workflow that only runs in one runtime belongs to the runtime, and you are renting it.

The market is already moving this way on its own, which makes portability the conservative choice rather than the bold one.

The clearest sign is what is happening to VS Code extensions. GitHub Copilot, Cursor, and Codex are settling on Agent Plugins, an open standard for packaging skills and MCP servers. Claude Code has its own format, and VS Code reads that one too. What moves between IDEs today is skills and MCP server configs; agent and hook definitions stay with the client you are in. MCP shows the same pattern: the way tools reach external systems is standardizing while the runtimes on top of it keep competing and churning. Bet on the lower layer, not on the runtime above it.

None of this means every tool is interchangeable today. Runtimes still differ in real ways, and some of those differences are worth choosing on. It does mean the parts worth locking in for a year are the portable ones.

After the Antigravity weekend we tightened one rule: durable value goes in MCP servers and skills, not in runtime-specific configuration. A new IDE gets evaluated on its merits, but nothing critical is allowed to live only inside it.

In practice that means a gateway. Rather than wiring every AI client directly into every tool, we put a Local MCP Gateway in between. Clients point at the gateway; the gateway holds the tool connections, the credentials, and the profiles that decide which workflow sees which tools. Swapping a runtime means repointing one endpoint. The tools, the access rules, and the audit trail do not move, because they were never the runtime's to begin with.

For teams that need the supported product layer around that pattern, we package it as MCP Gateway Enterprise. The portability argument and the governance argument are two views of the same idea. A neutral layer in front of your tools is what lets you both govern them and keep them independent of whichever client is in fashion this quarter. Teams that want to work through that model hands-on usually do it with us in the AI security and MCP governance workshop.

Runtime independence is a direction, not a solved problem.

Not every tool is portable yet. MCP servers vary widely in maturity. Some ship clean, spec-current implementations; others are pre-spec, especially on authentication, and take per-server work before they behave the same across clients. Portability is real, but it is not free at the edges.

Runtime-specific features are a genuine temptation. The reason we adopted a new IDE over a weekend is that it did something well. Some of the best capabilities in AI tooling are, for now, runtime-specific. Choosing portability sometimes means passing on a feature that only exists in one place, or accepting that you will lose it if that place changes course. That trade-off is a judgment call, not a rule.

Thin runtimes still need evaluation. Treating the runtime as swappable does not mean treating it as unimportant. You still have to assess each one for how well it drives your models, how it handles context, and how cleanly it speaks MCP. Swappable is not the same as interchangeable.

Before you build a habit around a new AI tool, three questions tell you most of what you need to know.

First, if this runtime disappeared next month, what would you actually lose? If the answer is "a nice interface," you are fine. If it is "half of how we connect to our systems," you have coupled too tightly.

Second, does the value you are adding live in the runtime or below it? Configuration, tool connections, and access rules that live only inside one client are the liability. The same things expressed as MCP servers behind a neutral endpoint are an asset.

Third, could you switch to a competing runtime this week? If switching is a config change, you have portability. If it is a project, you have lock-in, and you are one deprecation away from paying for it.

The Antigravity weekend cost us a few days and taught us something we would rather have learned cheaply. AI runtimes will keep moving fast, and the ones that look permanent today are the ones most likely to surprise you. The defense is not to pick the perfect tool. It is to make the tool the least valuable, most replaceable part of your setup, and to put your real investment in the portable layer underneath.

If you are choosing an AI coding tool right now, we have written a field report comparing Claude Code, Cursor, and GitHub Copilot from production. It covers where each one's integration story holds up and where it does not. And if you want to see what a neutral, runtime-agnostic tool layer looks like against your own workflow, get in touch. We will run the gateway on your systems and tell you plainly where portability still costs you something.