The single biggest predictor of whether a new AI hire ships something real in month one isn't their resume, it's whether you handed them a plan on day one or left them to figure out the codebase, the data, and the org chart by themselves. Most founders over-invest in the hiring decision and under-invest in the 30 days after it, then wonder why a strong candidate is still 'getting oriented' in week five.
What day one actually needs to include
Most onboarding failures trace back to day one: no repo access until IT tickets clear, no clarity on which of the six 'AI-adjacent' services are actually load-bearing, and a Slack channel instead of a person. Treat day one like a checklist you'd run for a contractor starting a fixed-scope engagement, because in effect that's what the first month is.
- Repo, data warehouse, model provider, and eval tooling access provisioned before they arrive, not requested on arrival.
- A one-page architecture map: which services are production, which are experiments, which are dead code nobody deleted.
- A named buddy, not a channel, someone who answers questions same-day for the first two weeks.
- One small, real, already-scoped task ready to start on day one, not 'read the codebase first.'
The week-by-week arc
| Period | Goal | What 'done' looks like |
|---|---|---|
| Week 1 | Ship one small, real change | A PR merged that touches the actual production model pipeline, not a toy script |
| Week 2 | Understand the data and eval story | Can explain what the eval set measures and where it's weak, in their own words |
| Week 3 | Own one workflow's failure modes | Can debug a bad output without pulling in the original author |
| Week 4 | Propose one improvement | A written proposal for a change, with a tradeoff, not just a bug fix |
What's different about an AI codebase versus a normal one
Onboarding into an AI system has a layer standard engineering onboarding doesn't: the behavior isn't fully determined by the code, it's determined by the code plus the data plus the model plus the prompt or fine-tune history, often undocumented. A new hire needs deliberate exposure to that fourth layer, or they'll debug prompt regressions as if they were code regressions and lose days.
- Walk through the eval harness before the architecture diagram, it explains what 'working' means here.
- Show them three real failure cases from production, not the demo path, in week one.
- Explain any tribal-knowledge prompt or fine-tuning decisions explicitly, these rarely live in comments.
- Pair on at least one live incident or near-miss in the first two weeks if one occurs.
Signals you're off track, and how to correct
- Still asking 'who owns this?' after two weeks means the ownership map wasn't written down, write it now.
- No merged code by day 10 usually means the first task was scoped too large, cut it in half.
- Hire is reading broadly but can't explain the eval score means pair them with whoever owns quality, today.
- Buddy reports 'they haven't asked me anything' in week two is a red flag, not a compliment, check in directly.
