@@ · the apprenticeship @@

Junior developers, AI code review, and the learning loop we are quietly breaking

Othman Shareef · August 3, 2026 · 6 min read · AI and Code Review

The scenario comes straight from Addy Osmani’s writing on agentic code review: a junior developer prompts an agent, gets a plausible five-hundred-line PR, opens it, and it lands. Somewhere in that sequence a question went unasked and unanswered: who actually reviewed this? For junior developers, AI code review is not an abstract workflow debate. It decides whether the review process still teaches them anything, or whether they become couriers moving code they do not understand from a model to the main branch.

The ownership gap nobody assigned

In the classic flow, authorship and understanding traveled together. Whoever opened the PR could defend it, and review was a conversation between two people who both held a model of the change. The agent workflow splits that: the junior owns the prompt, the model owns the reasoning, and the reviewer assumes the junior vetted what they are submitting. Often nobody did. Osmani’s framing of the moment is worth repeating: reading code has always been the skill, and it is about to be the skill. The uncomfortable corollary is that juniors are now shipping volumes of code that outrun their reading ability, and the process meant to catch that is the same one being squeezed by the volume.

Review was the learning loop all along

Code review was never only a defect filter. Microsoft’s research on modern code review (Bacchelli and Bird) found that understanding the change is the single biggest challenge reviewers face, and that knowledge transfer is one of review’s most valuable real outcomes, whatever teams claim it is for. We covered the same evidence in do code reviews find bugs: the bug counts are modest, the education is the payoff. For juniors specifically, review comments were the apprenticeship: the place someone senior examined their reasoning and handed back a better mental model. If the code arrives with no reasoning to examine, that loop breaks silently while the merge rate looks healthier than ever.

Seniors: review the model’s choices out loud

The senior reviewer’s job on an AI-heavy junior PR shifts from finding what is wrong to making the invisible reasoning visible. The highest-value comments are questions: why did the model reach for this pattern, what would the alternative have looked like, what does this change do to the callers three files away? Sometimes the junior knows. Often the honest answer is “I did not ask,” and that answer, said in a review thread rather than discovered in an incident, is the teaching moment. A senior who silently fixes or silently approves is optimizing for throughput and training a developer who will need the same rescue next month.

The collaboration cost is already visible

This is not hypothetical hand-wringing. A widely discussed r/ExperiencedDevs thread asks whether AI has made developers less collaborative, and the recurring pattern in the replies is exactly this shape: people consult the model before they consult a colleague, review threads go quiet, and juniors in particular stop asking the questions they used to ask out loud. Every question routed to a model instead of a teammate is individually reasonable and collectively erodes the channel that apprenticeship ran on. Teams do not lose mentorship in one decision. They lose it one skipped conversation at a time.

Norms for junior developers in AI code review

None of this argues for banning agents, which would only push usage underground. It argues for norms that reattach understanding to authorship:

  • Self-review before requesting review. The junior reads their own diff first, hunk by hunk, and fixes what embarrasses them. We laid out the practice in author self-review; for AI-generated changes it is non-negotiable.
  • Annotate intent while it exists. What was asked for, what the model chose, what was rejected, what is untested, in PR comments or the description, following capturing intent for AI changes.
  • The explain-any-hunk rule. If a reviewer points at a hunk, the author can explain it or the PR is not ready. This single norm converts generation speed back into learning pressure.
  • Keep one review human and conversational. Bots can pre-filter, but a junior’s PR should always get at least one human reviewer who asks at least one why.

The teams that hold these lines get the best of both: juniors who ship faster than any previous generation, and who are actually becoming the seniors who can review what the machines write next.

One more reframe worth stating plainly, again borrowing Osmani’s point: PR size is a review problem before it is a model problem. A junior who prompts an agent into a thousand-line change has not misused the model; they have produced something nobody can teach through. Part of the mentorship now is scoping: helping juniors learn to ask for changes small enough that the review conversation can still happen at all. The skill being trained is not prompting. It is judgment about what a reviewable unit of work looks like, and that skill outlives any particular tool.

Frequently asked questions

Should junior developers use AI to write code?

Yes, banning it just teaches them to hide it. The workable norm is ownership: a junior can generate as much code as they like, but before requesting review they self-review the diff, annotate why the change looks the way it does, and must be able to explain any hunk a reviewer asks about. The tool is fine; unexplained code is not.

How should seniors review AI-generated code from juniors?

Treat the review as teaching, not just defect hunting. Ask why the model chose this approach, what the alternatives were, and what the change breaks downstream. Microsoft’s research on modern code review found understanding is the top challenge and knowledge transfer a core outcome, and those questions are how the transfer survives when a model wrote the first draft.

Does AI-generated code hurt junior developer growth?

It can, if the review loop collapses. Juniors historically learned by having their reasoning examined in review. When an agent writes the code and review becomes a rubber stamp, that loop disappears and juniors can ship for months without forming a model of the system. Teams that keep review conversational, with juniors explaining and annotating their changes, keep the growth.

← All posts