Shared context for AI tools
How to onboard a new engineer's AI on day one
Onboard a new engineer's AI tools on day one: give their Claude Code and Cursor your team's context, decisions, and recent activity so they ship sooner.
A new engineer's first weeks are slow for a known reason: they do not have the context yet. Now their AI tools do not have it either, so the tools that should accelerate the ramp instead generate code that does not fit how your team builds. The fix is to onboard the new hire's AI the same way you onboard the new hire: give it your team's context on day one.
Why a new hire's AI starts blind
Out of the box, their Claude Code and Cursor know general programming and nothing about you. They do not know your architecture, your conventions, the decisions you have made, or what shipped last week. So the new engineer spends time correcting the AI on top of learning the codebase themselves. The deeper context on this is shared context for AI tools.
Step 1: have the context ready before day one
The point of a shared context layer is that you do not assemble it per hire. It already holds:
- The architecture, stack, and conventions the team follows.
- The decisions already made, and why, so the AI does not re-propose what you reversed.
- Recent activity, so the tools know the current state, not last quarter's.
If that source exists, onboarding the AI is connecting it, not building it.
Step 2: connect their tools to the shared source
On day one, have the new engineer connect Claude Code and Cursor to the team's context over MCP. From the first prompt, their tools answer from your real architecture and decisions. See giving Claude Code your whole project context for the tool-level steps.
Step 3: let them learn from the activity stream
A new hire's biggest question is "what is going on right now." The activity and decisions ledger answers it: their AI can summarize what the team shipped and decided recently, so they get caught up without interrupting five people.
Step 4: scope what they see
Role-based access means the new engineer's tools read what they should, the team and project context, without exposing everything company-wide. Good onboarding context and good security are the same setting.
What changes
- The AI writes code matching your conventions from the first session, not generic defaults.
- The new hire stops correcting the AI on settled decisions.
- "How does this work and why" is a question their tools can answer, not only their teammates.
- The ramp shortens because the context was ready, not assembled per person.
The test
A new engineer's AI should be able to answer "why is auth built this way" on day one. If it guesses, it has the codebase but not the team's decisions.
TL;DR
A new hire's AI tools start blind to your architecture, conventions, and decisions, so they slow the ramp instead of speeding it. Onboard the AI the way you onboard the person: have a shared context source ready, connect their Claude Code and Cursor to it on day one, let them catch up from the activity ledger, and scope what they see by role. The tools then fit your team from the first prompt.
Give every new engineer's AI your conventions, decisions, and recent work on day one.
Related reading
What is shared context for AI tools? (2026 guide)
Shared context for AI tools is the company, project, and decision background every AI reads automatically, so your whole team's tools stop guessing.
How to give Claude Code your whole project context
Give Claude Code your whole project context, not just one repo's CLAUDE.md. Here is how a shared source keeps it current across repos, tools, and teammates.
What is an AI activity and decisions ledger?
An AI activity and decisions ledger is a running record your AI writes as work happens, what shipped and what the team decided, so nothing important is lost.
AI coding consistency across a team: a checklist
A practical checklist for keeping AI coding assistants consistent across a team, so Claude Code and Cursor produce code that fits your standards, not generic defaults.