Ask a model to explain Rust lifetimes and you will understand lifetimes for about forty minutes. The explanation is good. It is tailored to your question, it uses your example, it answers the follow-up you were about to ask. Then you sit down to write code and discover you cannot produce a single lifetime annotation without going back.
Nothing went wrong. You experienced comprehension, which is real, and you skipped acquisition, which is the part that costs something. AI tutoring is extremely good at producing the first and quietly removes most of the friction that used to force the second.
Last verified against the linked guides on this site. Version-specific details drift — check the vendor docs before relying on an exact flag or limit.
Why reading explanations until it makes sense trains the wrong thing
The default learning loop is ask, read, nod, ask the next question. It feels efficient because the subjective sense of understanding rises with every answer, and that feeling is exactly the thing being measured incorrectly.
Understanding an explanation is a recognition task. Producing the answer yourself is a retrieval and construction task. They use different capabilities, and only the second one is what you need when the model is not in the room. A loop built entirely from explanations trains recognition and reports it back to you as mastery.
The fix is not to stop asking. It is to make every session end with production instead of comprehension.
By the end you will have
- The distinction between comprehension and acquisition, and why the model erodes the second
- A four-move loop that keeps generation on the correct side of the learning
- The Explain-Predict-Break-Rebuild Loop
- A test that tells you what you actually know, before it matters
- A rule for which topics to learn with AI and which to learn the slow way
Put the model on the question side, not the answer side
The single change that fixes most of this: use the model to generate questions and consequences, not answers.
| Instead of | Ask for |
|---|---|
| "Explain X" | "Ask me five questions about X, hardest last, and do not answer them" |
| "Write the code" | "Give me the function signature and the test. I write the body" |
| "Why did this fail?" | "Give me three candidate causes. I will find which one, then tell me if I am wrong" |
| "Summarize this doc" | "Quiz me on this doc after I read it" |
| "Is this right?" | "Here is my explanation. Find the error in it" |
Each right-hand prompt puts you in the position of producing the answer, with the model grading. This costs more per session and is the entire point, because the cost is the mechanism.
Mechanism dive: why comprehension does not become skill
Learning research has a long-standing distinction between performance during practice and retention afterward, and the two often move in opposite directions. Conditions that make practice feel smooth tend to produce weaker retention. Conditions that introduce difficulty, retrieving from memory instead of rereading, spacing sessions out, mixing problem types, feel worse during the session and produce durable skill.
An AI tutor is a machine for removing exactly those difficulties. It eliminates retrieval, because the answer arrives before you have tried to reconstruct it. It eliminates the search, because you never have to decide which part of the documentation is relevant. It eliminates productive failure, because you rarely sit with a broken mental model long enough for the break to register.
There is a second, sharper effect specific to coding. When you read generated code that works, you build a mental model of what it does. You do not build a model of why the alternatives fail. Debugging draws almost entirely on the second model. That is why people who learned a stack through generation can read their codebase fine and cannot fix it: the reading model is intact and the failure model was never constructed.
So the design goal is not to make learning harder for its own sake. It is to reintroduce the specific difficulties that generation removed, at the specific points where they do the work.
Add the friction back at four points
Predict before running. Before executing any code the model wrote, say out loud what it will output. Then run it. Every mismatch is a hole in your model located precisely, which is the most valuable event in a learning session and the one that generation normally deletes.
Break it deliberately. Take working code and break it in a way you predict will produce a specific error. If the error you get is not the one you predicted, you have found something you did not know. This is the fastest way to build the failure model that debugging requires.
Rebuild from blank. Close everything. Rewrite from memory. Not the same code, the same behavior. What you cannot reproduce is what you did not learn, and the gap is usually not where you expected.
Space and interleave. Come back to it in two days, and mix the topic with an adjacent one. Same-day repetition inflates the feeling of mastery more than the mastery.
The worked example: two weeks on an unfamiliar stack
I have done this both ways on the same kind of task, learning a new backend framework under deadline.
The first time was the default loop: ask, generate, adapt, ship. It worked. Two weeks later a request failed in a way that touched the middleware ordering, and I had no model of middleware ordering at all, because the generated code had always had it right. I had shipped a working feature and learned close to nothing about the system I now owned.
The second time, the rule was that I could ask the model anything except for working code. It could give signatures, tests, error messages, and criticism. I wrote every body. Days one and two were visibly slower and it felt like the wrong trade the entire time. Around day four the ratio inverted, because I stopped needing to ask about things I had already built once. By the end of that project the debugging was mine, which was the actual deliverable, since the feature would have shipped either way.
The cost is front-loaded and the payoff is at the first incident. That timing is why almost nobody chooses it.
Magnet: Explain-Predict-Break-Rebuild Loop
One topic, one session, roughly an hour. Do not skip move three.
## 1. EXPLAIN (10 min): model talks, you take no notes
Prompt: "Explain [topic] with one worked example. Then stop."
Rule: no note-taking. Notes create a false record of understanding.
## 2. PREDICT (15 min): you talk, model grades
Prompt: "Give me 5 short code snippets using [topic]. Do NOT tell me the output."
For each: write your predicted output BEFORE running it. Then run it.
Prompt: "Here are my predictions: [...]. Which are wrong and why?"
Rule: every miss gets written down. Misses are the syllabus.
## 3. BREAK (15 min): you break, you predict the error
Take one working snippet. Change one thing you believe will fail.
Write the exact error you expect BEFORE running it.
Prompt: "I changed X expecting error Y and got Z. What did I misunderstand?"
Rule: 3 breaks minimum. The goal is the gap between expected and actual.
## 4. REBUILD (20 min): blank editor, no model, no docs
Reproduce the behavior from memory. Not the same code, the same result.
When stuck, note WHERE, then look. Do not ask for the whole answer.
Prompt afterwards: "Here is what I wrote from memory. What is wrong or fragile?"
## 5. SCHEDULE
Same topic in 2 days, mixed with the topic before it. Rebuild step only.You should see: a low score on move 2 the first time, often half the predictions wrong on a topic you just finished understanding. That gap between the explanation feeling clear and the predictions being wrong is the measurement this loop exists to produce. If your predictions are all correct on the first pass, the topic was already known and you should move to a harder one.
Failure modes
| Smell | Result | Repair |
|---|---|---|
| Asking for explanations until it clicks | Recognition mistaken for skill | End every session on production, not reading |
| Taking notes during the explanation | A document you own and a skill you do not | No notes in move 1, notes on misses only |
| Running code before predicting | The single highest-signal moment is deleted | Predict first, always, out loud or written |
| Rebuild attempted with the tab still open | Recognition again, wearing a different hat | Blank editor, model closed |
| Only happy paths | Reading model built, failure model absent | Three deliberate breaks per session |
| All sessions on one day | Feels mastered, gone in a week | Space it, interleave the topic before |
| Learning a stack by shipping with generation | You own code you cannot debug | Ban generated bodies while learning |
When not to learn with AI
- You will never maintain it. A one-off script, a throwaway migration. Generate it, ship it, forget it. Learning has a cost and this case does not repay it.
- The topic is safety-critical. Cryptography, auth, financial calculation, anything medical. Confidently wrong explanations are indistinguishable from correct ones until they matter. Use primary sources.
- You are mid-incident. Production is down. This is not the moment for productive difficulty. Fix it, then learn it afterwards, deliberately.
- The material is genuinely new. Bleeding-edge releases have thin training data, so the model interpolates and sounds equally confident doing it. Read the source.
- You need certification-grade correctness. Structured curricula exist for a reason. Use the model as a quizzer alongside them, not instead.
path
Build the loop into how you work
Agent OS Setup wires rules, memory, and verification so the discipline is in the system instead of in your willpower.
The model can make anything understandable in ten minutes. Understanding is not the thing you are trying to acquire.
Your next action: pick the topic you most recently felt you understood from an AI explanation and run the Explain-Predict-Break-Rebuild Loop on it, starting at move 2. Score your predictions honestly. That score, not the feeling from the explanation, is what you know.
Related: Code With AI covers what to do once you know enough to grade the output, and How to Become an AI-Native Developer covers the wider skill shift.
