Free field guide
Who Wrote This?The AI code governance guide
The engineering leader's guide to governing AI-written code, and the technical debt that comes with it.
By Raghav Chamadiya, co-founder of Repowise
8 chapters, a maturity scorecard and a do-it-yourself appendix.
PDF, 71 pages, about 55 minutes. Or read the chapters online, free.
Executive summary
Five findings, five actions.
Your engineers already work with coding agents, and your repository is changing shape faster than your dashboards can show. The guide measures that change and turns it into a plan you can start on Monday.
- 4.5x
Popular open-source projects built with coding agents carry about 4.5 times the share of too-big functions that projects started in 2021-22 had at the same age, and about 3 times after accounting for codebase size.
Our study of 200+ open-source repositories, 2026, observational, projects compared at the same age. Chapter 2.
- 34/79
Commit trailers miss much of the agent use: 34 of 79 young projects that barely credited agents still added an agent config file within two months.
Our study of 200+ open-source repositories, 2026, observational, young projects with few agent credits. Chapter 3.
- 3.3x
In agent-era projects, each contributor adds over three times as much new code a week as in older projects of the same age, and all of it lands on the same reviewers.
Our study of 200+ open-source repositories, 2026, observational, lines added per contributor-week at six months. Chapter 4.
- 41-57%
Splitting a big function moves the work: its new helpers take 41% to 57% of the later edits in that area.
Our study of 200+ open-source repositories, 2026, observational, later edits after a split. Chapter 6.
- 19%
In a controlled trial, experienced developers were 19% slower with AI while believing they were faster.
METR randomised trial, 16 developers, 246 issues, early 2025. Chapter 1.
Five actions
- 01
Report the agent share of your code only with its label coverage, the share of commits you could label at all.
- 02
Name the 20 functions that are both too big and busy, and give each one an owner.
- 03
Order the review queue by each file's fix history, and save second reviewers for the top of it.
- 04
Write the reason behind every settled decision next to the code, where agents and new hires will read it.
- 05
Turn one review rule you already follow into a CI check this month, in warning mode first.
A look inside
Written to be read on a phone, in about 7 minutes a chapter.
Swipe for more pages.
A chapter openerEvery chapter starts with its point in one minute. Chapter 2, Debt at agent speed. 
The data, drawn plainlyFigure 2.1: too-big functions by the date each project started, one dot per repository. 
The maturity modelSix dimensions and five levels, scored against evidence you can open today. 
Do this on MondayThree actions to close every chapter, with the tools you already have.
Contents
Eight chapters, a scorecard and the recipes.
Each chapter opens with the point in one minute and closes with three things to do on Monday. Read any chapter here; the scorecard and the recipes come with the PDF.
- 01
Your codebase has a new author
How much of your code an agent wrote, where it lives, and why most teams cannot answer yet.
- 02
More too-big functions at the same age, on a list still short enough to name and own.
- 03
Label each change as agent, human-attested or unknown, and keep one record per merged change.
- 04
Point a fixed amount of reviewer attention at the code that history says breaks.
- 05
Single-owner files show no clear difference between eras. Keep the reasons behind decisions where agents and new hires will read them.
- 06
Paying it down without breaking things
Plan each split around how the code changes, and judge it by the whole area.
- 07
Policy engineers will actually follow
The change-management questions you already ask, answered with evidence on every change.
- 08
The AI Code Governance Maturity Model
Six dimensions, five levels each, and a 90-day plan to move up.
- +
Scorecard and do-it-yourself appendix
A ten-minute self-assessment, plus git and shell recipes for every measure in the book.
Template
AI coding policy template
A short acceptable use policy for engineering teams that work with coding agents. Copy it, fill in the brackets, and keep it in the repository next to the code it governs. It is built on provenance and accountability: record what produced each change, and name the person who owns it.
# AI coding policy for [Company] engineering
Owner: [name, role]
Approved by: [name, role]
In effect from: [date]
Next review: [date, no more than six months out]
## 1. Scope
This policy covers every change to [Company] repositories that a coding agent or
AI assistant helped write: application code, tests, configuration, infrastructure
as code, documentation and commit messages. It applies to employees, contractors,
and any bot or background agent that opens pull requests.
## 2. Approved tools and models
- Approved agents and assistants: [e.g. Claude Code, Cursor, GitHub Copilot, Codex].
- Approved models and providers: [list], used only through accounts [Company]
controls, under data terms [legal or security] has reviewed.
- Agent config files (AGENTS.md, CLAUDE.md, .cursorrules,
.github/copilot-instructions.md) live in the repository and are reviewed like code.
- To add a tool or model, open a request with [team]. Personal accounts and
unapproved tools are not used on company code.
## 3. Data and secrets
- Never put secrets, credentials, customer data or personal data in a prompt.
- Agents get the least access the task needs: no production credentials, and
read-only access wherever it is enough.
- Repositories classed as [restricted] are used only with [approved setup, e.g.
a self-hosted model or a local-only tool].
- Secret scanning runs as a pre-commit hook and again in CI.
## 4. Provenance and attribution
- Every change records which agent and model helped write it: a
`Co-authored-by` trailer on the commit, or the field in the pull request template.
- A change with no record is reported as unknown. It is never assumed to have
had no agent involved.
- When we report how much code agents wrote, we report label coverage with it:
the share of changes we could attribute at all.
## 5. Review and merge
- Every change is approved by a reviewer other than its author before it merges.
An agent can author a change. It cannot approve one.
- Changes to [payments, auth, data deletion, ...] need approval from a named code
owner, enforced with CODEOWNERS and branch protection.
- Changes over [N] lines must reach at least one test, or be split.
- Required CI checks pass before merge. No merging on a failing required check.
## 6. Accountability
- A named person owns every agent's changes: the engineer who started the agent
session, or the team that owns the automation. That person answers for the
change in review and in incidents.
- Every bot or background agent that opens pull requests is listed in [registry]
with its owning person or team.
## 7. Security and licensing
- Dependency, license and secret scans run on every change. A dependency an agent
adds needs the same approval as any other new dependency.
- Generated code that reproduces third-party code under an incompatible license is
not merged. Where a tool offers a public-code filter or reference check, keep it on.
- Security-sensitive changes follow [secure development policy].
## 8. Incidents
- Incident reviews start from the change that shipped: its files, author,
reviewer, and the agent and model recorded on it.
- When an agent-written change contributed, fix the prompt, rules or agent config
that produced it, and record the reason next to the code.
- Report a suspected data exposure through an AI tool to [security contact]
within [24 hours].
## 9. Exceptions
- Any override of this policy is logged with who, when and why. The log is read
at every policy review.
## 10. Review cadence
- [Owner] reviews this policy every [quarter / six months], and whenever an
approved tool or model changes.
- Each review reads the exception log, label coverage for the period, and every
incident that involved an agent-written change.
How Repowise supports this policy
- Reads the provenance markers already in your git history (bot accounts, commit trailers, git-ai notes and Agent Trace files), labels each commit from that evidence, keeps unknown as its own label, and shows any agent share with its coverage.
- Turns each merged pull request into a Change Record with its commits, files, author and provenance.
repowise changes show --format in-totoexports a record for your audit store. - Runs the rules you write in
.repowise/policies.yamlon every change withrepowise check, locally or in CI, with SARIF or JUnit output. A rule whose evidence is missing reports as not evaluated, never as a pass. - Offers opt-in hooks for Claude Code, Codex and Cursor that record which lines an agent wrote as it writes them, storing line hashes, never prompts or code.
See agent provenance in Repowise for the labels and coverage, or chapter 7, policy engineers will actually follow, for the controls this maps to.
The data
Built on our study of 200+ popular open-source repositories.
- 200+
- popular open-source repositories, read commit by commit
- 131 vs 80
- projects started in the agent era, against projects started before it
- 4 stages
- compared at the same age: 90 days, 180 days, the 300th and the 1,000th commit
The method and the cohort lists are in the guide's appendix.
FREQUENTLY ASKED
AI code governance, answered
What is AI code governance?
AI code governance is how an engineering team decides which coding agents and models may change its code, records which changes they made, and holds every change to the same review, testing and ownership rules. It answers two questions with evidence: what produced this change, and which person is accountable for it.
Do we need an AI coding policy?
If your engineers use coding agents, yes, and it can be short. Most of it extends the change management rules you already have: approved tools and models, data and secrets rules, how agent changes are recorded, who reviews them and who owns them. The template on this page covers that in ten sections, and chapter 7 shows which rules hold up in practice.
How can we tell which code an agent wrote?
Start with the evidence your repository already holds: commit trailers such as Co-authored-by lines, bot accounts, and the date an agent config file such as AGENTS.md or CLAUDE.md first landed. Trailers miss a lot. In our study, 34 of 79 young projects that barely credited agents in commits still added an agent config file within two months. Keep changes with no evidence as unknown, and report label coverage, the share of changes you could attribute at all, beside any share. Chapter 3 covers the method.
How should we review AI-generated code?
With the same bar as any change, aimed where it matters. A fixed amount of reviewer attention now covers more code: in our study, each contributor to an agent-era project added 3.3 times as much new code a week at six months as in older projects at the same age. Order the review queue by each file's fix history, run the tests a change actually reaches, and keep changes small enough to read. Chapter 4 covers each step.
What does an AI code governance framework include?
The guide's maturity model has six dimensions: debt, authorship, review, knowledge, paydown and policy. Each has five levels, from Unaware to Learning, and each cell is evidence you can open today, such as a list, a report or a CI log. Your level is your lowest row. Chapter 8 has the full table and a 90-day plan.
Does SOC 2 cover AI-generated code?
SOC 2 has no criterion written for code from AI tools. Its change management criterion, CC8.1 in the AICPA Trust Services Criteria, asks that changes are authorized, designed, developed, configured, documented, tested, approved and implemented, and that applies to every change however it was written. Auditors usually sample changes and look for an authorization, a test result and an approval on each. A record of which agent and model helped write a change adds authorship evidence the commit author field does not give. Your auditor decides which evidence they accept.
Does the EU AI Act apply to code written with AI coding tools?
The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems by the risk of their use, with duties for the companies that provide them and the companies that use them at work. It has no rule aimed at source code because an AI assistant helped write it. A team using coding tools at work still has the general duties of a deployer, such as AI literacy for staff under Article 4, and a product that is itself an AI system may carry more. What applies depends on your product and market, so check with your counsel.
Who is this guide for?
Engineering leaders, platform and developer experience leads, and staff engineers whose teams work with coding agents such as Claude Code, Cursor, Copilot or Codex. The whole guide reads in about 55 minutes, about 7 minutes a chapter.
Is it free?
Yes. All eight chapters are free to read on this site. Leave your work email and the PDF downloads straight away. We also email you a link so you can find it later.
What do you do with my email?
We send you the guide, and occasional emails about our research and product updates. You can unsubscribe at any time. We keep any name, company and role you give us with your email, and the privacy policy has the details.
Is there a vendor pitch?
A short box at the end of each chapter says how Repowise does that chapter's work. The rest is a playbook you can run with the tools you already have.
Read it this week. Measure it on your own code next week.
The guide is free. Repowise reads your code graph and git history and hands your agents and reviewers the same evidence the guide uses.