AI Makes Your Best Engineers 10× Faster. It Also Makes the Bus Factor Worse.

The engineering manager looks at the sprint board. The senior full-stack engineer closed 22 tickets this sprint — the other five engineers combined closed 18. The AI-assisted output is remarkable. Everyone is celebrating the velocity numbers. But the manager also notices something quieter: nobody else on the team can touch the services this engineer is building. If they were to leave — or get hit by a bus — the team would spend six months just understanding what was built.

This is the bus factor problem in the age of AI coding. It is not new. But AI made it dramatically worse, faster, and harder to see coming.

How AI changes individual productivity

A developer with a well-configured AI setup — Cursor with project-level rules, Claude Code with a thoughtful CLAUDE.md, semantic MCP context from the codebase — produces dramatically more than a developer without one. This is the point. Teams measure it in velocity. Managers celebrate it in sprint reviews. The senior engineer closes 22 tickets not because they are working longer hours, but because their AI setup amplifies everything they already know about the system. They ask the right questions. They get accurate, convention-following answers. They ship.

That amplification is real and worth preserving. The problem is not that the engineer is too productive. The problem is where the productivity actually comes from.

The hidden concentration problem

The productivity comes from context. Specifically: the engineer's accumulated understanding of the system, their local setup, their session knowledge. The AI amplifies what they know. It does not distribute it.

When that senior engineer sits down with Cursor or Claude Code, they are drawing on eight months of context: which services own which behaviors, why the NotificationService never calls the BillingService directly, what the retry conventions are in the payment flow, which database tables are safe to join and which have footguns. Their AI tool gets great answers because the engineer asking the questions already understands the system. The AI is an amplifier, not a substitute for institutional knowledge.

When that engineer leaves — for a new job, for vacation, for parental leave — the amplifier goes with them. The rest of the team sits down with the same AI tool and gets worse answers, because they are asking worse questions. The context was never shared. It lived in one person's head and one person's local setup.

What a high-productivity AI engineer actually carries

The bus factor problem used to be about code ownership. If only one person understood a service, and they left, the team had a problem. AI changes what "carries" means. A high-productivity AI engineer in 2026 does not just carry code ownership. They carry:

Architectural decisions made silently during implementation. When an AI-assisted engineer builds a new service, they make dozens of small architectural choices: how to name things, how to structure the data flow, which existing patterns to follow, which to intentionally deviate from. These decisions rarely end up in tickets or PR descriptions. They are embedded in the code, invisible to anyone who wasn't part of the session.

Conventions introduced without announcement. "I started structuring service handlers this way because it makes error propagation cleaner" — said to nobody, because the engineer just started doing it. Three services later, it's a pattern. But it lives only in the output, not in any document anyone can query.

Context embedded in their AI setup that nobody else has. The CLAUDE.md with the project-specific rules. The local Cursor rules file. The session history that knows what was tried and rejected. When the engineer leaves, these disappear unless someone explicitly copies and maintains them — which almost never happens.

Cross-service knowledge that only becomes visible in their output. The engineer knows that the ChargeHandler in PaymentService calls the FraudCheckService synchronously, that FraudCheckService has a 500ms p99 latency on large accounts, and that this means ChargeHandler needs a fallback path. This knowledge surfaces in how they write code. It lives nowhere else.

Code review as a signal, not a fix

The standard response to bus factor is "we'll just do more code review." When AI writes most of the code, that response stops working.

Code review catches:
  - Syntax errors and style violations
  - Obvious logic bugs in the diff
  - Missing tests for the changed lines
  - Type errors the compiler missed

Code review misses when AI writes the code:
  - Architectural decisions embedded silently in naming choices
  - New conventions introduced without announcement
  - Cross-service assumptions that only appear at runtime
  - Duplicate implementations of patterns that already exist elsewhere
  - Behavior changes three services downstream

Code review catches the surface. When AI generates code that looks correct — compiles, passes tests, follows style — reviewers approve PRs they do not fully understand. This is not a failure of the reviewers. It is a structural feature of AI-generated code: it looks right at the diff level even when the architectural understanding behind it is opaque.

The real risk is not in individual PRs. It is in the architectural understanding that accumulates silently over dozens of them. After 40 PRs from the same engineer, the codebase reflects a coherent architectural vision — but that vision lives only in the engineer's head and their AI session history. Code review cannot reconstruct it retroactively.

The bus factor math with AI

Here is the math that should concern engineering managers.

Without AI (typical senior engineer):
  Deep knowledge of: 2-3 services
  PRs per sprint: 8-12
  Reviewers who fully understand: 2-3

With AI (same engineer, 3 months later):
  Deep knowledge of: 6-8 services (they built them faster)
  PRs per sprint: 22-28
  Reviewers who fully understand: still 2-3

Net result: bus factor didn't stay the same.
It got worse. Faster.

Before AI, one engineer might own deep knowledge of two or three services. Their productivity was naturally limited. The volume of their output meant the team had some chance of keeping up in review — and the slower pace meant knowledge had time to diffuse informally, through pair programming, through architecture discussions, through incidents.

With AI, the same engineer produces work across six or eight services in the same period, with fewer people reviewing deeply — because the review volume is higher than the team can meaningfully absorb. The bus factor does not stay the same. It gets worse, faster.

And the engineer does not notice, because from their perspective the work is going well. The code is shipping. The tickets are closing. The sprint board looks great.

What teams actually need

The wrong answers here are "use less AI" and "do more code review." Less AI trades away the velocity gains without solving the underlying problem. More code review cannot reconstruct architectural intent from a diff.

The right answer is making the context that lives in one engineer's AI setup accessible to the whole team. That means the conventions, the architectural patterns, the cross-service relationships, the "never do X because Y" rules — these need to be team property, not personal property.

What the senior engineer's AI session knows:
  - CLAUDE.md with local conventions and forbidden patterns
  - Full session history: rejected approaches, chosen tradeoffs
  - Cross-service mental map built over 8 months
  - Architectural decisions made in Slack, never in tickets
  - The reason BillingService never calls UserService directly

What the rest of the team can access when they leave:
  - The code
  - A PR description that says "refactored billing flow"

The gap illustrated above is exactly where bus factor accumulates. The senior engineer's AI setup knows the system. The rest of the team's AI sessions start cold. When someone else opens Cursor to work on the BillingService, they have no access to the architectural rationale that shaped it. They get generic answers. They make changes that seem reasonable locally but conflict with decisions the original engineer made four sprints ago and never documented.

The team-wide index as the fix

What changes this is a shared, always-current semantic index of the codebase that reflects the conventions, patterns, and cross-service relationships as they actually exist in the code — not as they were documented once in a Confluence page that's now 18 months stale. When a new engineer opens Claude Code or Cursor and asks about the BillingService, they should get answers that reflect how the system actually behaves, not generic advice based on a partial view of the diff they're looking at.

This is distinct from documentation. Documentation captures what engineers decide to write down. A semantic codebase index captures what the code actually does — including the conventions that were never announced, the patterns introduced silently by the highest-velocity engineer on the team.

Kognita and the bus factor problem

Kognita's managed codebase index means that the architectural patterns, the cross-service relationships, and the behavioral conventions that a senior engineer discovers and embeds in their personal AI setup become accessible to the whole team. The index is maintained automatically — when the senior engineer ships changes that introduce a new convention, the index reflects it. When they go on vacation, that knowledge does not disappear with them.

This matters most in two moments: when a team member needs to work in a service they've never touched, and when a high-productivity engineer leaves. In both cases, the alternative without a shared index is archaeology — reading code, running the system, asking the engineer who built it. With a shared index, it is a query: "what does the ChargeHandler call downstream, and what are the fallback assumptions?"

The Jira MCP integration matters here too. Architectural decisions that were made in the context of specific Jira tickets get connected to the codebase changes they produced. The intent behind the implementation becomes queryable, not just the implementation itself.

Final take

The bus factor problem is not new. AI made it worse by concentrating productivity along with knowledge. When one engineer's AI-amplified output spans half the codebase and nobody else can fully review it, the team has built a single point of failure at scale — and they called it velocity.

The solution is not slowing down the fast engineers. That wastes the real gains AI provides. The solution is making their system knowledge team property rather than personal property. The conventions they discovered, the patterns they introduced, the architectural rationale they embedded in 40 PRs — all of it should be accessible to the next engineer who opens a session and asks about that part of the system.

Bus factor in the AI era is not a people problem. It is an infrastructure problem. The teams that solve it will not do it by writing more documentation. They will do it by indexing what the code already knows.