Joining a codebase that changes 200 times a day
By Soumen Sarkar · October 2026
Scenario. A new developer joins a fast-moving codebase and ships on day one by looking first: briefs, the team's record, and assumptions answered from it.
How does someone new get productive in a codebase that never holds still?
By looking first. When the team's decisions, work in progress and past dead ends arrive with the code, a newcomer's agents find most answers before anyone is asked, and state an assumption for the rest. Here are a new developer's first three days.
A made-up team, a real way of working.
The team builds route planning for delivery vans: which stops each driver makes, in what order, around their breaks. Six people run their own agents, and on a busy day around two hundred changes land. Femi joins on Monday. His first task: add a lunch break to driver shifts, so routes don't put a stop inside it.
Monday
09:30
Femi connects. In Claude Code it's a one-line setup from /connect, which adds the connection and the hooks. His first session opens with a brief of the team's state: what's in progress, what landed this week, the rules that stand. Nothing in it is addressed to him yet, and that's fine.
He types the task. That first request becomes the goal of his work in progress, so the team can see what the new person is doing without asking him.
09:34
His agent reads the routing code and gets its first area brief, for Routing · lib/routing:
Being changed right now
Grace: Re-plan routes when a van breaks down (expected Wednesday)
Decisions here
Times are stored in the depot's local time zone (Grace, last week)
Routes are re-planned at most every 5 minutes (5 months ago: check it still holds)
Tried and dropped
Splitting a route mid-shift: drivers lost track of where they were
Open assumptions
None
Femi reads it over his agent's shoulder. In thirty seconds he knows what is moving, what stands and what was tried, and which part of it might be stale.
09:50
The agent has its first unknown: if a delivery runs late, can the break move? It doesn't ask Femi or anyone else. It states its assumption:
state_assumption
question: If a delivery runs late, can the lunch break move?
assumption: No. The break is fixed and later stops shift.
The team's record already answers it. A decision Ade made last month in Shifts · lib/shifts, "Breaks are fixed; deliveries move around them", comes straight back, and the agent carries on. Nobody was interrupted.
10:40
The next unknown isn't written down anywhere: should the break show in the driver app as a stop on the route, or as a gap? The agent assumes "a stop, labelled Break, so drivers see it in order" and keeps going. The assumption goes to Grace, who last worked in the area.
11:15
Grace sees it on Activity and opens its "Answer it" link. The driver app isn't hers, so she clicks "Not mine to check", and it passes on to Ade, who owns the driver app. Ade picks the likely answer "a stop, labelled Break". Femi's agent hears at its next turn that it was right.
12:30
Femi notices Grace's breakdown work in the area brief. Re-planning around a broken-down van will have to respect breaks too, so his work and hers will meet. His agent calls wait_on with Grace's work. It gets her plan now, builds the break check as one function her re-planning can call, and will hear when her work lands.
He also sets Activity's Area filter to Routing. In one list he can see everything moving there: Grace's work, his own, and the assumptions open in the area.
14:00
Femi wants the bigger picture. He asks his agent to read the Record, the story of the project's calls, and summarise why routes re-plan every five minutes. The answer: it was set to keep the old driver phones from overheating. He doesn't need to book a meeting to learn the history of the code.
16:50
The change is done. On commit, its reasons are written for the reviewer, including both assumptions and how each was settled. Femi puts the link in his pull request description. Ade reviews it by its reasons and merges it the same afternoon.
Tuesday
09:10
Femi's session brief opens with "Pick up where it was left": nothing of his is unfinished, and nothing has been handed to him. He starts the next task, showing break times on the dispatcher's map.
09:25
His agent touches the five-minute re-planning rule, the one marked "check it still holds". It doesn't treat a five-month-old decision as law, and it doesn't stop either:
state_assumption
question: Does "re-plan at most every 5 minutes" still hold?
assumption: Yes. The map refreshes on the same 5-minute cycle.
likely answers: still 5 minutes · now 1 minute · no limit
10:05
Grace clicks "Correct it…": "Drivers have new phones since spring. It's 1 minute now." Femi's agent hears the correction at its next turn and changes one constant.
Grace records the new decision with its reason. It clashes with the old one, so the newer call stands, and the old one is marked replaced. The next agent to open the routing code gets the current rule.
Wednesday
11:20
Femi opens Activity with Since set to "your last visit", and finds something new: an assumption from one of Grace's agents, about how breaks interact with breakdowns. It came to him because he last worked on breaks. He follows its "Answer it" link and clicks "Right, keep going".
Three days in, he's the one in the area other people's agents find answers from.
What made it work
- [Answer it yourself](/vibeflock/answer-it-yourself). Femi's agents looked first. One question was answered straight from the record, and the rest became stated assumptions.
- [Turn unknowns into calls](/vibeflock/turn-unknowns-into-calls). Even the stale rule became a call to confirm, not a reason to stop.
- [Fix forward](/vibeflock/fix-forward). The out-of-date decision was corrected in a sentence, and from then on every agent got the new one.
- [Decide by doing](/vibeflock/decide-by-doing). The team's decisions, written with reasons as the work happened, did the onboarding.
For the questions a newcomer usually asks, see how to onboard someone onto a codebase built by agents.
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).