Zero AI Onboarding:
give a new developer's Claude full context on day one

Imagine it's a new developer's first day. They open their editor, fire up Claude Code, and type: "Give me an overview of this codebase." Instead of a generic summary scraped from README.md, the AI briefs them on the actual state of the system — which services are flaky, why JWT tokens live in httpOnly cookies and not localStorage, why docker compose up without -d over SSH will ruin your afternoon.

This isn't hypothetical. It's what happens when you combine cachly's brain_from_git with a single invite link. The team lead does two things. The new developer does one. And the AI that greets them on day one already knows what the team knows.

Developers have gotten good at onboarding each other. There are wikis, architecture diagrams, runbooks, Slack channels full of tribal knowledge. What nobody has figured out yet is how to onboard an AI assistant.

The problem compounds fast. Every time a new developer starts working with Claude Code, their AI session opens cold — no memory of the codebase, no awareness of conventions, no knowledge of what the team has already tried and discarded. So the developer re-explains. Over and over, across every new session: "we use Zod for validation, not Yup," "the Redis client has a connection pool timeout issue — use these exact config values," "Stripe webhooks have to bypass the rate limiter or they break."

Multiply that by every new hire, every onboarding session, every context switch. And add the worst version: a junior developer who doesn't know what they don't know. Their AI confidently suggests the exact pattern the team already discovered was broken — because nobody told it, and they didn't know to ask.

The cost isn't just time. It's repeated mistakes, slower ramp-up, and AI assistance that's less useful precisely when it matters most — when someone is new and needs it most.

Cachly solves this with two tools working together: brain_from_git and invite_link.

brain_from_gitreads your repository's commit history — deploy commits, hotfixes, reverts, refactors — and distills them into structured Brain lessons. It works backward through real git history to bootstrap the AI's knowledge from the accumulated decisions your team has already made. A year of commits becomes a Brain loaded with architecture context, severity-weighted lessons, and operational history. It runs once, takes a few minutes, and the result is a Brain that knows your codebase from day one.

invite_link takes that Brain and generates a shareable join token. Anyone who runs the join command connects their local AI setup to the team Brain instantly — no configuration, no manual export, no copy-pasting context files.

In practice, this is what it looks like. The tech lead runs two commands in their AI session:

They send that one line to the new developer. The new developer runs it:

That's the entire process. No wiki to read, no onboarding doc to maintain, no context file to copy. The new developer's Claude Code is now connected to the same Brain the rest of the team uses — loaded with everything brain_from_git pulled from a year of real commit history.

When the new developer opens their first session, cachly's session_start briefing runs automatically. Instead of a blank slate, they get this:

Before the new developer has written a single line of code, their AI assistant knows about the Safari cookie issue that burned the team three months ago. It knows about the Redis timeout fix. It knows the Stripe webhook allowlist. These aren't generic best practices — they're your team's specific hard-won lessons, extracted from your actual git history and delivered on day one.

For larger teams, the implications go further than individual onboarding. Every developer's AI session starting from the same Brain means a floor of consistent knowledge across the entire engineering org. Senior engineers' lessons — the kind that usually only get passed down through proximity and code review — become part of every junior developer's AI context from their first day.

Invite links can be scoped by team, project, or role. The frontend team's Brain doesn't have to include infrastructure lessons that aren't relevant to them. New hires in different departments join different Brains. And because the Brain accumulates continuously — new lessons from ongoing sessions, new history from ongoing commits — the knowledge is always current. There's no stale onboarding doc to maintain.

The practical result is that AI quality stops varying by seniority or time-on-project. A developer who joined last week has an AI assistant that knows what a developer who's been on the project for two years knows. Not everything — experience isn't fully transferable — but the accumulated decisions, the gotchas, the "here's why we do it this way" context that usually takes months to absorb.

You don't need to instrument anything new or change any workflows to get started. brain_from_git works on the history you already have. Every hotfix, every carefully worded commit message, every revert — it's all already there, waiting to be turned into AI context.

Run it today on a repository that's been active for a year or more. Watch what it surfaces. The lessons it extracts from your commit history will tell you something about your own codebase — and they'll give the next developer who joins your team an AI assistant that already knows your system before they write their first line.