AI Wrote It. Nobody Owns It. Bus Factor Just Went Up.

TL;DR: The old bus factor was one person holding the knowledge. The agentic-era version is worse: areas of your codebase that no human ever deeply held, authored by agents, approved under review pressure, churning fast. Ownership research ties low-expertise contribution to failures, and an unowned area fails the 2am test no matter who typed it. Map review-weighted ownership over your AI-heavy areas and you'll see the hole before an incident does. Here's how, starting with free git archaeology.

The incident channel is lively tonight. The failing service gets named, someone pastes the stack trace, and then comes the question that used to have an answer: "Who knows this code?"

Typing indicator. Stops. Starts again.

"I think the agent wrote most of that in March. Dana approved the PR." Dana, on holiday, by phone: "I reviewed it, I didn't memorize it. It was 1,900 lines."

Congratulations: you've discovered the new bus factor. The old one, where one person holds the knowledge and then leaves, at least had a person in it. This version skipped that step. The code went from a prompt to production, and the human who "owns" it in git history was the reviewer of record, under time pressure, eleven PRs deep that week.

Unowned code was always the risk. AI industrialized it.

Two research threads meet here. Neither is about AI, which is exactly why they bite.

First, the bus factor itself is usually already bad: Avelino et al. estimated truck factors for 133 popular GitHub systems and found 34% have a truck factor of one, meaning a single departure breaks the system, and roughly 65% sit at two or below. That's the baseline before anyone plugged in an agent.

Second, ownership predicts failures. In Bird et al.'s Windows study, components with more low-expertise contributors had more pre- and post-release failures, while a strong top owner meant fewer. The study predates coding agents, so the extrapolation to AI is ours; take it as an argument rather than a measurement. But an agent is functionally a low-expertise contributor with infinite stamina. It has no memory of your system's history and no accountability for its future.

Now add what AI-heavy codebases measurably look like. GitClear's 623M-change analysis found code-block duplication up 81% and refactoring line-moves down 70%. That is code accumulating without stewardship, which is what unowned code does. And developers themselves aren't claiming mastery of the output: in the 2024 Stack Overflow survey, 44.8% of professional developers rated AI tools bad or very poor on complex tasks, and only 43% trusted the accuracy of the output. The code merges anyway. Volume without a versed human is how you get six solo acts and a repo - except now some of the soloists aren't people.

To be fair to the fork: shipping agent-written code with light human depth can be a deliberate trade. A prototype, a migration script, a well-tested leaf module. The problem isn't that unowned AI code exists. It's not knowing which areas are in that state while your vibe-coded surface area quietly grows.

Do this first - free, this month

1. Make agent work attributable. Agent commits under bot accounts or with Co-Authored-By trailers cost nothing and turn "how much of this area is AI-written?" from a shrug into a git query. You can't retrofit attribution onto last quarter, so start now.
2. Map real ownership from evidence. git shortlog -sn -- <area> per directory, plus who actually reviews there. The org chart's opinion is not data. Ownership models only work when they match the history.
3. Overlay the two maps. Areas high on AI-assisted change and low on human authorship and review depth are your unowned zones. Rank them by blast radius: payment paths before README generators.
4. Give every area a named human owner. CODEOWNERS with an actual person rather than a team alias, and no area whose only "owner" is the bot that wrote it. For the worst zones, budget a real walkthrough: the owner reads the code, adds tests, writes the missing docs. That's how you buy the bus factor down.
5. Change the review contract for agent PRs. Small, explainable changes, and an approver who can answer "what does this do at 2am?" That's the core of agent best practices, and it's what keeps the rework rate from paying for the speed twice.

How you'd actually see it in Busfactor

The manual overlay above is the product's home turf. Busfactor's knowledge map computes review-weighted ownership per area. Reading code counts, not just writing it, so a reviewer who genuinely engages shows up as partial coverage and a rubber stamp doesn't inflate anyone's holdings. The AI view marks where AI-assisted work concentrates from deterministic attribution (trailers and bot accounts: a measured floor, never a guess), and the codebase map shows which of those areas are load-bearing.

The honest limit, stated plainly: no tool can see understanding - not from git, not from anywhere. What's measurable is structure: who wrote, who reviewed, how recently, and where the AI share is high. An area that no human wrote or meaningfully reviewed has no plausible owner, and that structural fact is what gets flagged. It's a statement about the system, never a verdict on Dana.

The door

The agents aren't the problem. Unowned code is, and it predates them by decades. What's new is the production rate. So: attribution trailers this week, the two-map overlay this month, a named human owner for every area that matters. Then run the drill for real: pick your most AI-heavy area and ask, out loud, who could debug it at 2am. If the answer is a typing indicator that stops and starts, you've found the work while it's still a planning item instead of an incident retro.