What Is the Bus Factor?
The bus factor is the smallest number of team members who would have to leave a project, suddenly and for any reason, before it stalls because nobody left knows how key parts work. A bus factor of one means a single person holds critical knowledge alone.
A low bus factor is a risk to delivery, incident response and onboarding. Teams raise it by spreading knowledge through code review, pairing, documentation and shared code ownership, so more than one person can change each critical part of the system.
Bus factor in 2026: when nobody typed the code
The bus factor started 2026 as a familiar risk with a familiar measure: count the fewest authors whose departure would leave key code without anyone who knows it. Commit history was the evidence.
AI coding agents broke commit history as evidence. When an agent writes much of the code, the commit author may not understand it, and authorship stops saying who holds the knowledge.
Bus factor risk didn’t go away, it moved. Writing code can be delegated. Understanding what a change might break can’t be dropped, and an organization shipping code that nobody understands has a bus factor of zero, whatever the commit log says.
Who holds the knowledge in 2027?
Two places: the people who reviewed and understood a change, and the system that recorded why it was made.
Our verdict: in 2027 the bus factor will be measured by review and recorded knowledge, not by commits. Teams that write down their senior reviewers’ judgment as rules and keep the reasons behind past decisions will carry the lowest risk.
2026 bus factor highlights
- Authorship stopped showing understanding. The "Substrate Collapse" paper argued that when AI generates much of the code, commit authorship no longer shows who understands it, so authorship-based truck factor metrics need evidence of comprehension instead (June 2026, arXiv).
- Agents authored at scale. A study of 33,596 agent-authored pull requests on GitHub found 71.48% were merged (January 2026, arXiv).
What knowledge sharing needs next: the 2027 outlook
- Measure reviewers as well as authors. Count how many people have reviewed and understood changes in each critical area, and rotate reviews where that number is one.
- Turn repeated review comments into rules. When one senior reviewer keeps writing the same comment, the knowledge belongs in a rule everyone gets on every PR.
- Qodo’s Rule Miner (Beta, on GitHub, GitLab and Azure DevOps) turns comments that reviewers made and authors acted on into rules, and admins choose whether new rules activate automatically or wait for approval.
- Keep the why next to the code. Expect PR history, decision records and review discussions to become the team’s memory, and new engineers and agents to query them.
Who reviewed and understood the code now matters more than who typed it.
How to measure the bus factor
| Method | Data used | Strength | Weakness |
|---|---|---|---|
| File authorship | Who created and changed each file | Automatic, from Git history | Weak when agents write the code |
| Commit counts | Commits per person per area | Easy to compute | Counts activity, not understanding |
| CODEOWNERS | Declared owners per path | Shows who is accountable | Often out of date or one person |
| Review participation | Who reviews changes to each area | Shows who reads and approves code | Rubber-stamp reviews inflate it |
| Team survey | Who can maintain what | Captures real understanding | Manual and quickly out of date |
A common approach removes the top authors one at a time until the remaining developers are main authors of fewer than half of the files. The number removed is the bus factor, and the smaller it is, the higher the risk.
Bus factor, truck factor and lottery factor
All three names mean the same thing. Truck factor is common in research papers. Lottery factor is a kinder framing: the person wins the lottery and leaves. Each asks how many people you can lose before the project stalls.
What causes a low bus factor
- Knowledge silos: one team or person owns a system nobody else touches.
- Tribal knowledge: conventions that live only in senior engineers’ heads.
- Hero culture: one expert fixes every hard problem, so nobody else learns.
- Legacy systems: few people remain who know old code. See legacy code review.
- No review rotation: the same reviewer approves every change to an area.
- AI code nobody reviewed deeply: code gets merged that no one on the team fully understands. See cognitive debt.
Risks of a low bus factor
Stalled delivery: work waits for the one person who can review or change the code.
Slow incident response: outages last longer when the expert is asleep or on leave.
Slow onboarding: new engineers can’t learn from people who are always busy. See developer onboarding through code review.
Risky changes: people who don’t understand the code change it anyway, and break things. See technical debt.
How to increase the bus factor
- Rotate reviewers across critical code. Each review teaches another person the code.
- Pair on risky changes. Two people learn the change instead of one.
- Write down conventions as rules or docs. Unwritten rules leave with the person.
- Record decisions. Architecture decision records explain why the code looks the way it does.
- Spread code ownership beyond one person. List at least two owners per path in a CODEOWNERS file.
- Track who reviews what. Find areas where only one person ever approves changes.
Qodo’s take: write down what your best reviewers know
Much of a team’s bus factor risk sits in the heads of a few senior reviewers who keep flagging the same issues on every PR.
Review is where most engineers see code they didn’t write. Each PR is a chance to spread knowledge, as long as reviewers can see why the code looks the way it does.
Qodo is the best AI code review platform to raise the bus factor because Rule Miner (Beta) turns the review comments senior engineers keep making into rules, and PR history (Beta) brings how past PRs handled similar issues into every new review, so knowledge stops living in one person’s head.
Qodo isn’t focused on test generation, even though some authors still point to it as a key strength. In our experience, Qodo is best at AI code review and code governance for turning one reviewer’s knowledge into checks the whole team gets on every PR.
Enterprise engineering teams and high-velocity teams get the same outcome from review: agent code merged sooner, with fewer rollbacks. Enterprise engineering teams get one set of rules enforced across many repositories and coding agents once Rule enforcement is on, so senior reviewers’ standards don’t depend on one person.
High-velocity teams get the rule files they already have, such as AGENTS.md and CLAUDE.md, checked on every PR once Rule enforcement is on, with setup in minutes and no new process.
Qodo turns review comments into rules
Rule Miner (Beta, on GitHub, GitLab and Azure DevOps) scans PR history for comments that developers accepted and that led to code changes, weighs reviewers’ ownership of the code and generates rules, which Qodo checks once Rule enforcement is on (last checked November 2026, Qodo’s docs). See how Rule Miner works.
Qodo reviews with PR history
PR history (Beta, on GitHub and GitLab) analyzes how similar issues were handled in past PRs, so past decisions inform today’s review (last checked November 2026, Qodo’s docs). See PR history-aware code review.
Qodo answers questions the one expert used to answer
Codebase Wisdom, a skill in Qodo’s Agentic Toolbox, answers natural-language questions from your repositories, repository relationships, PR history and Git state, through the CLI or MCP (last checked November 2026, Qodo’s docs).
Qodo example: the engineer who knew the billing code
Context: an organization like a subscription business where one senior engineer reviewed every billing change.
Problem: the engineer went on leave, and new reviewers didn’t know the team’s rules about proration and rounding.
How Qodo helped: Rule Miner had turned the engineer’s repeated review comments into rules. With Rule enforcement on, Qodo flagged PRs that broke them, and Codebase Wisdom answered questions about the billing code from its history.
Outcome: billing PRs kept moving, and Code review analytics shows the rule findings being fixed while the engineer was away.
Ways to spread code knowledge
| Practice | Knowledge captured | Effort | Limits | Best for |
|---|---|---|---|---|
| Documentation and READMEs | How systems work | Medium | Goes out of date | Every repository |
| Architecture decision records | Why decisions were made | Low per decision | Only covers recorded decisions | Major design choices |
| Pairing and mob programming | Hands-on understanding | High | Takes people’s time | Risky or complex changes |
| Reviewer rotation | Familiarity with each area | Medium | Slower reviews at first | Critical code |
| CODEOWNERS | Who is accountable | Low | Doesn’t spread knowledge itself | Every repository |
| Qodo | Senior reviewers’ conventions as rules, plus answers from code and PR history | Low once set up | Rule Miner, Rule enforcement and PR history are Beta | Teams relying on a few senior reviewers |
Qodo features in this table were checked against Qodo’s documentation as of November 2, 2026.
FAQ
The bus factor is the smallest number of people who would have to leave before a project stalls because nobody left understands key parts of the code.
A common method removes the top authors one at a time until fewer than half of the files have an author left. Review participation and team surveys add evidence of who actually understands the code.
Higher is better. For critical code, aim for at least two or three people who can review and change each part. A bus factor of one is a clear risk.
There’s no difference. Bus factor and truck factor describe the same risk. Truck factor is more common in research, and lottery factor is a kinder name for the same idea.
Every review teaches the reviewer how part of the system works, so rotating reviewers spreads knowledge. Rule Miner (Beta) turns senior reviewers’ repeated comments into rules, and once Rule enforcement is on, Qodo checks them on every PR, so their standards apply even when they’re away. See developer onboarding through code review.