Ask an AI to solve a hard problem and you may have working code in seconds. That can leave gaps in understanding, which show up later when you have to reproduce the result, change it, or solve a related problem without the previous response.
Model the student's knowledge
In a conversation with Dwarkesh Patel, Andrej Karpathy talks about learning Korean online, in a class, and finally with a one-on-one tutor. Books and language models already contain plenty of Korean knowledge. His tutor's advantage was how quickly she worked out what he knew, where his understanding was shaky, and what would be just hard enough to move him forward.
Most AI products optimize for the current answer. A tutor has to estimate what the student knows before choosing the next step.
Suppose someone asks why a small program keeps calling itself forever. A student who does not know that recursion needs a rule for when to stop is missing a fact, and a direct explanation may be right. If the rule is already there but the student cannot trace when it runs, the problem may be a bad mental model; the tutor could ask what gets smaller each time the function calls itself. Someone who cannot yet follow a single function call may need a smaller exercise before recursion makes sense. Supplying the finished rule without knowing which problem the student has fixes the program but says little about whether they can spot the same mistake next time.
Karpathy is careful here because current chatbots do not reliably construct the detailed student model that his tutor formed after a short conversation. Repeating "try again" without diagnosing the error only withholds information.
Direct answers can reduce practice
Karpathy makes a similar point about nanochat, his small build-it-yourself AI text model: keep his finished code open, but rebuild it yourself rather than copying it. Rebuilding puts the small decisions back in view, including what the program needs to remember, what has to happen first, and what must remain true as it runs. Those are often the exact places where apparent understanding falls apart.
When AI provides the implementation, tests, and explanation together, it speeds up delivery but makes it hard to tell whether the student understood a design decision or merely accepted a plausible account after seeing the finished result.
Unrestricted struggle is not automatically useful. Spending forty minutes rediscovering an obscure software setting may add no transferable knowledge. A tutoring system should increase assistance gradually: ask for a prediction, wait for an attempt, give one targeted hint, then reveal the missing step if progress stops. It should also separate tutoring from task-completion mode. Someone who needs a build fixed before a meeting may not be optimizing for retention.
Compare delayed retention with two small topics from the same domain. Use unrestricted AI for one and give the model a hints-only instruction for the other:
Act as a tutor, not a solver. Ask me to predict or attempt the next step.
If I get stuck, give the smallest useful hint.
Only show the full solution after I have made a real attempt.
Then ask me to rebuild or change it.Give both sessions the same amount of time. Forty-eight hours later, return without AI and try to rebuild each result from a blank page. Explain why the major pieces exist, then change one important condition.
My guess is that unrestricted AI wins the first session and hints-only help does better on the delayed test. The hints could be badly calibrated. Unrestricted help may save time without reducing retention, and some friction we call educational may simply be slow.
Two days later, can the student still build the thing?