The AI Code Governance Maturity Model

In one minute Governing AI-written code comes down to six dimensions, one per chapter, each with five levels you check against evidence you can open today. Your level is your lowest row. Levels 1 to 3 run on git, CI and a spreadsheet, and a 90-day plan takes a typical team from seeing the problem to governing it.

Sooner or later, leadership asks two questions about coding agents: how much of our code do they write now, and is it safe? The model below is the page you hand over in reply. It folds chapters 2 to 7 into one table, with six dimensions and five levels each. Each cell describes something you can show: a list, a report, a CI log, a file in the repository. If you cannot open it today, you have not reached that cell, however good the intent.

Many maturity models score how widely a tool is adopted, or how developers feel about it. This one is a checklist of evidence in and around your code, and it leaves individuals out of it.

Five levels, six dimensions

The levels describe how you know things. At level 1, Unaware, the facts sit in git history and nobody has pulled them out. At level 2, Visible, someone has looked once and can name the problem areas. At level 3, Measured, the same numbers are taken on a schedule, so you can see a trend. At level 4, Governed, the numbers decide what happens to a change before it merges. At level 5, Learning, you check your rules against what later broke, and change the rules.

The dimensions follow the chapters. Debt is where too-big functions pile up. Authorship is knowing what an agent wrote. Review is how changes get checked before merge. Knowledge is who understands the code and why it looks the way it does. Paydown is how debt gets cleared. Policy is your written rules, plus the proof you followed them.

Read each row from left to right. The levels stack. A cell counts only if every cell to its left is also true.

Score yourself in ten minutes

Do this with one staff engineer who knows your main repositories. Skip the survey. A survey measures belief, and this needs proof.

1. Pick one product area, or your three to five busiest repositories. Scoring the whole company at once blurs everything.
2. For each row, start at level 2 and ask, "Can we open the proof right now?" Move right until the answer is no. Your score for that row is the last yes.
3. Give no partial credit. "We sort of do that" is a no. A dashboard nobody has opened since spring is a no.
4. Take the lowest row as the level for the whole area. That is the only scoring rule. The other rows show where you are ahead and which habits you can copy across.

The check takes about ten minutes because you only ask whether the evidence exists. Gathering it is what the 90-day plan below is for. Expect a ragged profile: Review often scores a level above Authorship, because pull request rules existed long before agents did. The scorecard at the end of the book asks the same thing as 24 yes or no questions.

A 90-day plan from Visible to Governed

The plan assumes a team at level 1 or 2 on most rows. It ends at level 3 everywhere, and level 4 on Authorship, Review, Knowledge and Policy. Everything up to level 3 runs on git and your CI, with a spreadsheet for the numbers; the exact git commands are in the appendix. Level 4 on Authorship needs a record for every merged change, which means an attribution tool or a small pipeline you build yourself.

Days 1 to 30: make every row Visible

• List the 25 most-changed files in each of your five busiest repositories over the last 90 days. Mark the ones with three or more bug fixes in six months.
• Count agent commits per month from author names and Co-authored-by trailers. Then find the date each repository added an agent config file, such as AGENTS.md or CLAUDE.md.
• Turn on agent trailers in every agent's settings. Add one line to the pull request template: "AI assistance: none, partial or mostly, and which tool."
• Check that CODEOWNERS covers the busiest directories, and turn on branch protection so owners must approve.
• Write your change rules as five plain sentences. Mark any you cannot check from git or CI as manual.
• Publish the top 10 files per repository to the teams that own them.

Days 31 to 60: measure on a schedule

• On the first of each month, count the too-big functions that also changed this quarter, with the same cut-off every time, and give each one a named owner and a plan. Splitting a function to shrink the count does not count as a plan; chapter 6 shows why.
• Report the agent share with its label coverage, as chapter 3 describes. Below 3 in 10 commits labelled, report counts only.
• Find the 95th-percentile size of your last 100 merged pull requests. Anything bigger, or touching a file with repeated fixes, gets a second reviewer.
• Work out the bus factor, defined in chapter 5, for your 25 busiest files.
• Reserve a fixed share of each sprint for the top-10 list. Count edits to each area before you start.

Days 61 to 90: let the numbers decide

• Give every merged change a record with author, reviewer, tests run and AI assistance. Export it monthly to storage with retention, and spot-check ten records each quarter.
• Turn the second-reviewer rule into a CI check, and run the tests that reach the changed files first.
• Pair each top-10 hotspot with a second person and a one-page decision record.
• Move every rule CI can check into a policy file. Log each exception with a name and a reason.
• Rescore with the scorecard, send the six levels to leadership, and repeat each quarter.

Debt and Paydown often sit at level 3 on day 90, because code takes longer to change than a process. Level 5 needs a few quarters of history before you can test a rule against outcomes, so it belongs in the second half of the year.

Who wrote this, and is it safe to keep building on?

Every merge now asks that question, whether or not anyone answers it. At level 1 the answer to both halves is a guess. At level 3 you can answer the first half with a number and its label coverage, and the second half with a trend. At level 4 you answer both for a single change, before it merges, with a record an auditor can read.

Agents will keep getting faster, and the question stays the same. Level 4 is where you answer it with a record instead of a guess.

Do this on Monday

1. Book ten minutes with a staff engineer and score your busiest product area against the table.
2. Put the six row scores on one slide and circle the lowest. That row is your first 30 days.
3. Pull the 10 most-changed files in your busiest repository and share the list with its team.

How Repowise does this Repowise fills levels 2 and 3 from your git history and code: hotspots and health scores, agent share printed with its label coverage, and bus factor per file. For level 4, repowise check runs your change policy on every change, each merged pull request becomes a Change Record you can export in the in-toto format, and a CI step can hold the riskiest changes for a second look. For level 5, a health accuracy check compares your lowest-scoring files with where fixes landed. Your team still writes the rules.