What Is AI Code Governance?

At AI Summit Barcelona in September, and at the other conferences we’ve spoken at this fall, one question came up after almost every session: what does it mean to govern code that an AI wrote?

My answer is short. The goal is trust. You want to know what goes into your production environments, and you want to be able to prove it.

In Barcelona I spoke with the technology team of a UK-based company. Several systems integrators build for them at the same time, each with its own developers, its own tools and, more and more, its own AI assistants. New code arrives faster than ever, and they’re losing sight of how it’s being delivered. Checking it by hand stopped being possible some time ago. They need a reliable system that keeps up with that speed and holds every partner to the same standard.

The second conversation was with a major pharmaceutical company. Some of its IT people, capable but without a software design background, are experimenting with vibe coding: they describe what they want and an AI builds it. The results work well enough to be tempting. In a regulated business, working code is only the starting point. They need a system that tells them whether what the AI built can be trusted, and that leaves evidence a quality or compliance team can review.

Both are real, and both are happening now. The people and the reasons differ. The need is the same: know what goes into production, and be able to prove it.

Of the six guarantees below, the UK team needs 1, 4 and 6 most: one standard across every partner, the architecture held together, and a record of who delivered what. The pharma team needs 2, 3 and 5: no invented code, nothing more complex than it has to be, and an experienced person deciding what goes live.

Why AI code governance matters now

AI writes a large and growing share of the code teams ship. A senior engineer reading every line used to be the control. When agents write the first draft of most changes, nobody reads every line anymore, and the gap shows up later as an incident.

We measured what that gap looks like. In July 2026 we scanned 424 public projects built with Lovable, Bolt, v0 and Copilot, 21.6 million lines of code in total, with one deterministic ruleset. We found 16 issues per 1,000 lines, and 87% of projects had at least one security finding. The full dataset is open under CC BY 4.0.

One result from that study matters more than the rest. Copilot-assisted repositories, where a person drove the architecture and reviewed the output, came in at 9.1 issues per 1,000 lines. Lovable projects, where the model wrote most of the code on its own, came in at 18.1. The more of the codebase a model writes unsupervised, the worse it gets.

The goal of AI code governance is trust

Trust has a concrete meaning here, and it stands on two pillars.

Control. You decide what is allowed into production. Every change is checked against your standards, and a named person makes the final call.

Evidence. You can prove what happened. Every check, finding, fix and approval leaves a record that someone outside the team can review.

Control without evidence is a claim nobody can verify. Evidence without control is a detailed record of the problems you let through. You need both. With both in place, an engineering leader can answer three questions about any change running in production:

1. Does it meet our standards?

2. Who decided it should ship?

3. Where is the record?

If you can answer those for every change, whoever or whatever wrote it, you have governance. In practice that comes down to six guarantees. The first five give you control. The sixth gives you the evidence.

The six things AI code governance has to guarantee

1. The code follows your standards

Every organization has rules: naming, error handling, security patterns, approved libraries, how services talk to each other, and the rules you added after last year’s incident. An AI assistant knows general good practice and whatever sits in its context window. It doesn’t know your rules unless something checks the code against them.

Governance turns those standards into checks and runs them on every change, whether a developer, a contractor or an agent wrote it. A standard that only lives in a wiki page gets followed when someone remembers it.

2. The AI hasn’t hallucinated

Models invent things with confidence: functions that don’t exist, API parameters from an older version, configuration keys that look right, and packages that were never published. Attackers now register invented package names and wait for someone to install them, a practice called slopsquatting.

Governance checks that what the code depends on is real and approved before it lands: dependencies against an allowlist, wildcard versions flagged, references checked against the libraries and versions you actually run.

3. The code is no more complex than it needs to be

AI tends to over-build. Ask for a small feature and you can get an extra abstraction layer, three helper classes and defensive checks on inputs that can never be null. Each change looks reasonable on its own. After a few hundred of them, the codebase is harder to read, slower to change and more expensive to maintain.

Governance sets limits that no reviewer can hold in their head across every pull request: complexity, duplication, nesting depth, dead code, functions that do five things.

4. The code fits the architecture you chose

An agent sees the files in front of it. It doesn’t know why your system is built the way it is. Left alone, it will put business logic in the UI, call the database from the wrong layer, or add a second way of doing something the codebase already does one way.

Good structure means code that respects your layers and boundaries, follows design principles such as SOLID, and that the next engineer can understand without asking what the agent meant. Architecture is the hardest thing to protect through review alone, because no single pull request shows the drift.

5. A human decides what gets merged

Automation should do the checking. People should make the call. Every change that reaches production needs a named person, or a policy a named person owns, that approved it with the findings in front of them.

Teams under pressure skip this step. An agent that writes the code and then approves its own work gives you a second opinion from the same source. Governance keeps the decision with someone accountable and makes exceptions explicit: when a rule is broken on purpose, someone signs off and the reason is written down.

6. You can trace what happened

When an incident review, an auditor or your CISO asks how a piece of code reached production, a chat transcript won’t answer it. You need a record: which checks ran, what they found, which developer or agent requested them, what was fixed, and what was accepted and by whom.

Traceability is what makes the other five guarantees provable. The record is the evidence you hand to security, audit or a regulator.

AI code governance vs. AI governance vs. code review

The three terms overlap, and people use them interchangeably. They answer different questions.

Code review is one control inside AI code governance. Governance also covers the standards the review checks against, the record that it happened, and the state of the codebase between reviews.

How AI code governance works in practice

Checks only work where the work happens. With AI-assisted development, that means four places:

1. Inside the agent loop. The coding agent calls the governance checks while it writes, gets the findings back and fixes them before a person sees the code. The Model Context Protocol (MCP) makes this possible with most current agents, including Claude Code, Cursor and Copilot.

2. In the editor, for the developer working alongside an assistant.

3. On the pull request and in CI, to cover code that never went through a governed agent: contractors, teams that haven’t connected anything, and the agent nobody told you about.

4. After merge, with full scans of the repository to catch drift that no single change shows.

The earlier the check, the cheaper the fix. A finding the agent corrects mid-task costs nothing. The same finding in production costs an incident.

Why skills and markdown files aren’t enough

Most teams that take AI coding seriously already write their standards down for the agent: a CLAUDE.md or AGENTS.md file, Cursor rules, Copilot instructions, or agent skills that package a whole workflow. That’s a good habit, and we publish skills ourselves. The agent starts with your conventions in its context, and the first draft lands closer to what you want.

Good, but not enough, for four reasons:

1. They’re instructions, not checks. The model reads them and decides how much to follow. In a long session or a long file, rules get diluted or skipped, and nothing tells you when that happens.

2. They only reach the agents that read them. Each tool has its own file format, and a contractor’s agent or a developer’s personal setup never sees yours.

3. They drift. Every repository ends up with its own copy, edited by whoever touched it last, until no two teams follow the same version.

4. They leave no record. A markdown file can’t tell you whether a rule was applied to a given change. It guides the agent, but it gives you neither control nor evidence.

Use skills and markdown files to shape the code. Use checks to verify it, and the record to prove it.

Why the checks should be deterministic

Ask an AI reviewer the same question twice and you can get two different answers. That’s fine for brainstorming and explanation. As a control it fails, because you can’t compare this week with last week, and you can’t defend a verdict to an auditor if rerunning it might change it.

A governance check returns the same verdict for the same code, every time, and writes that verdict down. Use AI reviewers for judgment and context. Keep the gate itself a rule you can rerun.

How to start with AI code governance

Start small and make the first team’s life easier, or the checks will get bypassed.

1. Pick one team or repository where AI already writes a lot of the code.

2. Write down the ten standards that matter most to you, including the ones you learned from incidents, and turn each into a check.

3. Connect the checks where code is produced: the agent loop first, then the pull request.

4. Decide who approves what, and how an exception gets signed off.

5. Keep the record from day one and review it monthly: which rules fire most, which ones are noise, and where the architecture is drifting.

Expand to the next team once the first one stops noticing the checks are there.

Where Norma fits

We built Norma by Quality Clouds for this problem. Norma is the code governance layer for AI-generated code. It connects to your repository, detects the stack automatically, and checks code against your rulesets inside the agent loop through the Norma MCP server, and in VS Code.

Norma’s Livecheck returns the same verdict for the same code every time. Every check leaves an audit record: what was checked, what was found, which client asked, and what was done about it. Quality Gates decide what is allowed through, and a human keeps the final call.

The thinking behind it comes from Quality Clouds’ platform governance work, with scan data collected since 2017 across more than 950 governed enterprise platform instances. Norma has a permanent free tier, so you can put it on a real repository this week.

Frequently asked questions

What is AI code governance in simple terms?

It’s how you make sure code written with AI meets your standards before it ships, with a person accountable for the decision and a record of what happened.

Why does AI-generated code need governance?

Because AI now writes code faster than people can review it. When nobody reads every line, problems reach production before anyone sees them, and nobody can show how a change got there.

How is AI code governance different from AI governance?

AI governance covers how an organization uses AI in general: which models, which data, which uses are acceptable. AI code governance covers the code those tools produce and whether it is allowed into production.

Can’t my AI coding assistant review its own code?

Assistants catch real problems. They check against general good practice and whatever is in their context, their answers can change between runs, and they leave no independent record. Connect the assistant to your governance checks through MCP and it corrects its own output against your rules while it works.

Aren’t CLAUDE.md files and agent skills enough?

They help. They put your standards in the agent’s context, so the first draft is closer to what you want. But they’re instructions the model may or may not follow, each tool reads a different file, and they leave no record. Governance adds the check that verifies the result and the evidence that it happened.

Does AI code governance slow developers down?

It shouldn’t. When the checks run inside the agent loop, most findings are fixed before a person looks at the code, so reviews get shorter. Governance that adds a manual step to every change gets bypassed.

What should an AI code governance record contain?

At minimum: which checks ran on which change, what they found, who or what requested them, what was fixed, which exceptions were approved, and by whom.