Knowledge in the Repository, Keys in Your Hands: What If Your Developer Left Tomorrow?

I ended the previous article with a suggestion: swap the tool that runs your agent for another one for a day; however much keeps working is how much of your knowledge lives in the repository. This article takes the same experiment one step further. This time, let's swap the developer instead of the tool.

When a large company considers working with a small software firm, the first question on the table is always the same: “What happens if we can't reach this person tomorrow?” In procurement language it has two names: key person risk and vendor lock-in. The question is fair. If only one person knows a system, that person is the system's single point of failure.

The three classic answers to that question all fall short. Documentation is written into the contract, but it is either never written or frozen and out of date after its first version. A second developer splits the risk but doubles the cost. Source code escrow hands over the code, but not the knowledge needed to bring that code up: which environment is where, which job runs in which order, why a rule was put in place.

In a project built with AI, that picture changes. This article is about how it changes, and about what does not.

The knowledge is already in the repository

An AI agent starts every session without memory. It does not know what was discussed the day before, why a decision was made, or which command touches which environment. For it to know, all of that has to be written down in the repository, in the same place as the code. It cannot work with knowledge that is not written down.

That has a by-product: a project that works well with AI is a project that can be handed over. The knowledge the agent reads every morning is the same knowledge a new developer will read on their first day. In this site's repository, it sits in these layers:

• A rules file read in every session: the map of the repository, the commands and the rules that hold everywhere.
• Path-scoped rules: loaded only while that part of the tree is being edited.
• Reasoning: why a rule was put in place, and which incident or measurement it came from.
• Skills: task-shaped workflows, from publishing an article to taking a backup, from promoting a deployment to reading the live logs.
• The infrastructure itself: alert policies defined as code, and the one-time setup guides.
• Commit messages: they say why something changed, not what.

The difference from classic documentation is that it gets noticed when it goes stale. The repository has a rule: every change that alters what the code does rewrites, in the same change, every sentence that describes the old behaviour. The rule does not enforce itself, but when it is broken it cannot stay hidden: an agent that reads an outdated sentence does the wrong thing because of it, and the outdated sentence soon turns into a visible mistake. In a PDF nobody opens, the same sentence could sit unnoticed for years.

The real risk is not knowledge, it is access

Once the handover of knowledge is solved, a quieter question is left: whose are the doors? The repository the code lives in, the cloud account that runs it, the domain, the billing account, the credentials in the CI/CD pipeline. If these sit on the developer's personal accounts, even the best-documented repository ends up behind a locked door. The newcomer knows what to do but cannot do it.

That is why we work to four rules on client projects:

1. Every service is registered under a company account. The company's GitHub organization, its cloud organization, the domain, the billing account and every third-party service the project uses. A person is only granted access. When the person leaves, the only thing that leaves is that access.
2. Everything that runs unattended uses a service account or a functional account. The pipeline, the running functions, the extension that sends e-mail, the alert channel. None of them is tied to a person's login.
3. No personal token in the pipeline. Rotating a credential never requires logging in to the account of the person who first issued it.
4. No secret's value is kept in the repository. The repository says each credential's name, where it lives, who owns it and how it is rotated. The value itself lives where it is meant to be kept: in the pipeline's secret store (GitHub Secrets), in the cloud's Secret Manager, on the developer's machine.

The fourth rule's concrete form is an inventory page in the repository: which service belongs to which account, which credentials the pipeline uses, which ones the running system uses and which ones a developer machine uses; how each one is rotated, and what is done in which order on handover day.

In short: the knowledge in the repository, the keys in your hands.

Scenarios

“If the developer leaves” is not one scenario. Each of them starts differently, but they all end up in the same place.

The developer cannot be reached tomorrow

Through illness, an accident or some other reason. It is the only scenario nobody can prepare for, so it is also the yardstick: if nothing can be taken from the person themselves, what is left? If the rules were followed, everything. The accounts are already yours, and you are the one who grants access. The new developer clones the repository, and the agent explains to them how the system works, what comes next and where everything is, reading it all from the repository. The only thing missing is the access the previous developer held. You remove that too.

The contract ends

Your side may want this, or ours. Either way the order is the same: first our access is removed, then every credential we could have copied is rotated. Because the inventory says where each credential lives and how it is rotated, this is not a negotiation, it is a checklist. What the departing side keeps is only a copy of the repository, and that opens no door.

You want to bring the work in-house

The point where the project has grown and running it inside the company makes sense. When your team opens the repository, it finds not a black box but a system that explains itself. The transition stops being a knowledge transfer project and becomes a handover of access.

You move to another firm, or we take over someone else's project

Two directions of the same scenario. For the new firm the starting point is the same as for a new employee. In the other direction, when we take over a project someone else has left, our first job is to bring that project to this state: writing down in the repository who owns the accounts, where the credentials live, and the process itself. The only safe way to take over a project that does not explain itself is to make it explain itself first.

Someone new joins the team

The scenario where nobody leaves and someone only arrives. It is still a rehearsal of the same flow: the new person is granted access, sets up their machine and asks the agent their first question. The only difference between onboarding a person and handing over a project is whether the previous person's access is removed.

Three things AI does not take away

This article does not claim that “AI knows everything and nobody is needed any more”. Three things still belong to people, and deliberately so.

Access and secrets. These are not handed over; they are rotated. The agent can say where a credential lives; it does not know the credential itself, and it should not.

The person who approves. The agent knows the process, but it does not take the responsibility. In this repository every change is reviewed before it is pushed, and every write to a real environment shows its diff first and is not written until a person approves it. Whoever takes over has to be competent to give that approval. So the right sentence is not “the newcomer carries on flawlessly”, but “the newcomer carries on from where things were left, with the same safety nets”.

Discipline. This structure does not stand up on its own. The description of code whose behaviour changes is updated in the same change, a recurring mistake becomes a rule or a test, and a new credential enters the inventory on the same day. Building this structure and keeping it standing is our job.

Handover day

In a project where the rules were followed, a new developer's first day looks like this:

Read this diagram as text

The new developer is first granted access with the company account: the repository, the cloud account, the domain and the billing account. In the same places, the previous developer's access is removed. Then every credential the previous developer could have copied is rotated, in the order the inventory gives. The new developer sets up their own machine, logs in with their own credentials, opens the agent in the repository and says “hello” to it.

1. Access company account
2. Old access removed
3. Credentials rotated
4. Setup own machine
5. Login own identity
6. Hello first question

1. Access. The new developer is granted access with the company account: the repository, the cloud account, the domain, the billing account and the other services the project uses.
2. Old access. In the same places, the previous developer's access is removed.
3. Credentials. Every credential the previous developer could have copied is rotated, in the order the inventory gives: the pipeline's service account keys, the test tokens, the e-mail service's password.
4. Setup. The new developer installs the repository and its dependencies on their own machine.
5. Login. They log in to the cloud's and the agent's command-line tools with their own identity.
6. Hello. They open the agent in the repository and say “hello, what's next?”. The agent reads the rules file, looks at the backlog and carries on from where things were left.

There is no knowledge transfer step on the list. There is no meeting, no handover document and no week spent with the previous developer either. The knowledge has nowhere left to be transferred to, because it was already in the repository.

Our own site: accepted differences

I applied this standard to this site too, and took its inventory. In a few places we depart from it on purpose. We are a small company with one developer, who is also its owner, and for some services a personal account is much cheaper than a company one, or even free.

Those differences are in the repository too, written in the inventory under the heading “accepted differences”. Why each one was accepted and what it requires in a handover sit next to it. An unknown risk and a recorded, accepted difference are not the same thing. Whoever takes over does not run into them as a surprise; they find them on the list.

On client projects the default is the standard itself. When a cost or time constraint makes a small difference sensible, we decide on it together with the client: what is accepted, why and with what risk is written into the inventory, and the decision is the client's.

Frequently asked questions

Closing

When you assess a software firm, the right question is not “what happens if something happens to this person?”. The right question is: “If this person left tomorrow, what would their replacement do on the first day?” If the answer is a checklist and a “hello”, working with a small firm means depending on a system, not on a person.

If you would like to work out together how your current project answers that question, write to us through the contact page. A list of your accounts and a look at your repository are enough to start.

This article is the fourth in a series. Why the system was built: GCP Cost: The 8-Year Bill for One Decision. How it works: The Architecture You're Visiting: How This Site Runs on GCP. How it is developed: Claude Code CLI and Antigravity CLI: Where Should a Rule Live?