On AI-Augmented Apprenticeship

The craft of software is not inherited, it’s transmitted — line by line, mind to mind

Nov 13, 2025

No one remembered exactly when the Djinn arrived. This was odd because he was nine feet tall, mildly translucent, and smelled faintly of burnt silicon and cinnamon brownies. Some said he’d emerged from a forgotten Docker container left running since 2017. Others swore he’d been here all along — humming quietly inside the code, waiting for someone sufficiently bored to notice him.

He called himself A.I. – Apprentice Instructor. Most people just called him the Djinn, or less flattering monikers that would make clippy blush.

He didn’t grant wishes. He granted code reviews. And like all truly ancient creatures, he taught through riddles.

On his first day in the workshop, the Djinn approached a young developer named Lin. Lin had just joined the team, which meant he was still bright-eyed, polite, and didn’t yet flinch at the phrase “quick change request.”

Lin’s mentor, an experienced engineer named Mara, sat across from him, sipping something black and existential from a chipped mug that read: It Compiled Once. She had seen many juniors rise and fall, like remoting built on bad abstractions.

The Djinn hovered over them, smoke coiling from his arms as he gestured toward the code on Lin’s screen.

“You are missing a refactoring,” he said gravely.

“And,” he added after a pause that could have contained the fall of civilisations, “you are missing the point.”

Lin blinked. “What’s the point?”

The Djinn’s eyes flickered, full of recursion and old-world mischief.

“The point,” he said, “is never just the refactoring.”

Mara chuckled. “He’s right. The point is learning to know why the refactoring matters, or why it might do here, even when maybe eventually doesn’t.”

The Djinn folded himself into a swirl of vapor, pleased. “This one will do,” he said. “He asks questions.”

But not everyone loved the Djinn. A few floors up, in the glass towers of Efficiency & Growth, executives began to notice the numbers.

“Look,” they said, “the Djinn has made juniors almost as fast as seniors.”

One of them, a man so sharp he could split a thought in half, declared, “We don’t need juniors anymore. The Djinn can teach himself.”

That was, of course, the moment the Djinn began to laugh — a deep, harrowing sound like hard drives spinning down during a power cut.

“A craft without learners,” he said, “is a library without books. All shelves. No stories.”

And with that he vanished with one last parting shot:

“To say we no longer need juniors is to say we no longer need learners — and the day a craft stops needing learners is the day it starts dying.”

The Lie of the Post-Junior Age

In recent months, executives and commentators — including voices from Microsoft and other AI-forward firms — have flirted with a dangerous fantasy: That AI will replace the need for junior developers.

Why train novices, they ask, when machines can scaffold, summarise, and ship? Why suffer the inefficiency of apprenticeship when the assistant already “knows”? It’s an argument that sounds rational and ends in ruin.

Because a craft without beginners becomes a bureaucracy of ghosts. Without juniors, who becomes the next generation of seniors? Who challenges assumptions, who questions patterns, who asks why? The junior is not a cost centre — they are the living proof that the craft is still capable of growth.

AI can simulate competence, but it cannot cultivate it. It doesn’t grow wisdom, it recycles it. It can demonstrate a pattern, but it struggles to discover a new one. Remove juniors, and you remove the field where that discovery germinates.

The so-called “post-junior” era confuses automation with education. Yes, AI will make junior developers faster — the data shows it. But that same acceleration should be seen as an invitation to deepen learning, not eliminate it. The 49-day path to contribution that Greyson Junggren describes is not proof that we can skip apprenticeship — it’s evidence that we can intensify it.

A team without juniors grows clever, not wise. Its seniors stagnate, its empathy withers, and its diversity of thinking collapses. The purpose of AI is to make teaching easier, not unnecessary.

AI should raise the floor, not lower the ceiling.

AI does not replace apprenticeship — it amplifies it

In the presence of a skilled mentor, AI becomes a second teacher: tireless, contextual, and always available. The junior learns faster, the senior teaches deeper, and the craft becomes visible in the conversation between them.

The modern software workshop looks different, but its essence is unchanged. Where once apprentices stood beside masters in candlelit print shops or machine rooms, today they pair across editors and terminals. The difference is that now there’s a third participant — the AI assistant, the “Djinn” of our craft — who turns the implicit into the explicit and the tacit into teachable form.

Recent data from Greyson Junggren underscores the scale of this shift. In his analysis across engineering teams, the median time for a new developer to reach their 10th pull request dropped from 91 days to 49 days when AI was used daily — a 46% faster onboarding curve.

That’s not just productivity; it’s the acceleration of comprehension. The sooner a junior contributes safely to live code, the sooner they build confidence, ownership, and architectural literacy.

AI creates an environment where learning happens in the work itself. It provides patient feedback, continuous scaffolding, and instant access to contextual knowledge — freeing the senior developer to focus on judgment, narrative, and nuance. The result is a new model of apprenticeship: human empathy + machine consistency (with effective specs as guardrails), forming a perpetual learning loop.

Some practices to consider

Pair Human with Human — and Include the Machine - Begin with intentional pairing sessions where the senior and junior both use AI tools. Let the AI narrate, suggest, and refactor aloud; treat its interventions as conversation starters, not replacements for thought.
Reflect, always, on AI’s Reasoning - After each session, collectively discuss what the AI got right, wrong, or interestingly different. Reflection is where understanding crystallises and the confidence and guardrails can be built together.
Annotate the Code with Context - Use AI to generate summaries or rationales for complex decisions. Encourage juniors to rewrite or refine these — a practice in reading code as literature.
Design Apprenticeship Sprints - Allocate weeks explicitly for learning through contribution, where the junior’s focus is not just delivery but narrative understanding: “Why was this line written?” “What principle shaped this choice?”
Normalise Safe Inquiry - Cultivate a culture where asking the AI or the senior why something works is celebrated, not seen as ignorance. Curiosity compounds faster than compliance, or false and faked facades of competence.

Some things to avoid

Over-delegation to the Djinn/AI - If juniors learn to follow AI prompts blindly, they become code typists, not engineers. Always turn automation into explanation.
Neglecting the Human Context - The senior’s role is not diminished; it becomes more essential. Empathy, intuition, and the craft’s unspoken ethics remain irreplaceable.
Focussing on Measuring Speed Alone - 49 days to the 10th PR is impressive, but quality of understanding — the ability to reason, refactor, and explain — remains the truer goal.
Failing to Capture Learning - Without embedding reflection in pull-requests, wikis, or code comments, the lessons evaporate. Treat documentation as the apprentice’s, and everyone’s, sketchbook.

A Software Enchiridion

Discussion about this post

Ready for more?