When Your Best Engineer Leaves, What Does Your AI Agent Forget?

When a senior engineer resigns, your AI coding agent does not forget anything. That is the problem. It never knew what she knew. The deprecated internal HTTP client she blocked in review for two years, the retry pattern banned after a rate-limit incident, the reason the billing service reads from a replica and never the primary: none of that was in the repository. It lived in review comments, Slack threads, and her memory. The agent keeps generating plausible code at the same rate it always did. The difference is that the person who knew which suggestions to reject is gone.

That is what bus factor means now. It is not "who can maintain this service." It is "who can judge a change to it." And when generation is cheap and verification is expensive, losing a verifier costs far more than losing a producer.

This article is a practical checklist for converting a departing engineer's judgment into context that both humans and agents can retrieve at review and merge time, plus the two metrics that tell you whether it worked.

The Exit Interview That Should Have Been a Data Migration

Consider a composite scenario that captures a common handover failure. A staff engineer at a payments company gives notice. Her handover looks exemplary by conventional standards: a detailed Confluence document, recorded walkthroughs, and pairing with the engineer taking over her services.

After her last day, several pull requests reintroduce the same pattern. Each one wraps an outbound call to a partner API in a client-side retry loop with exponential backoff and no shared budget. The changes were AI-assisted, passed CI, and were reviewed by engineers who had joined more recently.

She had rejected that pattern repeatedly in review after it contributed to a cascading rate-limit incident. The guardrail that came out of the incident was never written down as a rule. It existed as a point she made in review comments, in slightly different words each time.

Her handover document did not contain it because reflexive review judgment is easy to overlook during documentation. The agents did not degrade. The review bar did. Bus factor risk, onboarding drag, and AI context gaps are the same operating problem, measured from three different angles.

Bus Factor Was Never About Headcount

Traditional bus factor math counts contributors per service. Two committers, you are fine. One committer, you have a risk item on a slide. That model was built for a world where writing the change was the expensive part.

Google's 2025 DORA report describes near-universal AI adoption alongside continued instability in software delivery: more change flowing through the same review and deploy systems, without proportional gains in throughput and stability together ^[1]. The reading that matters for staffing decisions is that AI amplifies whatever your existing system already does. If your review capacity was thin and concentrated in three senior people, AI does not fix that. It makes the concentration matter more, because the volume arriving at the review step goes up while the number of people who can evaluate it stays flat.

Open source maintainers hit this wall first. The curl project publicly documented a rising flow of fabricated, plausible-looking vulnerability reports and now requires reporters to disclose AI usage on submissions ^[3]. The scarce resource was never code. It was trusted review attention plus the context needed to judge a change.

The adoption data points in the same direction. DORA reports that AI use has become nearly universal among its respondents, while Stack Overflow's developer survey shows that broad adoption still coexists with substantial distrust of AI output ^[1][2]. That combination increases the value of review context: teams are generating with AI even when reviewers know its output cannot be accepted on confidence alone.

Cross-repo ownership makes the concentration worse. A CODEOWNERS file assigns reviewers per path inside one repository ^[4]. It cannot encode the implicit contract between two services: that the ledger service tolerates duplicate event IDs because the ingest service replays on failure, or that a field is nullable in the schema but never nullable in practice for accounts created after a specific migration. When the person holding that contract in their head leaves, no file changes and no alert fires.

The Four Layers of Context Turnover Destroys

Not all lost knowledge decays at the same rate or costs the same to rebuild. Sorting it into layers tells you where to spend the two weeks you actually have.

An agent reading the repository can infer part of layer one and part of layer three. It can see that advisory locks are used and that a directory has a code owner. It cannot infer layer two, because a constraint is defined by the absence of something. Nothing in the codebase says "we do not do X here." The code just quietly does not do X, and a fresh generation has no reason to preserve that silence.

That is why the constraint layer is the expensive one. It is the layer with no artifact, no owner, and no expiry date, and it is the layer that maps directly to incidents.

What an AI Agent Actually Forgets (and What It Never Knew)

Agents read the repository, not the reasoning behind it. A deprecated internal client library still compiles, still has usage examples in three older services, and will still get suggested, because from the model's point of view it is a well-attested pattern in this codebase.

Context windows are not memory. Session context evaporates when the session ends. Repository instruction files (GitHub Copilot's .github/copilot-instructions.md, AGENTS.md, CLAUDE.md) are a real improvement and worth maintaining ^[6], but they are hand-edited prose in a small number of files. They can drift as systems change, they have no per-rule owner, and teams may forget to review them when the thing they describe changes.

Here is the practical difference in a review comment. Without organizational context:

SlopBuster finding (generic):
  src/partners/settlement_client.py:88
  Consider making the retry count configurable.
  Severity: low

With organizational context attached:

SlopBuster finding (context-aware):
  src/partners/settlement_client.py:88
  Client-side retry loop on a partner API call.
  Violates constraint CON-114: "No unbudgeted client-side retries
  to partner endpoints."
    Scope:    services/partners/*
    Owner:    payments-platform
    Origin:   INC-041 (settlement outage, 4h, rate-limit cascade)
    Status:   active, reaffirmed 2025-11-02
  Required:   route through partners.budgeted_call() or request
              an exception via Guardian with a named approver.
  Severity: high

The second comment is not a smarter model. It is the same review step with a retrievable rule behind it. A new hire reading it learns the guardrail and its origin in fifteen seconds. An auditor reading the merge record sees which rule applied, who owned it, and what happened.

The hardest gap is cross-repo intent, because the answer is not in the diff. A change to the ingest service can be locally correct and still break an assumption the ledger team made two years ago. No single repository contains the answer, which is why per-repo instruction files cannot close this gap on their own.

Why Your Wiki Fails the Retrieval Test

Wikis, ADRs, and Notion pages are optimized for the person writing them. They are prose, they are written once, and they are read when someone already suspects there is something to look up. Merge time is precisely when nobody suspects that.

Prose is also ambiguous to a machine. "Prefer the budgeted client for partner calls" and "never call partner endpoints directly" produce identical wiki formatting and completely different enforcement. There is no field for status, scope, owner, severity, or expiry. So a rule from two years ago that has since been superseded sits next to a rule from last month with equal apparent authority.

Typed memory changes the economics. When a constraint is a record with a subject, a scope expressed as file or service patterns, a status, an owner, a severity, and links to the incident that produced it, three things become possible: a reviewer can query it, an agent can retrieve it during review, and a gate can evaluate it deterministically. This is what Genie's typed institutional memory is for, and it sits alongside your existing ADRs and Confluence rather than asking you to migrate a decade of documentation. You promote the twenty rules that actually block bad merges. The rest stays prose.

A 30-Day Departure-Proofing Checklist

Do this before anyone gives notice. The version you run during a notice period is triage, and triage misses the constraint layer because the departing engineer cannot recall rules they never consciously articulated.

1. Find the concentration. List every repository where one contributor authored or reviewed more than 60% of merged changes in the last 90 days. OrgWatch surfaces this alongside human versus agent activity mix, so you can see which single-contributor repos are also absorbing high agent-authored volume. Those are your top risks.

2. Harvest from review history, not interviews. Pull the last 200 review comments from each concentrated reviewer. Cluster them by recurring rejection. In practice, five to eight patterns account for most of the volume, and those patterns are your undocumented constraints.

3. Type the top 20 constraints. For each one, record scope, severity, owner, originating incident or decision, and status. Twenty is not arbitrary. It is roughly what a team can maintain honestly. Fifty becomes stale, and stale rules destroy trust in the gate.

4. Assign a named owner per rule. Not a team alias for the ones that matter most. A rule with no owner cannot be reaffirmed or retired, and unretired rules are how gates become noise people route around.

5. Wire the highest-risk rules into merge gates. Start with three to five. Each gate needs an exception path with a named approver and a recorded rationale, because a gate with no exception path gets disabled the first time it blocks a legitimate hotfix.

Guardian merge gates are where step five lands: a constraint becomes an evaluated condition on the pull request, with a clear exception path and a recorded rationale. Engineering leaders can then see when a rule was overridden, why it happened, and who made the decision.

Metrics That Prove the Memory Survived

Documentation coverage percentages, ADR counts, and wiki page totals predict nothing about merge safety. Track outcomes at the point where a bad change would have shipped.

The primary metric is time-to-first-safe-merge for new hires: calendar days from start date to the first merged change that passed all gates without a senior stepping in to rescue it. It is a single number that reflects onboarding quality, documentation retrievability, and gate clarity at once. Teams that capture constraints properly tend to see this number fall, because a new hire does not need to know the original incident. The gate tells them.

The last row is the leading indicator. If review findings never cite an organizational rule, your typed memory exists but is not wired into the review path, and you will learn that the hard way after the next departure. Context-aware SlopBuster pull request review is where that citation rate becomes visible, because each finding either points at a rule or does not.

One useful side effect: gate decisions carrying policy, approver, rationale, and AI provenance are the same records auditors ask for. Evidence generated at merge time scales with change volume, which is exactly what manual audit preparation does not.

FAQ

What is bus factor in AI-assisted engineering?

It is the number of people who can competently judge a change to a system, not the number who can write one. Generation capacity is now abundant across most teams ^[2]. Judgment is the constrained resource, so bus factor should be counted in verifiers.

Can AI coding agents replace a departing senior engineer?

They can absorb some of the production work. They cannot inherit the constraints that engineer enforced, because those constraints usually were never written down. Agents retrieve what exists. If a rule exists only in someone's habits, it leaves when they do.

How do you capture context before someone leaves?

Mine review history rather than running interviews. Recurring rejections in the last 200 review comments reveal enforced rules more reliably than asking someone to list them, because reflexive knowledge is hard to recall on demand.

What is context rot?

The gradual divergence between what your documentation says and what your systems actually require. Instruction files and wikis drift fastest because they have no per-item owner, status, or expiry, so nobody knows which lines are still true.

How does typed memory differ from CLAUDE.md or Copilot instructions?

Instruction files are hand-maintained prose scoped to a repository, and they are read as a prompt prefix rather than queried as records ^[6]. Typed memory stores each policy, decision, constraint, or ownership fact as a separate record with scope, owner, severity, status, and links to its origin. That structure is what lets a review tool cite a specific rule and a merge gate evaluate it. Keep your instruction files. Promote the rules that must block merges into records with owners.

Does this only matter for regulated industries?

No. Regulated teams feel it first because they need the audit trail anyway, and SSDF-style documentation expectations push them toward recorded approvals ^[5]. Any team with concentrated review capacity and high agent-authored volume has the same exposure without the paperwork forcing them to notice.

Your Next 30 Minutes

Open your two highest-traffic repositories and compute reviewer concentration over the last 90 days. If one person accounts for more than 60% of approvals in a repository that also carries significant agent-authored volume, you have found the seat where a resignation becomes an incident.

Then pull that person's last 50 review comments and read them looking for one thing only: rules they enforce that appear nowhere in the repository. Write down the top five, with scope and an owner. That list is the highest-value artifact your engineering organization can produce this quarter, and it takes an afternoon.

The metric to start tracking this week is time-to-first-safe-merge for your last three hires. If that number has been climbing since your most recent senior departure, the code did not get worse. The verification layer did, and the agent will keep producing plausible changes at full speed until you give the review step something to check them against.

References

[1] Google Cloud / DORA, "2025 State of AI-assisted Software Development Report," 2025. https://dora.dev/research/2025/dora-report/

[2] Stack Overflow, "2025 Developer Survey: AI," 2025. https://survey.stackoverflow.co/2025/ai

[3] Daniel Stenberg, "Death by a thousand slops," curl blog, 2025. https://daniel.haxx.se/blog/2025/05/14/death-by-a-thousand-slops/

[4] GitHub, "About code owners," GitHub Docs, 2025. https://docs.github.com/en/repositories/managing-your-repositories-settings-and-features/customizing-your-repository/about-code-owners

[5] NIST, "SP 800-218: Secure Software Development Framework (SSDF) Version 1.1," 2022 (still the reference SSDF baseline for change review and approval documentation). https://csrc.nist.gov/pubs/sp/800/218/final

[6] GitHub, "Adding repository custom instructions for GitHub Copilot," GitHub Docs, 2025. https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions