The fastest way to finish a hard problem is to ask an AI for the answer. Unfortunately, that is also a good way to end up with code that works and no idea why. A solved problem and a learned problem can look identical for about five minutes; the difference appears later, in front of a blank page, when the previous solution is gone. Most AI products optimize for time to an answer. A tutor should care about something slower and more valuable: the time it takes before the student can proceed without one.
The student is the problem
In a conversation with Dwarkesh Patel, Andrej Karpathy talks about learning Korean online, in a class, and finally with a one-on-one tutor. What impressed him was not simply her knowledge of Korean; books and language models have plenty of that. It was how quickly she figured out what he knew, where his understanding was shaky, and what would be just hard enough to move him forward.
That is a different product from a chatbot with good answers. An answer machine treats the question as the unit of work, whereas a tutor treats the student's understanding as the unit of work. The question may expose a missing fact, a bad analogy, or a prerequisite the student skipped three weeks ago; noticing which one is the real work.
Suppose someone asks why a small program keeps calling itself forever. The code needs a rule that says when to stop. Supplying that rule will fix the immediate problem, but it says nothing about whether the person can follow what the program is doing or spot the same mistake next time. A better first response might be a question: what gets smaller each time this function calls itself?
Karpathy is careful here because current chatbots do not reliably form the precise picture of a student that his tutor built after a short conversation. Refusing to answer is not enough; a bot that repeats "try again" while you remain stuck is not teaching, it is simply withholding information.
Help can spoil the problem
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 forces the small decisions back into view, including what the program needs to remember, what has to happen first, and what must remain true as the program runs. Those are often the exact places where apparent understanding falls apart.
AI is unusually good at removing that friction because it can provide the implementation, the tests, and the explanation as one polished bundle. That is useful when the goal is shipping something, but during learning the same fluency can hide the line between understanding a decision and merely accepting it.
Forced struggle gets silly fast, though, and there is no educational prize for spending forty minutes rediscovering an obscure software setting. A useful tutor needs an escape hatch. It might ask for a prediction, wait for a small attempt, offer one hint, and then reveal the missing piece if the student is still stuck. Sometimes nobody asked for a lesson at all; the build simply has to be fixed before a meeting. Tutor mode should therefore make its bargain explicit: this may take longer now so that you need less help later.
This is easy enough to test without pretending that one person's result settles anything. Pick 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, then return forty-eight hours later without AI and try to rebuild each result from a blank page. Explain why the major pieces exist and attempt a version in which one important condition has changed.
My guess is that unrestricted AI wins the first session while hints-only help does better on the delayed test, but it is only a guess. The hints may be badly calibrated, the unrestricted session may produce equal retention in less time, and some of the friction we call educational may simply be slow. The useful result is less impressive than a perfect answer: two days later, can the student still build the thing?