When nobody remembers why

In one minute In our study, about 4 in 10 files in both agent-era and pre-agent projects had a single person behind most of their changes, with no clear difference between eras.¹ What changed is volume: each contributor adds over three times as much new code a week, and it lands on the same owners and reviewers. The risk to manage is lost reasons, because the "why" behind agent-written code tends to stay in chat sessions and people's heads.

A common worry is that agents will hollow out ownership. If a model writes the code, maybe nobody really knows it. Git history lets you check that worry directly, so we did.

What ownership looks like in both eras

Git credits agent-written lines to the person who committed them, and our ownership numbers do the same. "Owner" here means the person whose commits carry the file, whoever typed the lines.

Bus factor is the smallest number of people who together made 80% of the changes to a file or project. A bus factor of 1 means one person made at least 80% of the changes, which is the simplest sign that one head holds the knowledge.

In our study of 200+ popular open-source repositories, we compared agent-era projects (started 2025 or later) with pre-agent projects (started 2021 to mid-2024) at the same age. At 180 days old, 41.8% of files in the typical agent-era project had a bus factor of 1, against 44.1% in the typical pre-agent project.¹ At the 1,000th commit the figures were 52.2% against 33.6%. That gap is wider, and with these group sizes it is not a significant difference. For whole projects, the bus factor was 2 in both groups at both stages.

Figure 5.1

Files still being changed after their main author had stopped working on them were rare in both eras at these ages. The typical project had none.² The ownership habits your teams already have apply to agent-written code too.

The same owners, more code

A bus factor of 2 was normal long before coding agents. In 2016, Avelino and colleagues studied 133 popular GitHub projects and found that 65% had a truck factor of 2 or less.³ Truck factor is a close cousin of bus factor, computed with a different method, named for how many people would have to be hit by a truck before a project stalls.

The volume reaching those few people is what has changed. As chapter 4 showed, each contributor to an agent-era project adds over three times as much new code a week.⁴ The owners of a module are usually its reviewers too, so that code lands on them.

Ownership itself now means something slightly different. Because git credits the committer, "owner" increasingly means "the person who accepted this change", which is a weaker claim than "the person who designed it". An ownership report can look healthy while real understanding thins out underneath.

Reasons are easier to lose than code

When a person writes a tricky piece of code, the reason usually lives in their head, and you can ask them. When an agent writes it, the reason lives in a chat session nobody will open again, in a pull request thread, or in the memory of whoever was driving the agent.

We found no published study that measures knowledge loss in AI-written code specifically. Treat the "why" as something your team writes down on purpose.

Lost reasons cost you in two ways. People repeat old debates, because nobody can find the original one. Agents reverse past decisions they never knew about. An agent that does not know you moved off a library on purpose will add it back, and the pull request will look fine.

Write the why where the code lives

Good teams keep decisions next to the code, in places that travel with it and show up in review.

• An architecture decision record (ADR) is one short file per decision, kept in a folder such as docs/adr/. Four parts are enough: the context, the decision, what it costs you, and the date. Ask agents to draft one whenever a pull request changes a pattern, and review it like code.
• A WHY: comment is one line above code that looks wrong but is right, such as # WHY: refunds skip retry because the provider already retries them. It is the cheapest decision record there is, and it sits in front of the next editor, human or agent.
• A pull request description that opens with the reason for the change keeps that reason in git history, even through a squash merge.

Written context fails in its own way: it goes stale. A README points at a file deleted in March. An onboarding guide links to a heading someone renamed. New hires and agents follow those pointers and either lose an hour or act on old advice, and when code moves faster, docs fall behind faster.

The fix is mechanical. Test every path, link and command your docs mention against the current code, and fail the build when one is gone. Run on every pull request, the check reaches the person who renamed the file while the change is still fresh.

Give agents the context up front

An agent starts each session knowing nothing about your repository's history. It rediscovers the structure by reading files, and it has no way to find a decision made in a pull request thread last spring. Two habits close most of that gap.

First, keep a short config file at the root of the repository, such as AGENTS.md or CLAUDE.md. Put in the rules that matter: which folders not to touch, which decisions are settled. Keep it short and current. A long, stale file does more harm than a missing one.

Second, bring the facts you already have to the moment an agent edits a file. Owners and decision records help only if they arrive at edit time. An agent about to change billing should learn who owns it and that refunds skip retry on purpose. Then your written decisions work as guardrails, and the owner's review queue gets a little lighter.

Do this on Monday

1. For each of your 20 most-changed files, run git shortlog -sne HEAD --since=12.months -- <file>. Where one person dominates, pair a second person with that file.
2. Pick one decision your team made this month and write it down next to the code, as a short ADR or a WHY: comment.
3. Check your README and onboarding docs for paths and links that no longer exist, and fix or delete each one.

How Repowise does this Repowise reads git history to show each file's owner, recent owner and bus factor. The output is a hotspot list with the bus factor and main owner of every busy file, and agents receive the same owners and the decisions tied to a file through MCP tools while they edit.

Sources