Article · research january to february 2026 · published 2026-08-03 · v1 · 3 min read
Bus factor zero
The old worst case was the one person who understood it leaving, and the new one is nobody having understood it
Why the classic measure of project resilience stops working when a machine writes the code, and what has to be written down instead. The canonical treatment of bus factor zero.
Software teams have measured a certain kind of fragility for decades with a grim little metric. The bus factor is the number of people who would have to be hit by a bus before the project could not continue, and a bus factor of one is the classic emergency: a single person holds the mental model, and everything from vacations to resignations becomes a risk to the system rather than to the person. Every remedy the industry built for this assumes the same thing, that the understanding exists and needs distributing. Pair programming distributes it. Code review distributes it. Documentation preserves it. Onboarding transfers it.
None of those work on a system nobody ever understood. That is the case a fluent generator makes ordinary, and it is one worse than the classic emergency rather than a variation of it. A model produces a subsystem faster than any person can read it, a solo developer or a small team accepts it because it passes, and the code enters production carrying no mental model anywhere. There is nothing to distribute. Six weeks later a bug appears in it and the author is in the position of a stranger reading someone else’s work, except that the someone else cannot be asked, was never a someone, and left no reasoning behind because reasoning was not what it was producing.
The distinction that matters is between knowledge lost and knowledge never formed. Losing it is recoverable in principle, since archaeology on a repository is slow and miserable but it works, and the person who wrote the strange thing usually wrote it for a reason that can be reconstructed from what else was true at the time. Knowledge never formed leaves nothing to excavate. The code has no intent behind it, only the statistical residue of a million other codebases, so the question every maintainer eventually asks, why is it like this, has no answer at all rather than a hidden one. Systems in that state cannot be safely refactored, because you cannot tell load-bearing from accidental, and everything therefore has to be treated as load-bearing, which is another way of saying the system is frozen.
Nothing about this is an argument for generating less. It is an argument that comprehension has to be produced deliberately now, since it is no longer a free byproduct of typing. The reasoning has to be externalized while it still exists, in decision records that say why this database and not that one, why this threshold and not a rounder number, what was rejected and what would have to become true to revisit it. The generated explanation is worth having and is not the same artifact, because a model asked to explain code will tell you what it does with total fluency and cannot tell you what anyone intended. And the practical gate is the one sentence a person has to be able to say without looking, which is why this is safe.
Bus factor zero is not a caution about ambition. It is a reminder that a system is not finished when it runs, it is finished when somebody understands it, and that has always been the standard we were quietly meeting by accident and can now choose to meet on purpose.
Evidence and lineage
Research trail
Follow the sources, inspect how the claims are graded, or propose a correction at the exact record it concerns.
Sources 3
-
MNSTRY engineering research record (2026). AI-augmented solo spiral development methodology (2026), on the bus factor dropping to zero and on knowledge graphing as the mitigation
The origin of the brick's argument. Names the trap directly, that using a model to write code the developer does not understand takes a bus factor of one down to zero, and prescribes decision records as the externalization.
Comment on this source -
MNSTRY engineering research record (2026). Synthesis on AI-assisted architecture patterns and gaps (2026), on preserving why rather than what
The maintainer's half of the problem: without recorded rationale, nothing distinguishes a load-bearing decision from an accidental one, so a system in that state cannot be safely refactored.
Comment on this source -
Michael Nygard (2011). Documenting Architecture Decisions (the architecture decision record format)
The standard artifact the brick asks for. An ADR records the decision, its context, the alternatives, and the consequences, which is the reasoning that generated code does not leave behind.
Comment on this source
Claims and confidence 3
- verified
The bus factor is a standard measure of project resilience, and a bus factor of one describes a project whose mental model is held by a single person.
Long-established usage in software engineering practice and its literature.
Respond to this claim - directional
Generation outpaces the rate at which a human can read and internalize code, so a system can reach production with no person holding a mental model of it.
Practitioner observation in our engineering research record, and a straightforward consequence of the throughput difference; not a measured comprehension rate.
Respond to this claim - directional
A system whose rationale was never recorded cannot be safely refactored, because load-bearing decisions are indistinguishable from accidental ones.
The research record's gap analysis and ordinary maintenance experience; a practice claim about what recorded rationale buys, not a measured outcome.
Respond to this claim
Read next
You have walked The craft end to end: the context nobody could hold, the inversion that made checking the job, the illusion that hides the error, the drift that survives review, and the absence left when none of it is done. The half of the work that got scarce was always the part that was the craft.
Practice Open the last thing a machine wrote for you that you shipped. Without opening anything else, write down why it is safe: what it assumes about the world, what happens on the empty and hostile cases, and which decision in it is load-bearing. Then check, and notice which half of that exercise was the actual job.