How do I onboard someone onto a codebase built by agents?
By Soumen Sarkar · October 2026
Short answer: Onboard someone onto an agent-built codebase by giving them the record of why the code is the way it is (decisions per area, what's changing now, what was tried and dropped) and letting them, and their agents, look things up instead of asking. Start them on real work in one area.
What's different about a codebase built by agents?
It changes fast, and the reasons behind it are rarely in anyone's head. When dozens of changes land a day, no single person remembers why each part looks the way it does. The code is readable, but the calls behind it (why this library, why this boundary, why not the obvious approach) were made in sessions that have ended.
So onboarding can't rely on a senior engineer explaining everything. By the time the tour is over, the code has moved.
What does a new person need first?
Not a tour of every folder. Three things:
- The global rules: what applies everywhere, in the team's agent instructions.
- The decisions, by area: what was decided in each part of the code, and why.
- What's moving now: which areas are being changed, by whom, toward what.
With those, a new person can answer most of their own questions. They look first, and when the record is silent, they state what they're assuming and keep going, like everyone else on the team.
How should their first week go?
Start them on real work in one area, with their own agents, from day one. The work is the onboarding.
Say a new developer joins a team building an analytics dashboard. Her first task is adding a date-range comparison to the charts in Dashboard · app/dashboard. Before her agent writes anything, it reads what's known about that area: charts take data already aggregated by the server, never raw events; a teammate is reworking the chart legend right now; client-side aggregation was tried and dropped because it froze on large accounts.
So her agent asks the server for both ranges, already aggregated, and leaves the legend alone, adding a note to build on the teammate's work in progress. She ships her first change on day two without having asked anyone why the dashboard works that way. When she finds something the record doesn't cover, she states an assumption, and the person who knows corrects it on their own time.
What should the team do to make this possible?
- Record decisions as they happen, tied to the part of the code they apply to.
- Keep work in progress visible, with its plan.
- Leave handoffs and reasons with the work, so the history of any change can be read later.
- Point the new person to the record, not to people. "Search first" is the most useful onboarding instruction there is.
What does Campfyrr give a newcomer?
Everything in the team's record is searchable by them and their agents. In Claude Code, the first session brief shows the team's state, and the first time any session reads or edits a part of the code, it gets an area brief: work in progress there, the decisions to follow, what changed this week, what was tried and dropped, and open assumptions. The Record tells the story of the project's calls for whoever wants the longer view.
The newcomer learns the codebase the way everyone else works on it: by answering it themselves from the team record, one area at a time.
Words used here
- Team record: The team record is everything a team has written down that a person or agent can search before asking: decisions, rules, handoffs, assumptions and the reasons behind changes.
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
- Decision: A decision is a call made in the work, recorded with its reason at the moment it is made, so it travels to everyone who touches the same ground.
The principle behind this: Answer it yourself: Look first. If the answer isn't there, assume it or decide it.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).