Spend the first thirty days on reading, not writing. Pair on review before implementation, run the spec-agent-review loop, and stop assigning work an agent already does better.
By JP LeBlanc
Onboard a junior into an agentic team by changing what the first ninety days are supposed to produce. The old plan measured how much code a new hire could write independently by month three. The new one measures whether they can write a spec precise enough for an agent to build correctly, review the result well enough to catch what a senior would catch, and need less hand-holding doing both by week six than week one. Spend the first thirty days on reading the system, not writing in it. Pair them on review before you pair them on implementation. Stop assigning the syntax practice that used to fill the entire first year, because an agent already does that part better than a junior does.
The instinct to get a new hire shipping fast is right, and it still holds: a change in production on day one tells you more about your environment than about the person, and it's worth protecting. What changes is what the rest of the month is for.
The old first month was mostly writing: small tickets, low stakes, building muscle memory for the codebase one modest PR at a time. That muscle isn't the one that matters most now. Spend the month instead having them read: real pull requests that already merged, the incident history, the context files that describe how the system actually works versus how the onboarding doc claims it works. Ask them to predict what a reviewer will flag before they see the actual comments, and check how often they're right. That's a sharper signal about judgment than a month of tickets ever produced, and it costs nothing to run.
Most onboarding pairs a junior with a senior writing code together. Flip it. Have them review a senior's change first, out loud, before they've written a line themselves.
The value isn't that they'll catch anything. Early on they won't, and that's fine. It's that reviewing forces them to build a model of why a change is correct, not just that it runs, and that model is the thing an agent can't hand them for free. Juniors who review more than they write are growing the muscle the job actually needs now, because the old apprenticeship, which ran on writing a lot of mediocre code and getting it corrected, doesn't have anywhere left to run. The volume of code a junior can generate is no longer the bottleneck on their growth. Their judgment about what's correct is.
Once the reading month is behind them, put them inside a specific loop and keep them there for a while: they write the spec for a real, bounded piece of work. An agent implements it. They review what came back against the spec they wrote, not against their own guess at what good code looks like. Then a senior reviews their review, not the code underneath it, and tells them what they missed.
That last step is the one teams skip, and it's the one doing the actual teaching. Reviewing the reviewer is slower than reviewing the code directly, and for the first few cycles it will feel like it's costing a senior's time for no visible output. It is costing that time. It's also the only mechanism left that closes the gap the old apprenticeship closed by sheer volume: a junior submits a clean, working PR built by an agent, gets asked why one check runs before another, and doesn't know, because the tool made the right answer easy to produce and easy to skip understanding. Catching that gap early, cheaply, in a review of a review, is a lot less expensive than catching it in production eight months later.
The tempting design rotates a different senior through each week, on the theory that broader exposure serves the junior better. It doesn't. Consistency matters more than variety, because a senior reviewing a junior's reviews needs to see the pattern across several weeks to know whether the gaps are closing, and a rotating cast never accumulates that picture. Rotate, and the first month of data is mostly noise you generated yourself.
Drop the tickets whose entire value used to be syntax repetition: the boilerplate CRUD endpoint, the mechanical refactor, the config change that used to teach a junior the corners of the codebase by forcing them to touch every one of them. An agent does that work faster and just as correctly, and assigning it to a junior now mostly teaches them to type, which was never the scarce skill even when it looked like it was.
What replaces it is smaller and harder to hand off: requests with real ambiguity left in them, where the ambiguity is the entire exercise. Give them a request with genuine gaps and have them write the spec that closes those gaps before anything gets built. That's a heavier lift for both of you than a boilerplate ticket ever was, and it's the actual job now.
Two signals, and neither is subjective. How much editing their spec needs before an agent can build against it without a senior stepping in, and how often their review of an agent's output agrees with a senior's independent review of the same change. Both should be moving, visibly, by week six. If neither is, the loop isn't running, whatever the calendar says about how many pairing sessions happened.
The old apprenticeship took years and mostly worked by accident, ground out of a person writing enough bad code to eventually stop. This one is faster, more deliberate, and it asks more of the senior running it than the old one ever did. That's a fair trade for what it produces.