The first three years, redrawn

The junior engineer’s first three years had a predictable shape, until they didn’t. The first year was about producing — small features, bug fixes, the boring code that nobody senior wanted to write. The second year was about producing better, faster, with fewer reviews caught and fewer broken builds. By the third year, patterns started to feel obvious instead of laborious, and the work that used to require a senior’s review started to need only a senior’s nod. This is what people meant when they said an engineer learned the craft — not that they read the right books, but that they did the same kind of thing enough times that the patterns settled into reflex.

That curriculum, the implicit one — produce, repeat, internalize — does not work the same way when the model is in the room from day one. The model produces better than a first-year and faster, on the exact tasks that used to build pattern recognition. The junior who uses the tool the way they were taught to use any other tool ends up shipping more code than juniors used to ship and developing less than juniors used to develop. The output looks healthy. The engineer is hollowing.

This is not an argument against juniors using AI. It is an argument that the developmental shape of the first three years has changed, and the conventional approach — let the junior produce, observe their growth — no longer produces the growth it used to. Four habits have to be deliberately reshaped. None of them is intuitive. All of them cost short-term output to build long-term skill.

1. Substrate skipping

Pattern recognition — the senior engineer’s defining capacity — is built by doing similar things many times until the patterns settle into instinct. The senior who can spot a race condition in a paragraph of unfamiliar code is not faster at thinking; they are pattern-matching against thousands of paragraphs they have written themselves. The capacity is not separable from the doing.

When AI does the doing on a junior’s behalf, the output looks the same and the substrate — the accumulated reps that produce instinct — does not form. Call this substrate skipping. The junior produces a clean implementation and ships it. The senior, looking at the output, sees a healthy junior shipping clean code. The junior, six months later, cannot tell why a similar pattern in someone else’s code is suspicious, because they never did the work that would have built the suspicion.

Substrate skipping is invisible because the proxies that used to indicate pattern formation — clean output, fast shipping, low review feedback — are exactly the proxies AI tools amplify regardless of substrate. The first proxy that would surface skipping is harder to read: the junior’s ability to identify problems in code they did not write. It only shows up when the junior is asked to debug or review under uncertainty, which is exactly the kind of work a junior is least often asked to do.

Two habits push back. The first is deliberately doing the boring work unaided — not all of it, not most of it, but a steady fraction of it, on purpose, with the model closed. Whether that is one feature in five, or one debugging session a week, or every Friday afternoon, the form matters less than the consistency. The reps build the substrate. The model cannot build it on the junior’s behalf.

The second is naming the substrate as the goal. Juniors who think their job is to ship are juniors who skip substrate. Juniors who understand that the implicit curriculum is building the capacity to spot patterns later know that their visible output is a side-effect, not the deliverable. The framing changes the day-to-day choices.

2. Reading the code you did not write

Pre-AI, juniors learned by writing. The codebase a junior was joining was mostly written by humans the junior could ask, in a style the junior could absorb by imitation, with intent the code itself carried fairly well. Reading was a supplementary activity, not the primary one.

Post-AI, the calculus inverted. A growing share of any codebase was not written by anyone the junior can ask, in styles that are stylistic rather than intentional, carrying intent that decayed in the writing. Reading has moved from supplementary to central, because the codebase is increasingly the only available teacher.

This would be fine, except that reading code is a developmental skill in its own right — a slow-acquired, hard-to-fake capacity to construct a mental model from text. Most juniors have not yet built it. The conventional move when reading unfamiliar code stalls out is now to ask the model to explain it. The model produces a fluent summary. The junior moves on. The mental model that would have come from working the read out unaided does not form.

The asking-the-model-to-explain reflex has the same shape as substrate skipping, in a different surface: it produces the appearance of comprehension without the build. A junior who has read a thousand functions explained-by-model has read no functions, in the developmental sense. The skill of building intuition about an unfamiliar codebase from the codebase itself does not develop on borrowed comprehension.

The discipline that pushes back is to read first, ask second. When a junior hits unfamiliar code, the first move is to spend ten minutes building their own mental model from what is on the screen — guessing at intent, tracing dependencies, articulating the contract. After ten minutes, ask the model. After fifteen, ask a senior. The ten minutes is where the skill builds. Without them, the junior is renting comprehension instead of growing into it.

3. The senior is still the better mentor

There is a quieter loss that no one names: the junior who asks the model their questions instead of asking a senior gets faster answers and a worse career.

The model is fast, free, and patient. It will explain anything, will not roll its eyes, will not be in a meeting, will not remember that this is the third time the junior has asked. It is, in the narrow sense of answer me right now, a better information source than any human teammate. The trade-off is that it does not teach the junior how to ask.

Asking a senior well is itself a skill. Framing the question precisely so the senior can answer in two sentences instead of twenty. Reading the senior’s body language to know when the question is welcome and when it is interrupting. Building, over time, a working sense of what each senior knows and what they don’t — which becomes a map of the team’s actual knowledge graph. None of those skills develops when the question is sent to a model that responds the same way regardless. Years of soft-skill development are skipped over by juniors who default to the faster path.

The junior who asks the senior also does something the model does not enable: they slot into the team. The fifth time a senior helps a junior with a tricky problem, a working relationship has formed. The senior knows what the junior is good at. The junior knows what the senior cares about. When a hard problem lands later, both know who to pull in. This is not soft texture around the actual work; it shapes what each engineer can do on a five-year horizon, because most engineering careers are decided by who-you-worked-with as much as what-you-shipped.

The discipline here is to prefer the senior at developmental moments, even when the model would be faster. Not at every moment — the model is genuinely useful for the things it is genuinely useful for. At the moments where the answer matters less than the interaction, defaulting to the model is choosing efficiency over development, and most juniors do not yet have the calibration to spot the difference.

4. Day-one calibration

The skill of knowing whether to trust your own output used to develop slowly across a career, with each project teaching the engineer where their own work was reliable and where it wasn’t. Juniors had license to be miscalibrated for years, because their output was small enough that the calibration error was bounded by the size of what they shipped.

Post-AI, that license is gone. The junior is shipping not their own output but the model’s, from day one. The model’s output is confident regardless of whether it is correct, and the junior who has not yet developed evaluation skills has nothing to push back against the confidence. The classical junior failure mode used to be uncertainty about correct output; the new junior failure mode is certainty about incorrect output, which is a much worse failure to have, because uncertainty asks for help and certainty does not.

This is the place where the apprenticeship ladder breaks most quickly if no one notices. A junior who accepts confident-but-wrong output once is fine; a junior who develops the habit of accepting confident-but-wrong output is in trouble, because the habit hides under productive-looking work for a long time before it visibly costs the team. The cost, when it lands, is concentrated in incidents and review failures and the moment a senior realizes the junior cannot evaluate what they have been shipping.

Calibration has to be taught explicitly, early, and as a primary junior skill rather than an emergent senior one. The form is concrete: hand the junior something the model produced, ask them to find what is wrong with it, and watch what they say. Repeat the exercise weekly. The point is to build, by practice, the instinct of evaluating model output before accepting it. The instinct is the skill.

Mentors who do not teach this assume the junior will pick it up by osmosis. They will not. Calibration was never osmotic; it was developmental, and the development used to happen over years of producing-and-being-corrected. The new conditions do not allow for years; the calibration that used to surface in year three has to be present in week six.

Closing

The first three years of being an engineer used to mostly take care of themselves. The work was developmental by accident, because the work was hard and the engineer was junior and the gap between them was the gap that produces growth. AI tools closed part of that gap on the engineer’s behalf, which is good for output and ambiguous for development.

The junior who treats AI as a productivity tool ships more code than juniors used to ship. The junior who treats AI as a production environment in which their own development still has to happen ships somewhat less code, more deliberately, with eyes on the substrate they are accumulating. The first kind of junior is easier to manage in the short run. The second kind of junior is the one who, in three years, becomes someone the team wants to keep.

Most of the responsibility for getting this right does not sit with the junior. It sits with the senior who designs their work, the manager who decides what they are measured on, and the team that decides whether developmental moments count as work or as interruption. But part of it is the junior’s, and the part that is the junior’s is mostly a matter of choosing harder things on purpose when easier things would ship the same output with less of them. The teams that come out of this period with strong seniors are the teams that made room for that choice deliberately, against the pull of the dashboards that reward the alternative.