Bus factor as a leading indicator: 14 organisations, nine months

Bus factor is an old idea with a grim name: how many people can be hit by a bus before a system becomes unmaintainable. It is normally estimated from commit history, which measures who wrote code rather than who understands it. Those are different questions, and agentic coding has made them much more different.

Because we already measure comprehension per engineer per concept, we can compute the concentration directly. This paper asks the only question that matters about a warning system: does it fire early enough to do anything.

Defining the metric

For each module we count engineers who have demonstrated comprehension of the module's primary concepts within the last 90 days, at or above the demonstrated level on the four-step mastery scale. One qualifying engineer is a warning. Zero is an alert.

We ran commit-history bus factor alongside as a baseline. The two disagreed on 38% of modules, and the disagreement was strongly directional: comprehension-based bus factor was lower than commit-based bus factor far more often than the reverse. Several people had touched the code. Fewer understood it.

Lead time

Median lead time was 4.7 months, with a long left tail: 14% of warnings fired less than a month before an event, which is not enough time to transfer understanding of a non-trivial system. The right tail is more useful than it looks. A warning that fires a year early is not a false alarm, it is a year in which someone could have paired.

We ship the one-or-fewer threshold and 34% precision, which means two thirds of warnings are not followed by an event in the window. We think that framing is wrong. A module that only one person understands is a real problem whether or not that person happens to resign, so the false positives are mostly true findings about a different question.

Agent-authored modules concentrate faster

Controlling for module age, size and team size, modules where more than 60% of lines were agent-authored were 2.4 times more likely to reach the warning threshold than comparable hand-authored modules.

The mechanism is visible in the comprehension data from AWL-2026-06. Code that is generated, reviewed briefly and merged produces one engineer with partial comprehension rather than two with solid comprehension. Repeat that across a quarter and a module has a bus factor of one while the commit log shows four contributors.

What organisations did with the warning

We tracked responses to 442 warnings. The most common response was nothing (61%), which is worth reporting plainly. Of the interventions that did happen, deliberate pairing on the module was both the most common and the most effective: 78% of paired modules cleared the threshold within two months.

• No action: 61% of warnings. Median time to clear the threshold, never within the window.
• Documentation written: 14%. Cleared threshold in 9% of cases, since documents do not demonstrate comprehension.
• Deliberate pairing: 17%. Cleared threshold in 78% of cases, median 6 weeks.
• Rewrite or retire the module: 8%. Cleared by definition, at obvious cost.

The documentation result is the one worth sitting with. Writing a document about a module you are the only person who understands does not change the fact that you are the only person who understands it. It changes how bad you feel about it.

Limits

• 61 events across 14 organisations is a small event count for a precision claim.
• Departures are not random. An engineer who is the sole comprehender of three systems may be more likely to be retained, which biases sensitivity downward.
• The 90-day comprehension window is arbitrary and materially changes the warning rate.
• Response data is self-reported by engineering managers who knew we were watching.
• The 2.4x agent-authored effect is observational. Teams that lean on agents may differ in ways we did not control for.

Threshold sweep, the event coding scheme and the anonymised module-level series are published. Organisation identities and module names are not.

Related work

Knowledge concentration has been estimated from version-control history since Mockus and Herbsleb [1] introduced expertise browsing, and Avelino and colleagues [2] give the standard commit-based bus-factor formulation we use as a baseline. Our contribution is to substitute a demonstrated-comprehension measure for authorship, which matters because Bainbridge [3] predicts precisely the divergence we observe once generation is automated. Nassif and Robillard [4] document how author departure degrades maintainability, and Bird and colleagues [5] connect ownership structure to defect rates. Conway's observation [6] frames why the module boundary rather than the team boundary is the right unit. The comprehension measure is documented in AWL-2026-06 [7].

Artefacts

Everything below is published or available on request. A number nobody can reproduce is an advertisement, not a result.

References

1. Mockus, A., & Herbsleb, J. D. (2002). Expertise Browser: A Quantitative Approach to Identifying Expertise. ICSE.
2. Avelino, G., Passos, L., Hora, A., & Valente, M. T. (2016). A Novel Approach for Estimating Truck Factors. ICPC.
3. Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6).
4. Nassif, M., & Robillard, M. P. (2017). Revisiting Turnover-Induced Knowledge Loss in Software Projects. ICSME.
5. Bird, C., Nagappan, N., Murphy, B., Gall, H., & Devanbu, P. (2011). Don't Touch My Code: Examining the Effects of Ownership on Software Quality. FSE.
6. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4).
7. Bhardwaj, M. (2026). The comprehension gap: 200 engineers, 12 months, and what agentic coding did to recall. AI Work Lab Research, AWL-2026-06.