The first month at a new job is a race against context. The codebase is large. The conventions are unwritten. The people who know are busy. An AI pair can compress some of that work, but only some, and only the parts where being approximately right is acceptable. The rest you have to read yourself. This is a four-week plan that names which parts are which.
Why this matters
Onboarding is the highest-stakes context window of your career at any company. Every assumption you form in the first month becomes a default for the next year. If those defaults are wrong, every PR you write fights the codebase instead of working with it. AI compresses the right kind of onboarding work — orientation, vocabulary, where-do-things-live — and corrupts the wrong kind: invariants, idioms, and the unwritten rules that exist precisely because someone shipped a bug last year. The plan below names the split.
Where should AI read for you in week one?
In week one, the goal is orientation, not mastery. You need to know where the major directories live, what the deploy pipeline looks like, what the test suite covers, and which services own which responsibilities. AI is good at producing this map. It is also good at summarizing the README, the contributing guide, and the architecture doc into a single short brief. Have it do that on day one and read its summary critically — not because the summary is wrong (it probably isn't), but because critical reading is the muscle you are about to need a lot of.
What AI should not do in week one is form your opinion about why things are structured the way they are. The architecture is the answer to a question the team faced in 2022. You need to learn the question, not the answer. The question lives in the commit history, the post-mortem channel, and the heads of two engineers who have been there longest. AI cannot reach any of those.
When do you stop trusting AI's summary and start reading the source?
By the end of week one, you should already be skeptical of AI summaries of any document longer than a page. The failure mode is not that the summary is wrong end-to-end. The failure mode is that one specific clause is wrong in a way that matters — a constraint dropped, an exception generalized away, a "usually" promoted to "always." You will not notice from the summary. You will notice when your PR violates the dropped clause.
The bar chart below is from our internal study of onboarding sessions across 14 codebases. We measured time spent on four activities and split it by whether AI's involvement saved or lost minutes over a representative hour of work.
The positive bars are the activities AI compresses cleanly. The negative bars are the ones it corrupts. Reading code for orientation — "what does this module do, roughly" — is the AI-shaped task. Reading code for root cause — "why does this module behave this way under contention" — is the task where AI's plausible-sounding summary sends you the wrong direction and costs you the minutes you appeared to save earlier.
How do you avoid the plausible-nonsense trap with an unfamiliar codebase?
The trap is well-named because it is what makes AI uniquely dangerous on a codebase you do not yet know. In a familiar codebase you can tell when an AI answer is structurally wrong because the shape of the wrong answer collides with the shape of the code you already remember. In an unfamiliar codebase you have no shape to compare against. Every answer sounds plausible because every answer sounds like code.
The discipline that breaks the trap: never accept an AI summary of a function whose behavior you cannot reproduce. If the answer to "what does this function do" is something you cannot run, log, or trace through yourself, the answer is provisional. Mark it provisional in your notes. Revisit it before it becomes a default.
The table below is the question split we recommend to new hires on the platform.
| Phase | Best questions for AI | Ask humans instead | Why |
|---|---|---|---|
| Day 1 | What does this acronym mean? Where in the repo is the auth layer? Summarize the README. | Who owns this service? Which post-mortem should I read first? What was the last big incident? | AI knows the repo's surface. Humans know the repo's history. You need both, but only humans have the history. |
| Week 1 | Explain this library call. What is this design pattern? Translate this idiom to the language I know. | Why did we pick this database? What did we try first that didn't work? | AI explains the present. Humans remember the rejected alternatives, which is where the rationale lives. |
| Week 2 | Where else in the repo is this function called? Draft a small PR that does X. | What invariants does this module assume? Whose review do I need on a change to this file? | AI is a faster grep with explanations. Invariants are unwritten and live with the people, not the code. |
| Week 3+ | Generate search queries I would have typed. Find code in this repo that does Y. | Is this the right abstraction to add, or am I about to repeat a mistake? | By week three, the questions worth asking humans are about judgment, not knowledge. Knowledge questions go to AI. |
What does your first PR need to prove?
Not that you can ship. Anyone can ship a one-line change in week three. The first PR needs to prove that you read the surrounding code, understood the convention the file uses, and respected an invariant that is not documented anywhere. Reviewers grade the first PR on those three things specifically. A passing first PR earns trust faster than a passing second-month PR earns it, because the first one is the signal that you did the reading.
AI can draft the change. AI cannot tell you which invariant the surrounding file is enforcing, because the invariant is in the team's heads and possibly in a Slack message from 2023. The draft AI produces will be syntactically clean and will, often, violate the invariant. Read the file. Read the file's history. Then submit.
The bug taxonomy that explains why AI's first-week summaries are most often wrong.
From Codritium Research
Where the AI Pair Fails
A taxonomy of the 1,876 bugs AI-assisted engineers shipped during our 2026 benchmark. Twelve bug classes, ranked, with the code patterns each one travels on.
Common questions
Can AI replace pairing with a human onboard buddy?
No. The buddy carries the history, the politics, and the unwritten rules. AI carries the syntax. The right split is to use AI for the questions you would have felt embarrassed asking a human five times, and to spend buddy time on the questions whose answers are not in the repo.
Should I let AI summarize the architecture doc?
On day one, yes — for orientation. By day five, you should have read the doc yourself, because the summary will have dropped at least one constraint you will care about within the month. The summary is a table of contents, not a substitute.
How do you handle internal frameworks AI has never seen?
Read the source by hand and write your own short notes. AI's hallucination rate on internal frameworks is higher than on public ones because it pattern-matches to the closest public framework it knows, and the pattern-match is often wrong in load-bearing places. Treat AI's answers on internal frameworks as guesses.
When is it OK to ask AI questions instead of your team lead?
When the question is factual and reproducible — 'what does this function call do', 'where is this defined', 'what does this error mean'. Save your team lead for the questions that need history, judgment, or politics. Those are the ones that are not in the repo and will not be in AI's training data either.
What should I commit to memory vs lean on AI for?
Memorize the service map, the deploy pipeline, the test command, and the names of three people whose review you will need on changes to the parts you touch most. Everything else — function signatures, library APIs, file paths — is fine to look up. The memorization bar is 'things that get you unblocked in a meeting.'
Where to go next
- Where AI Pair Programming Fails — the failure modes to recognize in week one
- Platform challenges — practice on production-shaped codebases
- The 12 most common bugs AI pair programmers introduce