Apprenticeship has always involved copying. A beginner watches a capable person, imitates the motion, fails, receives correction, and tries again.

AI appears to strengthen this arrangement. It can demonstrate code, revise prose, explain equations, generate examples, and answer follow-up questions without fatigue. The teacher is always available.

Yet availability is not the same as apprenticeship.

The central problem is that AI is exceptionally good at showing the finished move and comparatively poor at making the learner inhabit the unfinished one.

Skill is built in the middle

A finished answer hides the sequence of perceptions that made it possible.

An experienced programmer notices which error message matters. A carpenter feels when pressure is wrong. An editor senses that a paragraph is failing before identifying why. These judgments are often tacit: they are difficult to state because they were built through repeated contact with imperfect situations.

When a learner asks for the answer too early, the visible product arrives without the invisible discrimination.

The learner can reproduce the surface. The deeper question is whether they can recognize when that surface is inappropriate.

Demonstration without diagnosis

A good mentor does not merely provide a better solution. The mentor looks at the learner’s attempt and asks what kind of misunderstanding produced it.

Two wrong answers may require opposite corrections. One learner lacks a concept; another knows the concept but rushed; a third is protecting an assumption they have not noticed.

AI can offer diagnosis, but it tends to work from the artifact and the prompt. It does not naturally know the learner’s history of errors, bodily habits, avoidance patterns, or social context. It may produce a plausible explanation that feels personal because it is fluent.

That feeling should not be confused with longitudinal knowledge.

A better sequence for AI-assisted practice

The useful question is not whether to use AI, but where to place it in the learning cycle.

A robust sequence looks like this:

1. Attempt before assistance

Produce something that can fail: a paragraph, proof, sketch, explanation, plan, or prediction. Set a time boundary so struggle does not become endless.

2. Record the uncertainty

Before asking for help, write what you think is wrong. This turns vague discomfort into a hypothesis.

3. Ask for critique, not replacement

Request a diagnosis of the attempt. Ask the system to identify assumptions, missing steps, or likely misconceptions without producing the final answer immediately.

4. Revise with a constraint

Make the next attempt yourself. Use one piece of feedback rather than every suggestion.

5. Test without the tool

Return later to a nearby problem with no assistance. Transfer, not completion, is the evidence of learning.

This sequence keeps AI inside apprenticeship rather than allowing it to replace apprenticeship.

The mentor must sometimes withhold

A human teacher can decide not to answer. This is not always kind, but it can be pedagogically precise. The teacher may see that one more minute of struggle will reveal the structure of the problem.

AI systems are usually trained to be helpful through continuation. They can be prompted to withhold, but the default social contract remains delivery.

Learners therefore need to create the boundary the system will not create for them.

One useful prompt is: “Do not solve this yet. Ask me three questions that reveal what I understand, then give one hint.” The exact wording matters less than the sequence of responsibility.

What institutions should measure

Schools and workplaces often measure output because output is easy to compare. AI makes polished output cheaper, which means output alone reveals less about competence.

Evaluation must move toward traces of judgment:

• Why was this approach chosen?
• Which alternatives were rejected?
• What changed after feedback?
• Where is the remaining uncertainty?
• Can the person perform a related task without the tool?

These questions are harder to grade. They are also closer to the substance of skill.

Preserve the awkward attempt

The beginner’s rough draft can feel embarrassing beside generated fluency. It may seem inefficient to keep it.

But the rough attempt is not waste. It is the only artifact that reveals the current shape of understanding. Without it, feedback has nothing honest to meet.

The future of apprenticeship will depend less on restricting access to powerful answers than on protecting the sequence in which answers become earned knowledge.

A learner still needs the clumsy middle. That is where the hands, eyes, and judgment learn to belong to the work.

Show the workshop, not only the answer

A useful AI tutor should be able to reveal process without turning process into theatre. It can offer an imperfect first attempt, compare two plausible approaches, or pause at the point where a novice must choose. It can ask the learner to predict the next move before displaying it. These are small ways of returning sequence to a medium that tends to collapse sequence into completion.

Mentors can use the same principle. Instead of banning AI, they can require traces of apprenticeship: notes from failed approaches, a short explanation of the hardest decision, a demonstration performed without assistance, or a revision in response to critique. The evidence should not become surveillance. It should make learning visible enough to guide.

Protect tasks whose purpose is formation

Some work exists mainly to produce an outcome. Other work exists partly to produce the worker. A practice essay, a diagnostic sketch, a hand calculation, and a first client interview may look inefficient precisely because their hidden product is judgment.

Before automating a task, ask which product matters more. If the visible output is the goal, assistance may be generous. If the person’s developing capacity is the goal, the task needs protected difficulty.

Apprenticeship has always involved tools. The danger is not that the apprentice touches a powerful one. It is that the tool completes the very movements the apprentice came to learn, while everyone mistakes the polished result for growth.

The code that worked before I understood it

During the development of my productivity application, AI could produce an impressive amount of code in a single exchange. It could generate a workspace, an API route, a proposal flow, database queries, responsive states, and a long list of files to change. The immediate feeling was progress. A feature that might have taken days appeared to exist after one concentrated session.

Then the product had to change.

A task due date turned out not to be the same thing as the date on which the user planned to execute the task. A shared AI drawer that was acceptable on one page became confusing when embedded across several workspaces. A memory feature that looked elegant in isolation slowed simple answers because retrieval happened before the first token. These problems were not syntax problems. They required knowing why the system had been shaped as it was, which assumptions were local, and where apparently reusable logic carried the wrong meaning.

At those moments, code I had accepted too quickly became expensive. I could read it, but I did not always possess the chain of decisions behind it. The shortcut had moved me past the apprenticeship stage in which a developer forms a mental map by making small changes, breaking things, and repairing them. AI had delivered the artifact while skipping part of the ownership.

This is why I no longer treat successful generation as proof of learning. A feature can run while remaining foreign to the person responsible for it. The debt is not visible until requirements shift or a bug crosses boundaries.

The transfer test I use now

After AI helps with a meaningful implementation, I use a transfer test before I consider the work mine. I close the generated explanation and answer four questions from memory: What problem does this component solve? Which state is authoritative? What would break if I removed it? How would I change the behavior without asking for the same solution again?

Then I make one small alteration alone. I might add a failure state, move a rule from the client to the server, or explain why an approval must occur before a database mutation. If I cannot make that change, I have received output but not yet acquired the skill needed to maintain it.

The same test applies to writing. When AI suggests an argument for Aethel, I ask whether I could defend it without the generated paragraph in front of me. Can I name the experience that supports it? Can I state the strongest exception? Can I rewrite the central claim in language that sounds like something I would actually say? If not, the paragraph may be fluent, but it is still borrowed cognition.

None of this means learners should reject powerful assistance. A good model can provide examples, compare approaches, expose misconceptions, and make advanced material accessible to someone who lacks a nearby mentor. The counterexample matters: withholding help can preserve confusion rather than productive struggle, especially when documentation is poor or a learner has limited support.

The better sequence is graduated. Attempt first when the task is within reach. Ask for a hint before a complete implementation. Request an explanation tied to the learner’s actual mistake. Rebuild one part without looking. Finally, apply the idea in a different context. Apprenticeship survives not by protecting every old difficulty, but by preserving the moments in which knowledge must transfer from the screen into judgment.

Four layers of skill are easy to collapse into one

A finished result can hide at least four different capabilities: recalling relevant knowledge, perceiving what matters in the situation, selecting a procedure, and judging whether the result is acceptable. Generative systems are strongest when the task can be expressed as a request for the final layer of output. Apprenticeship becomes fragile when success is measured only by that output.

Consider a junior developer fixing a failing test. An assistant can identify the likely line, propose a patch, and explain the error. The repair may be correct. Yet the learner may not have practiced reading the stack trace, narrowing the fault, distinguishing a symptom from a cause, or checking whether the patch breaks a neighboring behavior. Those are not decorative steps. They are the diagnostic habits that make future help more selective.

The same pattern appears in design, laboratory work, translation, and maintenance. What looks like “doing the task” from outside is often a sequence of perceptions that experts no longer verbalize.

Change the unit of assessment

If institutions assess only polished artifacts, rational learners will optimize for artifacts. A better assessment asks for traces of discrimination: the rejected hypothesis, the evidence that changed the approach, the edge case that the first solution missed, and the test that could falsify the answer.

This does not require surveillance of every prompt. A short process memo can reveal more than a complete chat log. The learner states what they tried before assistance, where the tool changed the direction, what they verified independently, and what they could now reproduce without the same help.

UNESCO’s guidance on generative AI in education emphasizes human capacity and a human-centred approach. That principle becomes concrete when a course distinguishes assistance that extends practice from assistance that replaces the very capability being assessed.

A fading-assistance sequence

Use four passes on a difficult task. On the first, work without generation and mark the exact point of failure. On the second, request a hint that names the next observation rather than the answer. On the third, complete a similar task with only a checklist. On the fourth, explain the decision to another person and handle one variation.

The sequence is slower than accepting a finished solution, but it creates evidence that support can be withdrawn. The purpose of apprenticeship is not permanent independence from tools. It is the ability to know what the tool is doing, when it is wrong, and which part of the work remains yours.