Day one on a new codebase. You have cloned the repo, run the setup script, and you are staring at a folder tree with 400 files and no idea where anything actually happens. Your team's documentation is twelve months stale. The senior engineer who built this is in a different timezone.
This experience is nearly universal. It is also almost entirely unnecessary.
The documentation gap
Teams write documentation for the architecture they designed, not the architecture they shipped. Refactors happen; the docs don't follow. By the time a new engineer reads the architecture overview, it describes a system that no longer quite exists.
The code, however, always describes the system that exists. The question is how to read it structurally, not just line by line.
What a new engineer actually needs to know
The questions that consume the first week of onboarding are almost all structural:
- Where does the application actually start?
- Which files handle the feature I'm working on?
- If I change this, what else will I need to touch?
- Who owns this part of the codebase?
- What depends on the thing I'm about to modify?
None of these questions can be answered by reading files sequentially. They require graph traversal, following edges from the entry point outward, or backward from a target node to its callers.
The code graph as an onboarding tool
A Spiderbrain brain built from your codebase lets you answer all of those questions structurally, before the new engineer writes their first line of code.
Entry point mapping: which nodes have high in-degree and no significant ancestors? These are your entry points, request handlers, CLI commands, scheduled jobs.
Feature-local subgraph: given the files for a feature area, what is the transitive import closure? Show a new engineer the subgraph for the feature they're working on, they immediately know which files are in scope.
Blast radius awareness from day one: before their first PR, show the new engineer the blast radius of their change. "Your change touches auth/session.js. This has 18 callers. Here are the 3 that don't have test coverage."
Community ownership: community membership tells a new engineer which files belong together structurally, independent of the folder organisation.
The senior engineer's time budget
The hidden cost of slow onboarding is not just the new engineer's productivity, it is the senior engineer's time. Every "where does X happen?" question costs five minutes to answer and context-switches the responder out of deep work.
A code graph externalises the structural knowledge that senior engineers carry in their heads. The new engineer can answer their own structural questions. Senior time goes back to senior work.
What it looks like in practice
A structured onboarding workflow with Spiderbrain:
- Before they start: build a brain from the current commit and share the brain ID (no source code shared)
- Day one: new engineer runs
/api/scoreon the feature area; sees the top-ranked structurally significant files - First PR: blast radius surfaced in CI; new engineer can explain their change's scope before review
- First week: community detection shows which modules are "theirs" to own versus shared infrastructure
The goal is not to replace mentorship, it is to eliminate the questions that shouldn't require a person.