How locked in are you to your AI coding tool?

Ask a team how hard it would be to switch AI coding tools and you will usually get an answer about code: "Not hard, it's just an editor, the repo doesn't change."

That answer is right about the code and wrong about the cost.

The cost is context, not code

What a team accumulates around an agentic tool, over months, is not source code. It is context:

• Instruction files tuned by trial and error until the agent stopped making a particular mistake
• Conventions that exist because the tool behaves badly without them
• Workflows shaped around what this tool does well and around what it does badly
• A shared sense, across the team, of how to phrase a request so it works

None of that is in version control in a form another tool can read. Some of it is in nobody's head in an articulable form at all — it is habit. And habit is the expensive part, because it has to be rebuilt by experience rather than by copying a file.

Why it stays invisible

Lock-in of this kind accumulates in increments too small to notice. Nobody decides to become dependent. Somebody adds a rule to an instruction file because the agent keeps making a mistake. Somebody builds a script around the tool's output format. Somebody stops writing a certain kind of documentation because the agent infers it.

Each step is locally correct. The sum is a workflow that only functions with this tool in the middle of it — and the discovery happens at the worst time, when pricing changes, when a capability regresses, or when a better option appears and the team cannot take it.

Measure it before you need to

The useful exercise takes an afternoon and is worth running quarterly. For each category, ask: if this tool were unavailable on Monday, what would it cost to be productive again?

• Instructions and config. How many hours went into the current instruction files? Would they work elsewhere, or are they written against one tool's parsing?
• Workflow. How many steps in a normal task assume this tool's specific behaviour?
• Team fluency. How long did it take people to get good at it? That is roughly what it costs again.
• Artifacts. Is anything you depend on stored in a format only this tool reads?

Add it up in days. The number is usually larger than expected, and its size is not the point — knowing it is.

Reducing it without giving up the tool

The goal is not portability for its own sake. Refusing to use a tool well in order to stay free of it is a bad trade. The goal is keeping the expensive parts in forms that travel:

• Write conventions in plain Markdown, in the repository, in a widely-read format rather than a proprietary one. The same file feeding several tools is the cheapest insurance available.
• Keep the why with the what. A rule with its reason attached can be re-derived for a different tool. A bare rule cannot.
• Watch for workflow steps that exist only to serve the tool. Those are the ones that will not survive a switch, and often they are not earning their keep anyway.
• Test the assumption occasionally. Run one real task through a different harness once a quarter. It is the only way to find out what you actually depend on, and it is much cheaper as a drill than as an emergency.

The number that matters

Not "could we switch" — you always could. The question is how many days of degraded output a switch would cost, and whether you would accept that number if a materially better option appeared tomorrow. If the answer is no, you are not choosing your tool any more; it is choosing for you.