Worldview 8 min read

# Models Are Temporary. Architectural Intent Is Not.

In nine months the model is different. In eighteen months the IDE is different. In a year the agent runtime is different. If the team’s architectural rules live inside any of those, the rules turn over every time the tools do. Governance should outlive the model.

By Theo Valmis·May 2026

## 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.

Role 01 Model Generates candidates. Swapped on capability or pricing cycles.
Role 02 Agent Sequences work, calls tools, decides retries. Replaced by the next harness.
Role 03 IDE The surface where the human watches and steers. Migrates with productivity preferences.
Role 04 Provider The API the model is hosted behind. Moves on cost, latency, region, or compliance.
Role 05 Repo The codebase, its ADRs, its policies. Outlives all four above.

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.

Provider lock-in
Visible. API-level.

- Which API hosts the model
- Solved by multi-provider routing
- Cost: SDK rewrites, retesting
- Mostly an integration concern

Governance lock-in
Hidden. Rule-level.

- Where the team’s architectural rules actually live
- Not solved by routing — rules are model-coupled
- Cost: re-encoded per migration, drift in between
- A continuity concern across every model and tool change

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.

Provider lock-in is the rate you pay for an API. Governance lock-in is the price you pay when your architectural rules do not survive your next tool change.

## 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.

Pre-tool hook
Pre-commit
CI gate
PR check

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.

## Frequently asked questions

What does model-independent governance mean?+
Model-independent governance is the property that architectural rules are not embedded inside one model, prompt, IDE, or agent runtime. The rules live as a repo-native control layer, evaluated by a deterministic engine, and produce the same verdict regardless of which model or harness generated the work.
Isn’t this just avoiding provider lock-in?+
Related but not the same. Provider lock-in is about which API hosts the model and is solved by routing or vendor diversification. Governance lock-in is about whether the team’s architectural rules are portable across runtimes. Teams can fully address provider lock-in and still have governance lock-in if the rules are encoded inside one model’s prompts or one IDE’s configuration.
Don’t CLAUDE.md / AGENTS.md / system prompts solve this?+
They help — as ambient context for the runtime that loads them. They are model-coupled and surface-coupled by design. The first time you add a second harness, migrate to a different runtime, or run an agent in CI, the rules do not travel with the change. Treating them as the team’s governance layer is what creates governance lock-in.
How can a team test whether their governance is model-independent?+
Three questions. If we swapped the underlying model tomorrow, would our rules still produce the same verdicts at the same surfaces? If a different agent harness opened the same PR, would CI return the same answer? If a new engineer used a different IDE, would the rules apply the same way to their commits? If the honest answer to any of these is "depends on which model / harness / IDE," the governance is model-coupled in practice.
Related governance concepts

- Model-Independent Governance

  Architectural rules that live outside any one model, prompt, IDE, or agent runtime.

- Governance Infrastructure

  The platform layer that encodes, distributes, versions, and enforces architectural decisions across agents and CI.

- Executable Architectural Intent

  The slice of project knowledge promoted from documentation into enforceable constraints.

- AI Operating Layer

  The coordination layer above governance: intent, tools, agents, memory, execution.

Related operational essays

- OpenAI-Compatible APIs Are Commoditizing Models

  The shape of the provider layer that makes model independence a near-term concern, not a future one.

- Your LLM Wiki Is a Library, Not a Law

  Documentation is context. Governance is constraint. Reading is not obeying.

- AI Is Becoming the Operating Layer for Software Execution

  Why governance is the control plane of the AI operating layer, not a runtime concern.

- Architectural Governance Across Heterogeneous AI Coding Agents

  The multi-agent corollary: governance has to travel across every agent that touches the repo.

- The Agentic Convergence Trap Is an Architecture Problem Too

  If the model is shared, the architecture is the only thing that keeps your codebase from converging on everyone else’s.

- From AI Table Stakes to AI Advantage

  McKinsey’s moat thesis, applied to engineering: the model is rented; the enforced decision layer is owned.