The job flipped: a junior's first skill is now evaluating code they did not write, including the AI's. A practical onboarding playbook.
Onboarding a junior engineer in the AI era is no longer mostly about teaching them to write code. It is about teaching them to review, verify, and understand code, including the code an AI wrote for them. A junior who can generate a working feature in ten minutes but cannot tell you why it works, where it breaks, or what it silently assumes has learned the least valuable half of the job. The onboarding target has moved from production to judgment, and most teams have not moved with it.
The reason is specific. A junior who accepts AI output they cannot evaluate never builds the judgment that separates an engineer from an autocomplete operator. Addy Osmani, who works on developer tooling at Google, calls the failure mode "house of cards code": output that looks complete but collapses under real-world pressure, produced by juniors who accept incorrect or outdated solutions, miss security and performance considerations, struggle to debug the generated code, and build fragile systems they do not fully understand. Senior engineers using the same tools avoid this because they shape and constrain the output with experience the junior has not accumulated yet. The tool is identical; the outcome inverts based on judgment the junior is still missing.
Sources: Addy Osmani: The 70% Problem, Hard Truths About AI-Assisted Coding
This argument points somewhere commercial, so read it with that in mind: we build TLM Forge, a process layer that gates AI-written changes before they ship. The onboarding claims here stand on their own and do not depend on the product. The one product section near the end is labeled, and you can take the playbook without it.
Why "just ship faster" breaks juniors specifically
The instinct to hand a junior an AI tool and measure their output by velocity misreads what is happening cognitively. Human-factors research on automation is decades old and consistent: when a person supervises an automated system that is usually right, they drift into automation complacency and automation bias, accepting the system's output and missing its errors. The uncomfortable finding is that this drift shows up in experts as much as novices, and cannot be trained or instructed away with simple practice. A junior has all of the same susceptibility plus none of the pattern library that occasionally makes a senior pause on a wrong answer.
Sources: Parasuraman & Manzey, Complacency and Bias in Human Use of Automation (Human Factors, 2010)
The team-level signal matches the cognitive one. For two years running, Google's DORA research has found that rising AI adoption correlates with worse software delivery stability, even as it raises individual productivity and satisfaction. The report's own reading is that AI makes it easy to produce more code in larger batches, and that the fundamentals it strains against, small batch sizes and strong testing, are exactly what keep delivery healthy. A junior optimizing for how much the AI helps them ship is optimizing against the metric that actually predicts whether the team stays stable.
Sources: DORA, Accelerate State of DevOps Report 2024
The danger is not that a junior uses AI. It is that AI lets a junior produce correct-looking code faster than they can build the judgment to know whether it is actually correct. Speed without verification does not accelerate learning. It defers the learning until an incident forces it.
The onboarding goal flips from generation to judgment
Before AI, a junior demonstrated growth by writing more of the code themselves. That signal is now cheap and misleading, because the AI writes the code and the junior's name is on the commit. The growth signal that still means something is the ability to interrogate a change, their own or the machine's, and answer the questions a reviewer would ask before the reviewer asks them. Onboarding should be built to produce that skill on purpose, not hope it emerges as a side effect of shipping.
Concretely, the judgment you are trying to install looks like this:
- Reading a diff and explaining what each part does, in their own words, without the AI in the loop.
- Naming the failure modes: what inputs break this, what happens under concurrency, what the error path does.
- Distinguishing a test that proves behavior from a test the AI shaped to pass against its own implementation.
- Recognizing the surfaces where a plausible answer is dangerous: auth, money, migrations, data deletion, permissions.
- Knowing when the AI is confidently wrong, and having somewhere to check rather than something to trust.
A concrete onboarding playbook
Rule one: explain before you merge
Make the junior explain every AI-generated change in their own words before it merges, verbally or in the pull request description. Not "the AI added rate limiting," but what algorithm, why that data structure, what it does when the limit is hit, and what it assumes about the caller. The moment a junior cannot explain a line, that line is a liability regardless of whether the tests pass. This single rule does more than any lecture, because it converts passive acceptance into active reconstruction, and reconstruction is where understanding forms. It also surfaces the house-of-cards changes early, while they are three lines in review instead of a page in an incident timeline.
Rule two: test the AI's code, do not trust the AI's tests
Teach the junior that an AI-written test suite is a starting point, not evidence. Agents frequently write tests shaped to the implementation they already produced, so the suite passes without proving the behavior anyone actually wanted. The onboarding drill is to have the junior write at least one test the AI did not, targeting a boundary or failure case the generated tests skipped, and to break the code on purpose to confirm the tests catch it. A junior who has watched a green suite stay green while the feature is obviously broken learns, permanently, that green is not the same as correct. Testing AI-generated code goes deeper on why the passing suite is the weakest signal in the stack.
Rule three: use the AI as a tutor, not a vending machine
The most valuable use of AI for a junior is learning concepts, not receiving answers. A vending-machine prompt is "write the auth middleware." A tutor prompt is "explain three ways to implement this, the tradeoffs of each, and which one fits a service at our scale, then let me choose." The first produces code the junior cannot defend. The second produces understanding the junior can reuse when the AI is not there. Onboarding should explicitly reward the second pattern, because a junior who uses AI to understand faster compounds, while a junior who uses it to avoid understanding stalls the day the problem exceeds the model's training.
Rule four: pair every AI diff with mandatory verification
Verification cannot be a value the team hopes juniors absorb. It has to be a step they cannot skip. Attach a short, explicit checklist to every AI-assisted change and make it a merge requirement: did you read every line, do you understand every line, did you run it, did you test the failure paths, did you check the dangerous surfaces. A junior forced to walk that list on every change internalizes it within weeks and eventually runs it in their head. A junior who is merely told to "be careful" internalizes nothing measurable. An AI code review checklist gives a concrete starting list you can adapt into a merge gate.
Have juniors review AI-generated pull requests, not only write them. Reviewing someone else's (or the machine's) code with the reviewer's mandate to find what is wrong builds judgment faster than authoring, because it removes the authorship bias that makes people defend their own diffs. A junior who spends a rotation reviewing agent output learns the failure patterns as patterns, not as one-off surprises.
Teach fundamentals through review, not just generation
The old worry was that juniors leaning on AI would never learn the fundamentals. The fix is not to ban the tool, it is to move the teaching from the generation step to the review step. When a junior reviews a change and a senior asks "what happens if this list is empty, why is this query not indexed, what does this do to the existing sessions," the fundamentals get taught exactly when they are load-bearing. Review is where a senior's tacit knowledge becomes transferable, and AI has made review the center of the job rather than a chore at the end of it. Onboarding that treats review as the main event, not the afterthought, produces engineers who can evaluate any code, from any source, including code the next model generates.
Review only teaches when its conclusions persist. A decision made in one review ("we do not call the payment API from the client, ever") is worthless to a junior if it evaporates by the next session and they rediscover the same landmine. A private, persistent memory layer such as MemX keeps those review decisions and the reasoning behind them durable across sessions, so a junior builds on settled judgment instead of relearning it, and so the AI they prompt starts from what the team already decided rather than a blank slate.
| Onboarding element | Pre-AI default | AI-era version |
|---|---|---|
| Primary skill taught | Writing code from scratch | Reading, verifying, and explaining code from any source |
| Growth signal | How much the junior wrote themselves | How well they can interrogate a change they did not write |
| Where fundamentals are taught | While writing the first implementations | While reviewing diffs, when the concept is load-bearing |
| Role of the tool | Autocomplete and documentation lookup | A tutor for concepts, gated by mandatory verification |
| Definition of done | It compiles and the tests pass | The junior can explain, defend, and has verified it |
When to keep the AI out of a junior's hands
Some work should be done without AI on purpose, early on. The first time a junior touches a core data model, an auth flow, or a concurrency primitive, having them build it by hand, slowly, is worth more than a fast generated version they cannot reason about. The goal is not productivity on that task, it is the mental model that lets them evaluate every AI-generated version of it later. A junior who has hand-written a race condition and debugged it will spot the AI reintroducing one; a junior who has only ever accepted the generated version will not. When not to use AI coding covers the categories where the generated path costs more than it saves, and several of them double as deliberate teaching moments.
Make verification a gate, not a hope
Everything above depends on one fragile assumption: that "did you actually verify this?" gets asked every time, by a senior with the attention to ask it. That does not survive contact with a busy team. The reliable version turns the question into a step the change cannot bypass, which is the gap TLM Forge is built for. A spec audit forces the junior to state what the change is supposed to do before any code exists, so review has something concrete to check against. Independent review agents that did not write the diff examine it for the failure modes a tired human skims past. Phase-gated TDD makes tests a precondition rather than a courtesy. And an adversarial convergence gate blocks the merge until critical issues reach zero instead of until CI turns green. None of it replaces a junior's judgment. It makes the demand for verification structural, so the junior builds the habit against a wall that does not get tired.
AI is not bad for juniors, and keeping them off it would leave them unemployable in a field that has already changed. The claim is narrower: the tool amplifies whatever judgment the junior brings, and a junior brings the least, so onboarding has to install the judgment deliberately rather than assume it will arrive. Teams that rebuild onboarding around review, explanation, and enforced verification get juniors who grow faster than the pre-AI baseline. Teams that hand over the tool and measure velocity get house-of-cards code with a junior's name on it and no one who can explain it.
Frequently asked questions
01Will AI coding tools stop junior developers from learning to code?
Only if onboarding stays unchanged. The risk is real: juniors who accept AI output they cannot evaluate skip the judgment-building that matters. The fix is to move teaching from writing code to reviewing and verifying it, and to require juniors to explain every AI-generated change before it merges.
02How should a junior engineer use AI without becoming dependent on it?
Use it as a tutor, not a vending machine. Ask it to explain approaches and tradeoffs so you understand the choice, rather than to hand you code you cannot defend. Pair every generated change with mandatory verification: read every line, run it, and test the failure paths yourself.
03Should juniors be allowed to use AI coding assistants at all?
Yes, with structure. Banning the tool leaves juniors unprepared for a field that has already shifted. The productive setup lets them use AI while requiring they explain, test, and verify each change, and reserves a few foundational tasks (auth, data models, concurrency) for hand-building to grow the mental models.
04What should I look for when reviewing a junior's AI-generated code?
Whether they can explain every line in their own words, whether the tests prove behavior or just match the implementation, and whether the dangerous surfaces (auth, payments, migrations, deletions, permissions) got real scrutiny. If the junior cannot defend a line, treat that line as unreviewed regardless of a green suite.
05Does AI actually make software teams ship worse code?
It can. Google's DORA research has found for two years that rising AI adoption correlates with lower software delivery stability, largely because AI makes it easy to ship larger, less-reviewed batches. The mitigation is unchanged fundamentals: small changes, strong tests, and real verification before merge.