Onboarding new developers

A new hire's first weeks are spent asking the same questions of the same senior engineers: where is the webhook signature checked? which service owns billing state? what do I need to run the integration tests? CodeNavi answers those questions from the code itself — on your own hardware, with the code never leaving the box — so the new developer can explore on day one and the senior engineer stays in flow.

This page is the onboarding use case end to end. Everything on it is shipped behaviour; the links go to the reference pages.

Day one: chat before the local environment exists

A fresh laptop has no IDE plugin, no tokens, no working build yet. The web UI needs only a browser and the server URL:

• Chat is grounded Q&A across the indexed code, docs and (optionally) crawled internal pages. Every answer cites the chunks it used as file:line ranges, so "where is X" resolves to a place in the repository, not a paraphrase.
• Scope limits a session to one codebase or spans all of them — useful when the new hire's first task touches a shared library and the service that calls it.
• The LLM is whatever you configured: a local Ollama/vLLM/LM Studio model keeps everything on-box; a cloud provider is opt-in and the UI warns that retrieved code chunks will be sent to it.
• Sessions persist server-side, so a mentor can open the same conversation and see what was asked.

The same chat is available from the terminal for people who prefer it:

codenavi chat "trace an incoming order from the API router to the database write"
codenavi chat "which environment variables do the integration tests need?"

See the CLI reference.

Questions that work well in the first week:

Instead of asking a senior…	Ask CodeNavi
"Where does auth happen?"	"Where is the session token validated on incoming requests?"
"How does an order get saved?"	"Trace an order from the HTTP handler to the persistence layer."
"Is it safe to change this?"	"Who calls PaymentGateway::charge, and what depends on them?"
"Is there a doc for this?"	"What do the docs say about the release process?"

Week one: the map of the system

Two screens give the shape of the codebase without reading it file by file.

• Wiki — knowledge pages compiled by an LLM over the indexed documentation, with a staleness badge when the source docs have changed since compile. This is the "architecture overview" nobody had time to write, generated from the docs you already have, and re-generated when they change. Compile happens on-box with a local model, or with an explicit confirmation if you choose a remote one.
• Graph — the call graph as an interactive neighborhood explorer. Start from any symbol, expand callers and callees, see which functions are hubs (many callers — change them carefully), and jump to the source line. Cluster colouring shows which functions belong together even when the directory layout doesn't say so.

Week two: the first change, with a safety net

When the new developer starts editing, the same intelligence is available inside their agent — Claude Code, Codex CLI, Antigravity, VS Code, Zed and others, see Connect your agent:

• codebase_overview and generate_claude_md give the agent (and the human) the entry points, key modules and framework hints in one call.
• find_callers and impact_analysis show what a change touches before it is made; diff_impact reviews the actual diff against the call graph. The Claude Code plugin wraps the last one as /codenavi:review.
• save_note lets the developer — or their agent — record what they learned ("the retry loop in Dispatcher is intentional, see incident 2024-11"). Notes are anchored to the code they describe, flagged stale when that code changes, and surface as advisory results in later searches. Tribal knowledge stops living only in one person's head.

What the team gets

• Fewer interrupts. Baseline "where is / how does" questions go to the index first; the senior engineer sees the interesting ones.
• Consistent answers. Everyone queries the same index; the answer to "how does billing work" is the same on Monday and Thursday, and it cites code.
• Code stays home. The index, the embedder and (by default) the LLM run on your hardware. Nothing about onboarding requires a cloud account — the air-gapped setup supports every step on this page.
• It compounds. Notes, wiki pages and search feedback accumulate; the second hire onboards faster than the first.

Setting it up

1. Install CodeNavi and index the repositories a new hire will touch (reindex, one command per codebase).
2. Point chat at a local LLM (Settings → Chat LLM) — or accept the remote-provider warning if you prefer a cloud model.
3. Compile the wiki once the docs are indexed.
4. Give the new developer the web UI URL. Add the agent plugin when their environment is ready.