The truck factor on your team is almost certainly wrong. It has been since the first AI-generated PR merged without significant revision.
The truck factor — sometimes called the bus factor — is the smallest number of developers who could leave before the project loses critical knowledge. It's computed by mapping modules to their authors, identifying concentrated knowledge, and counting the minimum set of contributors who collectively cover everything. A truck factor of one means one person's departure puts the project in serious trouble. Healthy teams aim for two or three or higher across every critical subsystem.
In June 2026, researcher Brett Wheeler published a paper called "The Substrate Collapse" with a specific argument: AI code generation has not degraded this metric. It has invalidated it.
What the Truck Factor Was Actually Measuring
The truck factor works because authorship licenses an inference. The person who wrote a module understands it. Writing code — constructing it, debugging it, adapting it when requirements shifted mid-implementation — produces knowledge that reviewing code does not. You might catch obvious bugs in review. You probably can't explain, under time pressure, why a specific piece of logic exists, what assumptions it's making about the upstream state it receives, or what happens when an edge case hits at 2am that none of the tests covered.
Wheeler calls this "authorship depth." The degree-of-authorship metric, the degree-of-knowledge model, and the truck factor itself all depend on the claim that authoring a module is evidence of comprehending it at that depth. This was a reasonable inference when humans wrote all the code, because the process of constructing code forces transient comprehension even when the author doesn't retain it perfectly.
The degree-of-authorship metric computes a score per developer per module, weighted by recency and breadth of contribution. The degree-of-knowledge model extends this across the team to produce a distribution — who knows what, and how well. The truck factor is derived from that distribution.
All three are broken for the same reason.
The Severed Inference
When an AI agent generates a module and a human merges it, version control attributes authorship to the human. The commit record is indistinguishable from one where the human wrote the code.
But what actually happened during that "authorship" event was different. The developer reviewed the generated code at inspection depth: is this plausibly correct? Does it fit the interface? Are there obvious bugs? They may have run it locally, checked the tests, and iterated with the agent through one or two correction cycles.
That is not authorship depth. Inspection depth tells you whether code looks right. Authorship depth is what lets you fix it under conditions you didn't anticipate when you wrote it.
Wheeler's point is precise: the same authorship footprint in the commit history now accommodates full comprehension, shallow comprehension, or essentially none. You cannot tell which from the record. "The metric still returns a number, but the number measures a substrate that has come uncoupled from the quantity it was used to estimate."
The truck factor for your codebase computes a number. That number represents the count of developers who authored significant fractions of the code. It no longer represents the count of developers who could maintain it under pressure.
The Failure Mode This Creates
Teams running authorship-based knowledge metrics look fine on paper right up until an incident surfaces a gap.
The scenario: a production incident at 2am involves a module with a healthy degree-of-authorship score distributed across three developers. The on-call developer is one of the three listed authors. They pull up the code and discover that they reviewed it but didn't write it — an agent generated the majority of it eight months ago, they approved the PR after two rounds of steering the agent, and their memory of it is at inspection depth, not authorship depth.
Under pressure, with a time limit, there's a significant difference between "I wrote this and I can reason about what it's doing" and "I approved this and now I need to re-derive what it's doing from scratch." The second scenario still works — developers can re-read code they didn't write — but it takes longer, it's more error-prone under stress, and it fails in a specific way: the original design decisions and the assumptions behind them are not in anyone's head. They're nowhere except inside the model that generated the code, which is not on-call.
Wheeler predicts exactly this outcome in the paper: systems with healthy authorship-derived knowledge metrics but low actual comprehension will experience "unpredicted incident-resolution failures." The metrics said knowledge was distributed. The distribution wasn't measuring comprehension.
How Widespread the Exposure Is
The exposure is roughly proportional to how much of a codebase's history involves AI-generated code that received review-style rather than authorship-style engagement.
For teams that adopted agentic coding tools in 2024 and 2025, a significant and growing fraction of their codebase now carries authorship attributed to developers who engaged with it at inspection depth. The specific percentage depends on team workflow — some developers prompt heavily and review carefully, others approve more quickly — but the direction is consistent. More AI generation means more authorship records that no longer proxy for comprehension.
There's no way to detect this from version control alone. The commit timestamps look the same. The authorship percentages look healthy. The truck factor comes back at three, or four, and nobody flags it.
What Actually Proxies for Comprehension Now
Wheeler's paper is honest about the measurement gap it opens: it argues the field needs new "comprehension-grounded instruments" without specifying what those instruments are. The honest reading is that we don't have them yet, and the problem is genuinely open.
Some candidates are worth thinking about, even imperfect ones.
Time-in-file is a weaker proxy, but it points in a better direction. A developer who spent six hours debugging a module has interacted with it at a depth that the person who approved the PR in 45 minutes has not. Neither session produces commit record evidence, but the debugging session creates comprehension that review didn't. Tracking actual session time by file and module — not just commits from it — gives you a different signal than authorship alone.
Post-merge engagement is another partial proxy. Developers who return to a module after merge, who open it for follow-up debugging, who ask questions about it in standup, are demonstrating that they're building real working knowledge of it. This is harder to instrument than commit records, but it's closer to what you actually want to know.
Bug ownership patterns matter. When a bug in a module gets routed to whoever "owns" it based on authorship, watch who actually understands what to look at. The gap between the listed owner and the person who ends up debugging it is worth tracking.
None of these are perfect. The truck factor worked because authorship was simple to measure and closely tracked comprehension. We're in a period where the simple measure has broken and the better measures are harder and more expensive to collect. The paper's contribution is naming the class of metrics that have broken and being precise about why. Filling the gap is the work it leaves open.
What to Do With This
If you're a tech lead or engineering manager, the practical step is to stop reading your truck factor output at face value. Run it anyway, but treat it as a floor — the number of developers who have any engagement with each module — rather than a count of people who could actually maintain it under pressure.
For the most critical subsystems, the question worth asking is not "who authored this?" but "who wrote this without AI generation, or who has debugged it post-deployment, or who could explain this design to a new team member?" That conversation will produce a more accurate knowledge distribution than any metric that reads from the commit log.
The underlying shift is real. There was a period when authorship and comprehension were the same thing because humans were the only ones writing code. That period is ending, unevenly, across codebases at different rates depending on how aggressively teams adopted agentic tools.
The commit history now has two populations in it: code that developers understand because they wrote it, and code that developers reviewed but that was generated by something that isn't on any team, doesn't attend your standups, and is not available to debug its own output when production breaks.
The truck factor counts both the same way. It shouldn't.