Models Are Temporary. Architectural Intent Is Not.

The turnover assumption

The conversation about AI coding usually assumes the model is the constant. The team picks a model, learns how to prompt it, encodes the team’s preferences into a CLAUDE.md or an AGENTS.md, builds workflows on top of the runtime, and treats the surrounding scaffolding as the variable part.

The history of software infrastructure suggests the opposite. The model, the runtime, and the IDE are the things that turn over fastest. The repo, the architecture, and the policies the team committed to are the things that last.

The model is an execution engine. The agent is an operator. The IDE is a surface. The repo is the system of record. Governance belongs outside all of them.

Five roles, one system of record

An AI-assisted development workflow has five distinguishable roles. Four are designed to be swappable on different cycles. One is the system of record.

Architectural intent only stays consistent if it lives in the role that does not turn over. Encoded in any of the other four, it has to be rewritten on every migration and accept inconsistency in the meantime.

The second kind of lock-in

Most "lock-in" conversations focus on the API. Multi-provider routing, vendor diversification, fallback chains. That is the visible cost. There is a second kind that is less visible and more expensive to discover late.

A team can address provider lock-in completely — route across three vendors, swap models on demand — and still have full governance lock-in. The rules live in one runtime’s prompt loading or one IDE’s configuration. The first time the team migrates, the governance has to be rebuilt by hand. The day-of-cutover state is governance-by-good-intentions until the rewrite catches up.

The wrong place to put governance is inside the model

The most common shapes of governance lock-in in AI coding workflows:

• Rules in CLAUDE.md / AGENTS.md. Useful as ambient context. Coupled to the runtime that loads them. Lost the moment the team adds a second harness or migrates to a different one.
• Rules in the system prompt. Coupled to whichever model that prompt was tuned for. Re-tuned on every model change, and silently weaker between tunings.
• Rules in IDE configuration. Coupled to the IDE. Coupled to the per-developer setup. Effectively absent at CI.
• Rules baked into agent harness behavior. Coupled to that harness. Does not propagate to other agents working the same repo.
• Rules in a wiki the agent “reads.” Reading is not obeying. An LLM wiki is a library, not a law.

None of these surfaces was designed to act as the team’s long-lived architectural rulebook. They were designed to make a specific runtime more useful in a specific session. Using them as the place where the rules live is the source of governance lock-in.

What model-independent governance looks like

The alternative is to put the rules in the role that does not turn over. Model-independent governance has four properties:

• Repo-coupled, not model-coupled. The rules live with the code they govern. They are version-controlled alongside it.
• Deterministic. The same proposed change against the same corpus produces the same verdict, every time.
• Multi-surface. The same engine consulting the same corpus runs at the pre-tool-use hook, at pre-commit, at the CI gate, and at the PR check.
• Model-agnostic. Claude in Cursor today, GPT-driven CI tomorrow, a custom agent next quarter — the verdict does not depend on which.

A change that violates ADR-007 at the pre-tool-use hook in Claude Code violates ADR-007 at the CI gate when GPT-driven CI tries to merge the same diff. The model swapped. The verdict did not. That is the testable property.

Why this matters now, not later

Three things are happening at once in the ecosystem that make this argument concrete instead of abstract:

• Models are commoditizing behind OpenAI-compatible APIs. Multi-provider routing is becoming the default, which means the model under any given workflow will turn over more often, not less.
• Agent runtimes are proliferating. Claude Code, Cursor, Copilot, OpenAI Operators, custom agents on the Anthropic and OpenAI SDKs, plus everything Shopify, GitHub, and others are building internally. Teams already use more than one.
• Goal-driven agents are becoming standard. Once the loop runs unsupervised, the cost of a model change is not just retuning a prompt — it is whether the rules the team relied on are still being honored across the new runtime.

The teams that take this seriously now are not predicting a specific future model. They are betting that they will not be using the current one in nine months and want their architecture to outlive that.

How to test whether your governance is model-independent

Three questions. If the answer to any of them is "depends on the model" or "depends on the IDE," the governance is model-coupled in practice.

• If we swapped the underlying model tomorrow, would our architectural rules still produce the same verdicts at the same surfaces? Or would the team need to rewrite anything?
• If a different agent harness opened the same PR, would the CI gate return the same answer? Or does the gate’s strictness depend on which runtime committed?
• If a new engineer joined and used a different IDE on day one, would the architectural rules apply to their commits the same way? Or only after they configure their environment to match?

The teams whose answers are all "same verdict, same surface, same enforcement" have model-independent governance whether or not they call it that. The teams whose answers include "depends on which" have governance lock-in waiting to surface on the next migration.

Closing

The strategic claim is small and durable. Models, agents, IDEs, and providers are categories that change. Architecture, ADRs, dependency rules, and security policies are categories that compound. Governance only compounds with them if it lives where they live, not where the runtime of the moment lives.

Models are temporary. Architectural intent is not. Treat them accordingly.