Level 07 · Fleet
It outgrew you, and it has to survive people who did not build it.
A codebase that only one person understands is a business risk, and one built largely by a model is a particular case of it: the reasons live in a chat history nobody else can read. This level is about making the thing legible to people who were not there.
You are here if
- You are the only person who can deploy it.
- Nobody else knows why anything was built the way it was.
- Onboarding someone would take a week of you sitting next to them.
- You are hiring, and you do not know what to tell them about how you work.
The reasons are the missing artefact
Code says what it does. It does not say what you rejected, or the constraint that made an odd choice correct. In a project built with a model, those reasons were in a conversation that is now gone, which is why the second developer’s first instinct is usually to rewrite something that was right.
The fix is small and unglamorous: a decisions file. Date, what you chose, what you rejected, why, in three lines. Twenty entries is enough to make a codebase legible, and it is the single highest-return document in this whole climb.
Checks a machine can run
As soon as more than one person changes the code, “I tested it” stops being a system. You do not need full coverage. You need a handful of tests over the paths that would embarrass you if they broke, running automatically on every push, plus whatever type or lint checks your stack gives you for free.
This matters twice as much with AI-written code, because it is fluent and plausible, and reviewing it carefully is tiring. A test that fails is not tired.
Onboarding as a measured thing
The target is an hour: clone, install, run, see it working, with one document to follow. Test it with the next person who joins, watch where they get stuck without helping, and fix that step. Every stall you remove you remove for everyone after them.
It doubles as a disaster plan. A project a stranger can run in an hour is one that survives you being unavailable.
What the machines are allowed to do alone
With a team, the question stops being personal and becomes policy: what may an agent change without a human looking, and what may it never do unattended. Our own answer is the one we ship: anything outward-facing or irreversible passes a human gate, and it is enforced in the architecture rather than left as a habit.
Write yours down before the first hire, because the alternative is that each new person invents their own, and you find out which one they picked from the incident.
Run it yourself
The checklist we would run.
There is nothing held back in it. If you work through this list and nothing on it is open, you have left this level, and you did not need us to do it.
- 01
A new developer can run it in an hour from one document
Measured on a real person, not estimated.
- 02
A decisions file with real entries
What you chose, what you rejected, why. Three lines each.
- 03
Checks run automatically on every push
A few meaningful tests beat a coverage number.
- 04
More than one person can deploy and roll back
And has done it once, on purpose.
- 05
Access is listed and reviewed
Who can reach production, the database, the keys. Remove the ones that are no longer needed.
- 06
A written rule for what agents may do unattended
Before the first hire, not after the first incident.
- 07
Someone other than you has restored a backup
The bus factor is not one until a second person has actually done the recovery.
What done looks like
- Someone else shipped a change end to end without you.
- A stranger can understand why the odd parts are the way they are.
- You could be unreachable for two weeks.
Where it usually goes wrong
Documenting everything
Nobody reads it and it goes stale. Twenty decisions and one runnable onboarding beat a wiki.
Hiring before the project is legible
You pay for two weeks of someone reading, then rewriting what they did not understand.
Leaving the agent rules implicit
Every person will assume a different line, and you will discover the differences the expensive way.
If you want company
Handover as an engineering problem: written decisions, runnable checks, an onboarding a new developer can follow, and the first hires briefed on what the machines do and what the humans keep.
Handover is the one piece of work we are happy to be measured on by never being needed again.
It starts with a conversation and innovate@isyncso.com, subject Hangar. Tell us the level you landed on and what is in front of you. If the answer is on this page, we will say so.