Ownership When Nobody Typed the Code

Ownership When Nobody Typed the Code is the accountability problem the rest of the operating model rests on. Chapter 8 built a reversal path, and somebody has to decide to use it at three in the morning, for code that no person in the building composed line by line.

Key takeaways

• Bird and colleagues, in 2011, defined a minor contributor as a developer with under 5% of a component's commits, found that components with many minor contributors show more pre-release faults and post-release failures, and recommended that minor-contributor changes get greater scrutiny, ideally from a major contributor.
• Every generated change has minor-contributor shape. The submitter often has no accumulated context in the file, which is the exact condition that research associated with defects.
• Ownership is answerability, not authorship. It means a named person who can explain what a path does, disable it, and decide to revert it, without needing the person who submitted the change.
• GitHub's code owners documentation states that the last matching pattern takes the most precedence, that any single owner's approval is sufficient where branch protection requires code-owner review, and that owners are not automatically requested on draft pull requests.
• Trust is not accountability. DORA's 2025 report found 30% of respondents report little to no trust in AI-generated code, and a distrusted change with no named owner still ships.

Read this after Chapter 8, whose reversal path needs someone authorised to pull it, and alongside Chapter 6, whose routing table already assumed a named owner per exit. Chapter 10 turns the same ownership records into the evidence a security reviewer asks for.

The incident review asks a simple question. Who owns this module.

The commit log shows eleven contributors in six months, none with more than a few changes. The person who submitted the change that caused the incident describes what they asked for, and cannot explain why the retry loop is where it is, because they did not write it and did not need to.

Nobody is being evasive. The information genuinely does not exist in anybody's head. It used to exist as a side effect of typing, and nothing replaced it.

Authorship stopped being a proxy for understanding

For thirty years, the commit log was a reasonable map of who understood what. Writing code required holding its context, so the author was the expert by construction.

That coupling is gone. A submitter can produce a correct, idiomatic, well-tested module in a service they have never reasoned about, and the diff will not reveal the difference.

Two consequences follow, and organisations usually notice the second one first. Expertise no longer accumulates automatically, so it has to be built deliberately, which is Chapter 13. And accountability can no longer be inferred from a log, so it has to be assigned, which is this chapter.

Faros AI, which sells engineering-productivity analytics, reports that fewer than 1% of pull requests in its dataset are opened by AI agents as of March 2026. So a human name is still on almost every change. The name is real. The implied expertise is not.

Ownership, defined as answerability

Ownership of a path in the codebase means a named person who can explain what it does and why, who is authorised to disable or revert changes to it, and who is accountable for its behaviour in production, independent of who submitted any particular change.

Three distinctions make that definition usable. Authorship is a historical fact about a commit. Ownership is a current assignment about a path. Accountability is what happens at three in the morning, and it needs a person rather than a team, because a team is nobody at that hour.

The test for whether ownership is real is a question you can ask on a Tuesday. For this directory, who do I page, and can they turn it off without help.

If the answer is a team name, you have a routing rule. If the answer is a person who would need to find the submitter first, you have a courtesy.

What the ownership research actually found

The evidence here is fifteen years old and its age is worth stating in the same breath as its finding. Bird, Nagappan, Murphy, Gall and Devanbu published Don't Touch My Code at ESEC/FSE in 2011, studying Windows Vista and Windows 7.

Their definitions are the useful part. A major contributor has a substantial share of a component's commits, and a minor contributor is a developer with under 5% of them. Their finding is that high levels of ownership, and low numbers of minor contributors, are associated with fewer defects, and that components with many minor contributors show more pre-release faults and post-release failures.

Their first recommendation is the one to lift. Changes made by minor contributors should be reviewed with more scrutiny than changes made by developers experienced with that source, and where possible a major contributor should perform those inspections.

The paper is careful about its own scope and I will be too. It notes that Microsoft employed strong ownership practices, and that its results are much more likely to hold in other industrial settings where similar policies are in place. This is a correlation in two large projects, not a law.

Every generated change is a minor-contributor change

Set the 2011 definition against current practice and the implication is immediate. A submitter who has never worked in a component, using an agent to make a competent change to it, is a minor contributor to that component in exactly the sense the paper measured.

That is not an argument against the practice. It is an argument that the scrutiny recommendation now applies to a much larger share of arriving change than it did when the paper was written.

Which collides directly with Chapter 6. Triage says read less, and this says read minor-contributor changes more carefully, so the two have to be reconciled rather than left in tension.

The reconciliation is that contributor history becomes an input to the risk predicate. A change in a path where the submitter has no history is routed to the path's owner, regardless of size. A change by the owner in their own path can take a lighter route. One rule, mechanically evaluated. It does more for quality than any appeal to care.

The CODEOWNERS mechanics that decide whether it works

Ownership needs a mechanism or it is a wiki page. GitHub's code owners feature is the common one, and several documented details decide whether it does what you think.

Owners are automatically requested for review on changes matching their patterns, and where branch protection requires code-owner approval, GitHub's documentation states that an approval from any of the owners is sufficient. That last clause matters: listing five people does not mean five reviews, it means one review from a set.

The precedence rule catches teams out. GitHub's documentation states that the last matching pattern takes the most precedence, which is the opposite of what many people assume from gitignore-style intuition. Order your file from general to specific, and test it.

Three limits are worth knowing before you plan around them. The file cannot exceed 3 MB and will not load above that size. Owners are not automatically requested on draft pull requests, so a change that spends its life as a draft never notifies anybody. And users and teams listed as owners need explicit write access, or the entry silently does nothing. The file must live in the repository root, in the .github directory, or in docs.

Ownership, authorship and accountability, separated

The table below separates three things that used to travel together, which is the distinction this chapter exists to make.

The bottom two rows are the ones to get right, and they are the two that no tool assigns for you. The top row is the one most organisations still act as though they can rely on. It is a log entry. It was never a control.

On-call for code nobody read closely

An on-call engineer holding a service where most code was generated needs a different kind of preparation, and the useful test is three questions they must be able to answer without a colleague.

What is this path for, in one sentence, and what does it depend on. How do I disable it, meaning the flag name or the revert command from Chapter 8. And what would tell me it is misbehaving, meaning the specific signal rather than a general dashboard.

If a runbook cannot answer those three for every risk-marked path, the on-call rotation is a notification list. Generating that runbook content from the specification and standing context is reasonable, and it should be reviewed by a person, because a runbook nobody read is the same failure one level up.

One more habit is worth the small cost. When an owner is assigned a path they did not write, give them an hour to read it and write those three answers themselves. That hour is the cheapest expertise transfer available and it is the practical version of Chapter 13's argument.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A services team owns nine repositories and has an ownership file in each. All nine list the same team handle at the root and nothing else. The file is technically correct and operationally useless.

They rewrite it over an afternoon. Nine risk-marked paths get a named individual, not a team, each with a stated deputy. The root pattern stays as a team handle, because most paths genuinely do not need an individual. The patterns are ordered general to specific, and somebody tests three files against the resolver to confirm the last-match rule behaves as expected.

Then the part that took longer than the file. Each named owner spent an hour writing the three runbook answers for their path, and four of the nine discovered they could not answer the disable question, because no flag existed.

Those four gaps were the real finding. The ownership exercise did not improve the code. It found four paths with no off switch, which is Chapter 8's work arriving through a side door.

The objection: this punishes people for using the tools

The objection is that treating a change as minor-contributor work because the submitter lacks history in that file penalises exactly the behaviour you asked for, and it is a fair reading of the policy as stated.

Three parts to the answer. The routing decision is about the change, not about the person, and it should be phrased and implemented that way, evaluated from the diff and the history rather than from anybody's judgement of a colleague. It is temporary per person and per path, since history accumulates and the lighter route opens as it does. And it replaces something worse, which is a uniform approval requirement that produced a queue and, per Faros AI, a 31.3% rise in changes merged with no review at all.

The version of the objection I take more seriously is about trust. DORA's report of 24 September 2025 found 30% of respondents report little to no trust in AI-generated code, with its full distribution showing 4% expressing a great deal of confidence, 20% a lot, 46% somewhat, 23% a little and 7% none. An ownership policy that reads as institutional suspicion will be resented.

So frame it as what it is. Ownership is not a check on the submitter, it is the guarantee that somebody can answer for a path at three in the morning, and that guarantee is what lets the organisation stop reading everything.

Chapter summary

Authorship stopped being a proxy for understanding, because a submitter can now produce a correct, idiomatic change in a service they have never reasoned about, so accountability has to be assigned rather than inferred from a commit log. Ownership means a named person who can explain a path, disable it, and decide to revert it without needing whoever submitted the change, and the test is whether you can name who to page and confirm they can turn it off unaided. Bird and colleagues, in a 2011 study of Windows Vista and Windows 7, defined a minor contributor as having under 5% of a component's commits, found that high ownership and few minor contributors are associated with fewer defects, and recommended that minor-contributor changes receive greater scrutiny, ideally from a major contributor, while noting their results are much more likely to hold where strong ownership is already practised. Almost every generated change now has minor-contributor shape, which collides with Chapter 6's triage until contributor history becomes an input to the risk predicate, routing changes in unfamiliar paths to the path's owner regardless of size. The mechanism has documented details that decide whether it works: any single owner's approval suffices under branch protection, the last matching pattern takes the most precedence, the file cannot exceed 3 MB, owners are not requested on draft pull requests, and listed users need explicit write access. On-call needs a runbook answering what a path does, how to disable it, and what signals misbehaviour. And since DORA found 30% report little to no trust in AI-generated code, the policy has to be framed as a guarantee of answerability rather than as suspicion of colleagues.

Ownership records who answers for a path. A security reviewer and an auditor want the same records, plus evidence that specific classes of defect were looked for. Chapter 10 is Security and Compliance Inside the Loop.