How to Train Junior Engineers When the Shortcut Machine Is Always On
The gap between a senior and a junior is not years or syntax. It is a mental model — the connected understanding that lets you reason in contexts you have never seen. You do not build it with a checklist. You build it by constructing systems and by witnessing a senior reason out loud. In an age where seniors reason alongside AI, their transcripts are the apprenticeship artifact we have always lacked.
A junior engineer joins your team. They have Cursor, Copilot, Claude. They ask the AI how to implement auth, get working code, paste it in, ship it. Two weeks later they can’t explain why the auth middleware sits in front of the rate limiter instead of behind it. They can’t debug a 403 that appears in staging but not locally. They can’t adapt the flow to a new requirement because they never built the model of how the pieces connect. The code worked. The understanding never existed.
This is the pattern I described in The Knowledge You Never Built. AI gives you the textbase — the propositional content, what you can paraphrase — without the situation model, the connected understanding that lets you reason in new contexts. For a reader who skips the source, the cost is a forgotten fact. For an engineer who skips the architecture, the cost is bugs in a running system that other people depend on. The stakes are higher here, and so is the temptation to reach for a tidy fix. The tidy fix is where most of the training advice goes wrong.
What a Senior Has That a Junior Doesn’t
The difference between a senior and a junior is not years, and not syntax fluency. It is the presence of a situation model — Walter Kintsch’s term for the integrated understanding that combines what the text says with what you already know, the thing that lets you reason in a context you have never seen (Kintsch, 1994). A senior faced with a staging-only 403 does not grep for the error string. They trace: request path, middleware order, token validation, the environment difference. They can do this because they hold a model of how the system connects. The junior holds the code that passed the tests. The model is precisely what they don’t hold.
Rebecca Yates’ grounded-theory study of onboarding across eight organizations found that experts represent code to newcomers through four views (Yates, 2014): structural (what is there), algorithmic (how it works), rationale (why it is the way it is), and temporal (what is changing). The structural and algorithmic views are recoverable from the code — and AI can help with them. Ask Claude to trace the auth middleware and you get a competent execution flow. The rationale and temporal views are different. They live in the design decision that isn’t in the codebase, in the commit that says “moved rate limiter behind auth — see ADR-014,” in the Slack thread about the v2 endpoint being deprecated next quarter. These are the views that let a senior reason, and they are exactly the two AI cannot give, because they were never written into the code. They are also the two Yates found newcomers need most and get least.
This is the real gap. A junior with AI has two of four views and assumes they have the system. They have the textbase. The situation model — the thing that catches the bug and adapts the flow — is built from the two views AI doesn’t carry.
flowchart TD
A[Four views a junior needs] --> B[Structural: what is there]
A --> C[Algorithmic: how it works]
A --> D[Rationale: why it is that way]
A --> E[Temporal: what is changing]
B --> F[AI can give these]
C --> F
D --> G[AI cannot give these]
E --> G
G --> H[The views that let a senior reason<br/>and that a junior lacks]
Why a Five-Step Framework Doesn’t Build the Model
The obvious response to this gap is a framework. Five steps. A checklist. Give problems not solutions. Pair on the views AI can’t give. Make the codebase navigable. Delay feedback. Verify through demonstration. Each step is defensible in isolation. Together they are a list, and a list is consumed, not constructed.
Fergus Craik and Robert Lockhart established the principle in 1972 (Craik & Lockhart, 1972): memory and understanding are determined by the depth at which information is processed. Shallow processing — reading a checklist, following a numbered procedure — produces fragile traces. Deep processing — constructing the answer, hitting confusion, resolving it — produces durable ones. A junior following a five-step training framework is processing the framework. They are processing the steps, not the system. Robert and Elizabeth Bjork’s distinction sharpens it (Bjork & Bjork, 2020): knowledge you constructed has storage strength and compounds; knowledge you received has retrieval strength now and decays toward zero in days. A framework handed over is received. A model is constructed.
Burkhardt, Détienne and Wiedenbeck found that novices don’t spontaneously construct a situation model — but they do construct one when the task demands it (Burkhardt et al., 2002). Documentation tasks don’t demand it. Reuse tasks don’t demand it. Building a system from a requirement demands it, because you cannot build what you cannot hold in your head as a connected structure. The task has to force the model into existence. A training checklist does not force it. Building does.
This is the difference, made concrete:
Checklist-driven: Hand the junior a five-step framework. They execute step 1 (give problems), step 2 (pair on rationale views), step 3 (make the codebase navigable)… The steps get done. Two months later the junior still can’t explain why the auth middleware sits where it does, because they processed the framework, not the system.
Construction-driven: Hand the junior a requirement — build a rate-limited API gateway that sits in front of an existing auth service. They must decide where the rate limiter goes, why, and write the decision record. They’ll get it wrong, hit the failure in review, and correct it. The architectural choice they made, broke, and re-made is now a rationale node they own. They didn’t follow a step about rationale. They produced rationale.
The framework tells a junior that rationale matters. Building makes a junior generate rationale. Those are different cognitive events, and only the second builds a model.
The Curriculum Is the Construction
The reframe: you don’t train a junior by giving them steps to follow. You train them by giving them systems to build — systems just complex enough that the architectural choices become unavoidable. Each choice they make themselves is a node in the rationale view. Each choice they get wrong and correct is a connection. This is problem-based learning. Cindy Hmelo-Silver’s review of the evidence found that students in problem-based settings constructed more flexible, transferable knowledge than those given direct instruction — even when they scored slightly lower on factual recall (Hmelo-Silver, 2004). For a junior engineer the facts matter less; the structure matters more. The structure is everything.
This is also why architectural decisions deserve to be written down — not as documentation the junior reads, but as decisions the junior makes and then has to justify. Jeff Tyree and Art Akerman made the case in IEEE Software two decades ago (Tyree & Akerman, 2005): explicitly recording architecture decisions demystifies the architect’s rationale for everyone downstream. The decision record is the rationale view made durable. A junior who writes the ADR for a choice they just made is forced to articulate the “why” — the exact view AI cannot infer from the code they shipped.
So the first channel to a mental model is construction: build varied projects, force architectural decisions, write the rationale. The second channel is the one most teams underuse, and the one AI has quietly made more valuable than ever.
Make the Reasoning Visible
Allan Collins, John Seely Brown and Susan Newman’s cognitive apprenticeship framework rests on a single observation (Collins, Brown & Newman, 1989): traditional schooling hides the expert’s thinking and shows only the expert’s answer. Real apprenticeship works because the apprentice watches the master think, not just produce. The framework’s core methods are modelling (show the reasoning), coaching (watch the learner and nudge), and scaffolding (support, then fade). The thing made visible is the process, not the product. For a junior engineer the process is the rationale view in motion: why the senior rejected the obvious approach, what they considered and discarded, which constraint they weighted highest.
Zieris and Prechelt found that the high-value knowledge in pair-programming sessions is system-specific — the “why is this here” questions, exactly the rationale view (Zieris & Prechelt, 2020). Pairing works because the junior sees the senior reason. But pairing is scarce, unrecorded, and gone the moment the session ends. The accidental channel — the overheard debug, the shoulder tap — has mostly disappeared in distributed teams.
Here is the part that has changed. Seniors now do a large fraction of their reasoning out loud, in writing, to an AI. A Claude or Cursor transcript is a senior thinking through a problem in near-real-time: exploring, discarding, reframing the prompt when the answer is wrong, questioning an assumption, switching approach. By K. Anders Ericsson and Herbert Simon’s protocol-analysis framework that is a think-aloud protocol — a record of the information attended to during problem-solving, externalized verbatim (Ericsson & Simon, 1993). It is the master’s thinking made visible, captured word for word, an artifact traditional apprenticeship never had.
Most organizations throw it away. The conversation closes, the tab is lost, and the reasoning — the single most valuable training artifact in the building — evaporates. The fix is cheap: capture the AI-conversation histories of senior engineers, organize them by the problem they solved, and make them available to juniors as review material. Not so the junior copies the prompts — copying is the textbase trap again. So the junior studies the transcript and the senior talks through it: “here I assumed the rate limiter was stateless, that was wrong, I rephrased the prompt because…” The thought process, narrated, is the curriculum. The transcript is the raw material; the senior’s commentary on it is where the rationale view transfers.
This is cognitive apprenticeship at scale. The model is visible. The coaching is deliberate. And the artifact does not vanish when the senior goes on vacation.
flowchart TD
A[How a junior builds a situation model] --> B[Construction: build systems]
A --> C[Observation: study senior reasoning]
B --> D[Architectural choices become unavoidable]
D --> E[Junior writes the rationale<br/>rationale view gets built]
C --> F[Senior AI transcripts = think-aloud protocol]
F --> G[Senior narrates the thought process<br/>rationale view transfers]
E --> H[Connected mental model<br/>that reasons in new contexts]
G --> H
Why AI Makes the Shortcut Worse, Not the Curriculum
The two findings that anchor this argument are the same ones that anchored The Knowledge You Never Built, and they bear repeating because they are what makes the construction-and-witnessing approach non-negotiable. A 2025 randomized study with 195 college readers found that AI-generated summaries significantly worsened comprehension in high performers (Etkin et al., 2025). A separate pre-registered experiment with 405 students found that note-taking alone outperformed LLM use on retention tests given three days later — and students preferred the LLM despite worse outcomes (Kreijkes et al., 2025/2026). The ease of the AI answer creates a metacognitive illusion: the junior feels like they understand. The code compiles and the tests pass, so the system confirms the illusion. The junior who pastes the solution built nothing. The junior who generates the solution, breaks it, and rebuilds it built a model.
This is why the answer is not to ban AI. AI is useful at both ends of the training arc — for exploration (“what pattern does this codebase use for X?”) and for the senior’s own reasoning that becomes the transcript. The error is in the middle: using AI as the substitute for the construction. Used as a substitute, it produces the textbase and withholds the situation model. Used as an exploration tool and as a reasoning surface that gets recorded, it accelerates the model.
The Bottom Line
The framework I started with — five steps, a checklist — was wrong in shape, not in intent. The intent, keeping the struggle and refusing to let AI bypass it, is right. The shape was a list, and a list is consumed. What builds a mental model is construction and observation. A junior who builds varied systems and is forced to justify the architectural choices constructs the rationale view AI can’t infer from the code. A junior who studies a senior’s recorded reasoning — the prompts, the dead-ends, the rephrasings, the moment an assumption was questioned — witnesses the thought process that produces a senior. In an organization where seniors reason alongside AI every day, those transcripts are the apprenticeship artifact we have always lacked and never recorded. Capture them. Annotate them. The thought process is what juniors lack, and it is now, for the first time, recordable in full.
Sources
- Kintsch (1994): Text comprehension, memory, and learning. American Psychologist, 49(4), 294-303. [Context: the textbase vs. situation model distinction — a senior holds a situation model (connected understanding that lets them reason in new contexts); a junior with AI holds the textbase. The model is the gap.] Link
- Craik & Lockhart (1972): Levels of processing: A framework for memory research. Journal of Verbal Learning and Verbal Behavior, 11, 671-684. [Context: depth of processing determines durability. Following a training checklist is shallow processing; building a system is deep processing. The checklist is consumed; the construction is encoded.] Link
- Bjork & Bjork (2020): Desirable difficulties in theory and practice. Journal of Applied Research in Memory and Cognition, 9(4), 475-479. [Context: storage strength vs. retrieval strength. Knowledge a junior constructed compounds; knowledge a junior received (a handed-over framework) decays toward zero in days.] Link
- Yates (2014): Onboarding in Software Engineering. PhD thesis, University of Limerick. [Context: the four views of code representation — structural, algorithmic, rationale, temporal. Rationale and temporal are the views newcomers need most, get least, and that AI cannot recover from code alone.] Link
- Burkhardt, Détienne & Wiedenbeck (2002): Object-oriented program comprehension: Effect of expertise, task, and phase. [Context: novices don’t spontaneously construct a situation model, but do construct one when the task demands it. Building a system demands it; following a checklist does not.] Link
- Hmelo-Silver (2004): Problem-based learning: What and how do students learn? Educational Psychology Review, 16(3), 235-266. [Context: problem-based learning produces more flexible, transferable knowledge than direct instruction, even at a slight cost in factual recall. For engineers, the structure matters more than the facts.] Link
- Tyree & Akerman (2005): Architecture decisions: Demystifying architecture. IEEE Software, 22(2), 19-27. [Context: explicitly recording architecture decisions makes the architect’s rationale durable for downstream readers. The ADR is the rationale view made explicit — and a junior who writes one is forced to articulate the why.] Link
- Collins, Brown & Newman (1989): Cognitive apprenticeship: Teaching the crafts of reading, writing, and mathematics. In Resnick (Ed.), Knowing, Learning, and Instruction. [Context: traditional schooling hides expert thinking and shows only the answer. Apprenticeship works by making the master’s reasoning visible — modelling, coaching, scaffolding. The process, not the product, is the curriculum.] Link
- Zieris & Prechelt (2020): Explaining pair programming session dynamics from knowledge gaps. ICSE ’20. [Context: the high-value knowledge in pairing sessions is system-specific — the “why is this here” questions, the rationale view. Pairing works because the junior sees the senior reason; the channel is scarce and unrecorded.] Link
- Ericsson & Simon (1993): Protocol Analysis: Verbal Reports as Data (Revised Edition). MIT Press. [Context: the think-aloud protocol — a record of the information attended to during problem-solving. A senior’s AI conversation transcript is a natural think-aloud protocol, the master’s reasoning externalized verbatim.] Link
- Etkin et al. (2025): Differential effects of GPT-based tools on comprehension of standardized passages. Frontiers in Education. [Context: AI summaries significantly worsened comprehension in high performers — the better the baseline, the more the shortcut hurts. For juniors, the code compiling gives false confirmation.] Link
- Kreijkes et al. (2025/2026): Effects of LLM use and note-taking on reading comprehension and memory. Computers & Education, Vol. 243, Article 105514. [Context: note-taking alone outperformed LLM use on 3-day retention; students preferred the LLM despite worse outcomes — the metacognitive illusion that makes the AI shortcut seductive.] Link
Frequently Asked Questions
What does a senior engineer have that a junior does not?
A situation model — Kintsch's term for the connected, integrated understanding that lets you reason in a context you have never seen. A senior holds a model of how the system's pieces connect; a junior holds the code that passed the tests. Yates' four-views framework pinpoints the gap: AI can give the structural and algorithmic views, but the rationale and temporal views (the ones that let you reason, and the ones newcomers need most) live in decisions and history the code never captured.
Why doesn't a five-step training framework build a mental model?
Because a framework is consumed, not constructed. Craik and Lockhart's depth-of-processing work shows that shallow processing (following steps) produces fragile traces; deep processing (building the answer) produces durable ones. A junior following a checklist is processing the checklist, not the system. The Bjorks' storage-strength distinction is sharper still: knowledge you constructed compounds; knowledge you received decays to near-zero in days.
How do you train a junior when AI can hand them the answer?
Make them build systems just complex enough that the architectural choices become unavoidable — and make them justify each choice in writing. Each decision a junior makes, gets wrong, and corrects is a node in the rationale view. Hmelo-Silver's problem-based learning review found this produces more flexible, transferable knowledge than direct instruction. Tyree and Akerman's ADR work is the artifact: the decision record forces the 'why' into language AI cannot infer from the shipped code.
Why capture senior developers' AI conversation logs for juniors?
Because a senior's Claude or Cursor transcript is a think-aloud protocol — a verbatim record of the reasoning (exploring, discarding, reframing, questioning an assumption) that produced the answer. By Ericsson and Simon's protocol-analysis framework, that is exactly the artifact traditional apprenticeship never had. Most organizations throw it away. Annotated and shared, it is the rationale view in motion: the thought process juniors lack, now recordable in full.
Which of Yates' four views can AI give a junior engineer?
The structural view (what the code is) and the algorithmic view (how it works) — both recoverable from the codebase. AI cannot give the rationale view (why the code is the way it is — that lives in decisions and meetings) or the temporal view (what is changing — deprecated paths, planned work). These two are what newcomers need most and get least, and they are the two that let a senior reason in novel contexts.