Onboarding
Onboarding used to happen twice a year. Now it happens every hour.
A new engineer spends their first weeks asking why the code is the way it is. Every agent session starts from the same blank slate and asks the same things. The answers exist. They are in your seniors, and your seniors are the ones paying for it.
The real cost is not the new person
A new engineer is slow for a while. Everyone expects that and budgets for it.
What nobody budgets for is the senior who answers the questions. That person is the fastest engineer you have, and for six weeks they are a search engine. Then it happens again with the next hire, and again every time an agent opens a session, because the agent knows even less and asks more often.
The answers were written down once, in a pull request nobody will scroll back to.
What they ask
- Why is this service still here?
- Who calls this, and what breaks if I change it?
- We tried that. Why did we stop?
- Is this the pattern we use now, or the old one?
- Who do I ask about billing?
Not one of these is answered by reading the code.
One query, two readers
Your new hire and your agent need the same thing
This is the only place the two overlap completely. Both arrive knowing nothing, both need the reasoning rather than the code, and neither will find it on their own.
The engineer who started Monday
Reads the approved records for the part they were handed, sees what depends on it, and finds the decision that explains the odd bit before asking anyone.
The agent that started this session
Pulls the same records through MCP before it writes anything, so it does not undo a workaround that is there on purpose.
Write the answer down once and both readers have it. That is the whole mechanism.
What comes back
- Only what the team stands behind
- Every record carries a status. Ask for the approved ones and a draft nobody has read does not reach a newcomer as though it were settled.
- A slice, not the whole thing
- A traversal is bounded, so the answer is small enough to read. A wiki hands you everything and lets you find it. This hands you the part that bears on what you are doing.
- The neighbours, not just the file
- The system graph comes with it, so "what breaks if I change this" is answered next to the code rather than in a meeting.
- The answer the senior already gave
- Reviews produce decisions and constraints. Captured once, they stop being something the same person explains twice.
It does not replace a mentor
A new engineer still needs someone to tell them what matters and what to ignore. What this removes is the part of that job nobody wanted: answering the same factual question for the fourth time. Keep the mentor. Give them back the afternoon.
Put your system on the record
Run the open core on your own infrastructure, or start on the hosted workspace. The graph is portable either way.