AI Coding Governance Should Be Reviewable

When something goes wrong with an AI coding agent — a banned framework gets introduced, a cross-boundary call slips into production, a deprecated pattern resurfaces after three ADRs told the team to stop using it — the first question an engineering lead asks is: what was the agent operating under when this happened?

With most current AI tooling, you cannot answer that question. The constraints the agent was aware of exist somewhere in accumulated prompt history, a cloud memory service, or per-session context that was never persisted. The governance state is opaque. The incident is unreproducible. The audit trail is empty.

This is not an edge case. It is the default condition for AI coding governance today.

The assumption most teams haven't questioned

AI memory, as most tools implement it, inherits its design from consumer AI assistants: hidden embeddings, cloud persistence, black-box retrieval, state that accumulates behind an API. The mental model is a human assistant who "remembers" things. The implementation is a vector database that approximates similarity.

That model made sense for knowledge lookup. It makes no sense for engineering governance.

We do not accept hidden state in the rest of our engineering infrastructure. Terraform files are version-controlled. Kubernetes manifests are reviewed in pull requests. CI pipeline configuration is committed alongside the code it governs. The principle is consistent: if it controls how software is built and deployed, it should be visible, versioned, and reviewable.

AI coding governance controls how software is built. It should be held to the same standard.

What reviewable governance actually means

Reviewable governance is not just "we can read the config." It is a set of properties that the governance state must have for engineering teams to trust and maintain it:

• Versioned. Every change to a constraint has an author, a timestamp, and a commit message. You can answer: who added this rule, when, and why.
• Diffable. When architectural decisions change, the change is visible as a standard file diff. Engineers can see exactly what shifted between the last governance state and the current one.
• Reviewable in a PR. New constraints, superseded decisions, and rule updates go through the same review process as the infrastructure they govern. The team can debate, approve, or block a governance change before it takes effect.
• Co-located with the repository. The governance state lives next to the code it governs. It is not in a separate cloud service or in an IDE's local config. When you clone the repo, you get the governance state. When you branch the repo, the governance state branches with it.
• Auditable after the fact. If a violation occurs, you can check out the exact commit where the agent was operating and read the constraints it was applying. The incident is reproducible. The investigation has evidence.

How this differs from current approaches

The contrast with existing approaches is concrete:

None of these approaches produce governance state you can review in a pull request. None of them produce governance state that branches when your codebase branches. None of them produce governance state an auditor can examine six months after an incident.

Repo-native governance as engineering infrastructure

Mneme stores its governance state as a structured JSON file — project_memory.json — co-located with the repository it governs. The file contains architectural decisions, constraints, and prior decision records in a format that is human-readable, machine-executable, and version-controlled.

This is not a clever trick for working around vector databases. It is a deliberate architectural commitment to a different model of what governance state is.

When a new ADR supersedes an old one, the change is a pull request. Reviewers can see exactly what constraint was removed, what replaced it, and why. The governance history is the git history.

Why this matters for enterprise trust

The reviewability property connects directly to the concerns that block AI coding adoption at the enterprise level:

• Compliance and audit. Regulated industries require an audit trail for decisions that affect production systems. Governance stored in git satisfies this. Governance stored in a cloud vector store does not.
• Deterministic behavior. If the same query always retrieves the same constraints, behavior is reproducible. If retrieval is probabilistic, the same task may be governed differently on different days — which is not a property enterprises can accept in production AI workflows.
• Multi-agent consistency. When multiple agents — Claude Code, Cursor, a CI governance gate — operate against the same repository, they all draw from the same governance file. There is no per-session state drift, no agent-local divergence, no inconsistency between what the IDE agent allowed and what the CI gate blocks.
• Governance state travels with the repo. When a team forks the codebase for a new product line, the governance state forks with it. When a contractor clones the repo, they get the constraints. When an agent runs in CI on a branch, it applies the branch's governance state.

Governance decisions are infrastructure decisions

The deeper principle here is architectural. Governance decisions — "we use Pub/Sub, not Celery," "BigQuery clients live in backend services," "no raw SQL string concatenation in production paths" — are engineering decisions with the same authority and permanence as the infrastructure decisions they constrain. They should be stored with the same discipline.

Treating AI constraints as ephemeral prompt context is the wrong mental model. Treating them as version-controlled engineering infrastructure — subject to review, authorship, and audit — is the right one.

Most teams haven't confronted this distinction yet because they're still in the early phase of AI coding adoption, when the volume is low enough that opaque governance is survivable. As agent usage scales, the distinction will become unavoidable. Unreviewed governance state will produce unauditable violations. Opaque constraints will produce irreproducible incidents. Hidden AI memory will produce engineering debt that no one can trace.

The time to establish the right model is before that debt accumulates — not after it.