What Is the Bus Factor of a Vibe-Coded Project?

What the bus factor actually measures

The bus factor is a blunt metric. It asks: how many team members could be removed before the project stops moving? The framing is deliberately stark. What the question actually measures is knowledge distribution: how much of the project's operational context lives in one person's head rather than in shared systems, documentation, and team understanding.

In software delivery, bus factor is almost always a knowledge problem rather than a headcount problem. Teams replace people. They cannot easily replace the mental context a departing engineer carried: which modules are fragile, which fixes were applied under pressure and never revisited, which architectural decisions were made in a late generation session and never written down.

Key person risk in software development has always existed. What vibe coding does is concentrate it faster.

Why AI-assisted development concentrates knowledge faster

When a developer drives an AI generation session, they hold the context: the prompts, the decisions made during the back-and-forth with the model, the edge cases they chose to handle and the ones they deferred. The output arrives quickly. Often faster than anyone else on the team can absorb.

Code review in a vibe-coded build requires explicit process controls to stay meaningful. Without them, reviews tend to be high-level rather than granular, because the volume of generated code outpaces what a second engineer can assess in a normal sprint cycle. Google's 2025 DORA report found that AI adoption was associated with a 51.3% increase in pull request size. Larger PRs are harder to review thoroughly. The reviewer sees more code and understands less of it. The knowledge gap compounds with every sprint.

The result is a predictable pattern. The engineer who drove the generation sessions becomes the one who fully understands what was built and why. Not because others were excluded, but because the generation context was never formally shared.

Consider a team with a primary backend engineer driving the AI sessions alongside frontend and DevOps colleagues. Two weeks before go-live, the backend engineer is unavailable. The frontend engineer can read the code. They cannot necessarily modify complex integration logic safely, because they were never part of the generation decisions that shaped it. The DevOps engineer can keep the infrastructure running. They cannot tell you whether a last-minute configuration change will interact with a module built the previous week.

That is a bus factor of 1. Not because the team is small, but because the knowledge is concentrated.

Traditional development with a single core developer carries the same risk. What changes with vibe coding is pace. Knowledge concentrates faster when one engineer drives large generation sessions. The gap between when it works and when anyone else can maintain it arrives earlier in the delivery cycle.

What the data from a real AI-assisted delivery shows

Across a 20-week AI-assisted B2B SaaS delivery our team tracked end to end, a clear concentration pattern emerged. The backend engineer, who drove the majority of the generation sessions, carried 64.4% of all project bugs, including every item marked Critical and Highest severity at go-live. The frontend engineer carried 33.7%, with no Critical or Highest severity items. The DevOps engineer carried zero bugs across ten infrastructure tasks.

The 64.4% backend figure shows where knowledge is concentrated. Individual fixes go through standard verification: QA validates each one against documented acceptance criteria before it reaches pre-production. That process works. What it cannot replace is architectural understanding. When an unexpected interaction surfaces in production: one that passed QA because it only appears under a specific production configuration, the engineer who drove the generation sessions is the one who knows which design decisions are relevant, which edge cases were explicitly handled during development, and where the codebase is most sensitive to change. That knowledge does not sit in the ticket descriptions or the test results. It sits in the generation history that only one person has.

The DevOps figure is worth noting separately. Infrastructure-as-code does not produce this concentration pattern because it does not carry the same ambiguous integration surfaces. A Terraform module either provisions correctly or it does not. Application code, particularly in areas with complex state management, requires contextual understanding that does not transfer through a read-through alone.

Veracode's 2025 GenAI Code Security Report found that AI models frequently produce correct authentication middleware whilst failing to wire it into subsequent components: the vulnerability lives in the integration, not in any individual file. That finding maps directly to what delivery data shows. The individual modules pass review. The seams between them require a different kind of attention.

The traceability gap that compounds the risk

There is a second layer to the concentration risk that is easy to miss until it matters.

In the delivery above, 68.3% of the 101 bugs raised had no explicit parent task link in the project management system. Some of these reflect genuine cross-module issues or edge cases that do not map cleanly to a single feature. In pre-production projects, formal resolution timestamps often sit in status transitions rather than dedicated fields. Neither of these is unusual.

What they mean together is this: if the engineer who held the generation context had left after go-live, the team inheriting the codebase would have needed to reconstruct the fix logic for those 69 unlinked issues from the tracker alone, without the mental model the original developer carried.

This is not a criticism of the workflow. It is an argument for supplementing it with structures that externalise what the generation session produced.

How AI tooling changes the equation

The tools that accelerate knowledge concentration can also distribute it. This is the part that most discussions of vibe coding risk miss entirely.

GitHub Copilot's pull request summaries generate a structured overview of every change: what was modified, which files are affected, and what a reviewer should focus on. When a second engineer reviews an AI-generated module, they are not starting from a wall of unfamiliar code. They are starting from a summary of the decisions made. That is not a complete knowledge transfer. It is a meaningful step towards one.

CodeRabbit, currently running across more than two million repositories and 13 million pull requests, goes further. Each PR receives a TL;DR summary alongside an architectural diagram showing how the change fits into the broader codebase. A second engineer reviewing with that context understands the module's role in the system, not just its internal logic. The knowledge that previously lived only in the author's head gets partially externalised with every review cycle.

Our approach at Go Wombat builds these tools into the delivery workflow from sprint one. AI-generated PR summaries reduce the review burden. AI-assisted code review surfaces integration issues earlier. Automated module documentation captures the decisions the generation session produced. None of this removes the need for a second engineer to read and understand the output. What it does is make that review feasible at the pace Vibe Coding operates.

The contrast is direct. Teams that adopt AI-assisted development for speed alone, without pairing it with governance tooling, accelerate the knowledge concentration problem. Teams that use both are the ones whose AI-assisted projects arrive at go-live with a bus factor above 1.

Five practices that reduce bus factor without slowing delivery

None of the following requires significant process overhead. All five require consistent application from sprint one.

1. Mandatory second-engineer review before any major AI-generated module is merged

Not a full line-by-line audit of every commit. A structured session where a second team member reads the AI-generated PR summary, walks through the architectural diagram, and asks the questions the original developer took for granted. Thirty minutes per module. The knowledge distribution happens here.

2. Named sign-off records for every Critical and Highest severity bug

A status label signals readiness. It does not replace a named reviewer, a regression test result, or a production environment confirmation. The record exists so that any engineer on the team can reconstruct what was checked and why.

3. Bug-to-task linking is enforced from day one

Requiring a parent task link on every bug costs seconds per issue. It pays back in full when context needs to be reconstructed under pressure. The 68.3% unlinked figure from our delivery was not the result of negligence. It was the result of a workflow that never required the link. Requiring it from the start changes the outcome.

4. Shared context documentation for AI-generated modules

The model's output is not self-documenting. A brief written record of what was generated, which decisions were made, and which edge cases were handled reduces the bus factor before it becomes a risk event. AI documentation tools make this faster than it sounds.

5. Post-production ownership defined before go-live

Error logging thresholds, alerting rules, and a first-week triage cadence should be assigned before deployment. Consider pairing this with a structured IT support and maintenance arrangement so that monitoring and incident response are in place from day one in production.

What leaders should ask before go-live?

The bus factor question is, at its core, a governance question. When AI writes the code, who actually understands it?

For a CTO or Head of Engineering assessing a vibe-coded build, three questions cover the essential ground. First, is there more than one engineer familiar with fixes for the most critical bugs? Second: has the QA lead confirmed that critical items have been verified against the production environment, not only closed in staging? Third: are AI-generated modules documented, and have a second engineer reviewed them using PR summaries and architectural context?

If the answer to any of these is uncertain, the delivery carries more risk than the status board shows.

The Google DORA 2025 report identified documentation hygiene and code review discipline as two of the seven engineering capabilities that cause AI to improve both throughput and delivery stability at the same time. The teams whose AI-assisted projects hold up in production are not only using AI to write code faster. They are using it to govern what they built.

That is the part that takes experience to get right. It is also the part where working with a team that has already governed this at a delivery scale makes the most difference. Get in touch with Go Wombat to discuss your AI-assisted delivery.