AI code governance without a policy nobody reads

The document trap

Most AI code governance efforts start with a policy document. Someone writes twelve pages about responsible use, everyone acknowledges it in the HR system, and nothing about the code changes. Six months later the same document is cited in an incident review as evidence that the rules existed.

The reason is simple. Engineers make decisions inside an editor, at speed, and a document is not present at that moment. Anything you want followed has to be where the work happens.

Put the rules in the repository

Cursor reads rule files under .cursor/rules, Claude Code reads CLAUDE.md, Codex reads AGENTS.md. Different names, same idea: text in the repo that the assistant reads before it writes. That is where a governance rule becomes operational.

Rules that carry their weight there are narrow and checkable:

• Which directories are off limits, named explicitly by path.
• That generated files and migrations are never hand-edited.
• That tests are not modified to make a change pass.
• Which internal library to use for a thing, so the assistant stops reaching for a new dependency.
• The verification command that must run before a change is called done.

Keep it under a page. A rules file long enough to feel thorough is long enough that both the model and the humans skim it.

Enforce in the pipeline, because rules files are advisory

This is the part teams skip. A rules file is a strong suggestion, not a control. An assistant can ignore it, and a person can delete it. Anything that actually matters needs a deterministic check that runs whether or not anyone cooperated.

Four checks cover most of the real risk. Secret scanning on every commit, because agents read and sometimes echo config files. Dependency review on every pull request, because assistants add packages casually and a plausible-sounding package name is a supply chain problem. A licence check, since generated code occasionally arrives with a licence header nobody meant to accept. And a size limit that flags any pull request over a few hundred lines for extra scrutiny, since review quality falls off a cliff past that point regardless of who wrote the code.

Notice that none of these ask whether the code was AI-generated. That question is unanswerable at scale and mostly beside the point. Govern the change, not its provenance.

What AI code governance should not try to do

Do not require engineers to label AI-assisted commits. Compliance decays within weeks, the data is unreliable, and it creates a two-tier culture where some code is treated as suspect. Do not build an approval queue for using the tool, which pushes people onto personal accounts and makes visibility worse. And do not make a model-based review a blocking merge gate, since its output varies run to run and a flaky gate teaches people to route around gates in general.

The measure that tells you whether any of this is working is not tool adoption. It is change failure rate and time to restore, split by team, before and after. If those hold steady while throughput rises, your governance is adequate. If failures climb, the problem is almost always pull request size, not the assistant.

Where to start on Monday

Pick your highest-risk repository. Write a one-page rules file in whatever format your tool reads. Turn on secret scanning and dependency review. Then look at your last month of pull requests and find the median size. If it is over 400 lines, fix that before you write another word of policy.

If you want help putting this into practice, talk to us.