Your codebase has a new author

In one minute Nearly every engineering team now uses AI coding tools, and many of the people using them do not trust the output. In a controlled trial, experienced developers took 19% longer with AI while believing they were 20% faster. Governing AI-written code starts with a question most organisations cannot yet answer: how much of our code did an agent write, and where does it live?

Nearly everyone uses it

In Google's DORA survey of nearly 5,000 technology professionals, 90% said they use AI at work.¹ You are no longer deciding whether to allow these tools. Your teams already chose.

The largest companies say the same in public. In October 2024, Alphabet's CEO said more than a quarter of all new code at Google is written by AI, "then reviewed and accepted by engineers."² Google described its number as a governed process with a human approval step. Your board and your auditors will start to expect the same from you.

Few trust it

Use is high and trust is not. In the same DORA survey, 30% of respondents said they have little or no trust in AI-written code.¹ Close to one engineer in three does not trust what the tools write.

Stack Overflow's 2025 survey shows what that distrust looks like day to day. Asked for their top frustration with AI tools, 66% of developers picked "AI solutions that are almost right, but not quite."³

Almost-right code is the hardest kind to review. It compiles and it reads well. The mistake sits in the one branch nobody tested. A team that writes more of it puts more weight on review, whether or not anyone planned for that.

How fast it feels, and what gets measured

Most AI programs are judged on what engineers report: a day saved here, a migration done in an afternoon there. Those reports are sincere, and they are a weak basis for a budget.

METR, an independent research group, ran a randomised trial in early 2025. Sixteen experienced open-source developers worked on 246 real issues in projects they knew well, some with AI and some without. With AI they took 19% longer, and afterwards they still believed AI had made them about 20% faster.⁴ Feeling and measurement ended up about 40 points apart, pointing in opposite directions.

Telemetry from companies tells a similar story at a larger scale. Faros AI looked at 1,255 teams and more than 10,000 developers. Teams with high AI adoption merged 98% more pull requests.⁵ That is the figure that ends up in a quarterly update.

The same data showed review time per pull request up 91%.⁵ The work had moved from the person writing the change to the person approving it. At the company level, Faros found no significant link between AI adoption and throughput or quality. Individual speed showed up in the numbers, and organisation speed did not.

Figure 1.1

The question most teams cannot answer

Try this at your next leadership meeting. Ask: "How much of our code did an agent write last quarter, and which parts of the system is it in?"

Most teams answer a different question. Seat counts tell you who could use a tool, not what shipped. Surveys tell you how people feel, and the METR trial shows how far feeling can drift from fact.

Some teams count commits that name an agent as co-author. That helps, and it gives you a floor. In our study of 200+ popular open-source repositories, 43% of the young projects with almost no agent credits in their commits had still added an agent config file in their first two months.⁶ Chapter 3 shows how to close that gap.

Location matters as much as share. An agent-written test helper and an agent-written payment retry loop carry very different risk. If you know the share but not where it lives, you cannot point review time, refactoring or ownership at the right places.

What the research disagrees on

• Self-reported savings. In Atlassian's 2025 survey of 3,500 developers and managers, 68% said AI saves them more than 10 hours a week.⁷
• Measured slowdown. METR's 2025 trial found experienced developers took 19% longer with AI on code they knew.⁴
• A newer, murkier result. METR's 2026 follow-up with 57 developers leans toward a speed-up, but the range of plausible results includes zero. METR itself calls the data weak, because many developers declined to work on tasks without AI.⁸
• Flat at the top. Faros saw teams merge far more, with no significant change in company-wide throughput or quality.⁵

These studies measure different things: how people feel, single tasks in a lab, and team dashboards. None of them looks inside the repository, at what builds up there over months. The original numbers in this book do, using git history and source code from our study.

Where the book goes from here

The repository view comes one question at a time. Chapter 2 looks at what is piling up in the code. Chapter 3 returns to the question above and shows how to label agent-written changes with evidence an auditor will accept. Chapters 4 and 5 cover review and ownership, where each contributor's extra code lands on the same reviewers. Chapters 6 to 8 are the practical end: paying debt down safely, writing policy engineers will follow, and a maturity model you can score yourself against in ten minutes.

Do this on Monday

1. Ask five tech leads to estimate what share of last quarter's merged code an agent wrote. Write the answers down before you check anything.
2. Count commits from the last 90 days that name an agent as co-author, as a share of all commits (command in the appendix). Treat the result as a floor.
3. Search your repositories for agent config files such as CLAUDE.md, AGENTS.md or .cursorrules, and compare that list with the leads' estimates.

How Repowise does this repowise attribution status reads the markers already in your git history, such as bot authors, co-author lines, "Generated with" footers and agent trace files, and labels every commit as agent, human-attested or unknown. It prints the agent share beside its label coverage, the share of commits it could label, so the number you quote always comes with the evidence behind it. It runs locally and is open source, so you can answer the leadership question from your own laptop this week. Chapter 3 shows a real Change Record.

Sources