How to actually learn from AI-generated code

To learn from AI-generated code instead of just shipping it, run every generated block through four steps before it stays in your file:

1. Read it line by line and mark any line you cannot explain.
2. Ask about the marked lines specifically, not about the code as a whole.
3. Change something on purpose and predict what will break before you run it.
4. Delete it and rewrite it from memory. If you cannot, you did not learn it.

That is the protocol. It costs about five extra minutes per block, and it is the difference between accumulating skill and accumulating code you cannot maintain.

The rest of this post is why those four steps in particular, including what the research actually found, which is more interesting than either side of the usual argument.

What the studies found

Two 2023 studies from the same research group are the most directly relevant evidence available, and read together they contradict the comfortable story on both sides.

The controlled experiment. Kazemitabaar and colleagues ran 69 novices aged 10 to 17 through 45 Python tasks, with roughly half given access to OpenAI Codex. Access to the AI increased code-authoring performance substantially: a 1.15 times higher completion rate and 1.8 times higher scores. It did not decrease performance on manual code-modification tasks, where the AI was unavailable. On a post-test a week later, the AI group did slightly better, though not by a statistically significant margin.

So AI access, by itself, did not damage learning. That is worth stating plainly, because a lot of writing on this topic assumes the opposite.

The observational study. The same group looked at how 33 learners actually used the tool across the same 45 tasks, and sorted their behaviour into four patterns:

• AI Single Prompt: ask once for the entire solution.
• AI Step-by-Step: break the problem up and generate each piece.
• Hybrid: mix writing code by hand with generated code.
• Manual: write it yourself.

The finding that matters: the AI Single Prompt approach produced the highest scores on writing code and the lowest scores on modifying it afterwards.

Put both studies together and the conclusion is specific. The question is not whether you use AI. It is whether you prompt for a whole solution or work through a problem in pieces. The first gets you a working answer and leaves you unable to change it. And being unable to change code is not a small gap, it is most of the job.

Why the single prompt fails you

When you read a complete, working solution, it makes sense. Every line is reasonable, the structure is sensible, and you finish reading with a genuine feeling of understanding.

That feeling is not knowledge. Recognising a correct solution and being able to produce one are different abilities, and reading fluently gives you the first while feeling like the second. It is the same reason watching someone parallel park does not teach you to parallel park.

Writing code yourself forces a hundred small decisions: what to name the variable, whether the loop starts at zero, where the condition goes, what happens when the array is empty. Each one is a chance to be wrong and correct yourself, and that correction is where the learning happens. A generated solution has made all hundred decisions already, invisibly.

This is why the single-prompt group could produce and not modify. They had answers, not decisions.

The protocol, in detail

1. Read it line by line, and mark what you cannot explain

Before running anything. Go through the generated code one line at a time and ask "what does this do, and why is it here?"

Be strict. "It sorts the array" is not an explanation of arr.sort((a, b) => a.value - b.value) if you cannot say why the callback subtracts, or what happens without it.

Mark the lines that fail. Usually it is two or three out of twenty, and those two or three are your actual lesson. Everything else you already knew.

2. Ask about the marked lines, not the whole thing

The prompt that teaches is narrow:

"In this line, why is the second argument a function that returns a number rather than a boolean? What would happen if it returned true or false instead?"

The prompt that does not:

"Explain this code."

A broad request gets you a broad summary you will forget, because it answers a question you did not have. A narrow one gets you the specific missing piece, attached to a gap you already noticed, which is the condition under which things stick.

Follow up with "what would break if...". You are looking for the boundaries of the concept, not a restatement of it.

3. Change something and predict the result first

This is the step people skip, and it is the one that converts reading into knowledge.

Pick a line and change it deliberately. Flip a comparison, remove a parameter, change the loop bound, delete the base case. Write down what you expect to happen before you run it.

Then run it.

If you predicted correctly, you understand that line. If you did not, you have found a precise gap, and now you have a specific question worth asking. Either outcome is useful, which is what makes it a good test.

This works because it inverts the exercise. Instead of checking whether the code is right, which the AI already handled, you are checking whether your model of the code is right. That is the thing you are trying to build.

4. Delete it and rewrite it from memory

The explain-back test, done properly.

Close the file. Write the same function again from your own head. Not word for word, but working code that solves the same problem.

Stuck at line three means you did not learn it, and that is fine information to have while it is cheap. Go back, look, close it again, try again. Two rounds of this is worth an hour of rereading.

When it works, you own it. That is the only real proof, and it is why the step is non-negotiable in this list.

The prompts that teach

Same tool, different requests, different outcomes.

The pattern: arrive with an attempt or a specific confusion. Every prompt in the right-hand column requires you to have done something first, which is exactly why they work. The AI fills a gap you have already located instead of preventing you from locating one.

The most underrated of these is the last row. Asking what your code misses gets you the edge cases you did not think of, and thinking about edge cases is a skill you keep.

The warning signs

Four honest self-checks. If more than one is true, tilt toward writing more by hand for a few weeks.

• You cannot explain code you shipped last week. Not the architecture, the actual lines.
• You cannot start a file from empty. The blank editor feels impossible without a prompt.
• Your debugging is "paste the error back in". When that stops working you have nothing else.
• You do not know when the AI is wrong. If you have never caught it producing a function that does not exist, or an approach that is subtly wrong for your case, you are not checking. It happens regularly.

That last one is the serious one. Generated code that looks right and is subtly wrong is the normal case, not the exception, and catching it is a skill built only by knowing the language yourself.

When to just take the answer

Not everything is a learning opportunity, and treating it that way is its own inefficiency.

Take the answer for boilerplate you have written before, config files, regexes for well-known formats, syntax lookups in a language you know, and one-off scripts you will run once and delete.

Work through it for anything using a concept you are currently learning, anything going into a codebase you maintain, anything you will need to debug later, and anything where you cannot tell whether the answer is right.

The dividing line is simple: if you will need to change this later, you need to understand it now. If it is genuinely disposable, be efficient about it.

The one-sentence version

The research points at something narrower than "AI is good for learning" or "AI is bad for learning": prompting once for a complete solution produced the best code and the worst ability to change it.

So do not prompt once for a complete solution. Break the problem into pieces, attempt each one, and use the AI on the specific piece you are stuck on. That is the AI Step-by-Step and Hybrid behaviour, and it is where the speed and the learning coexist.

Practise on code you wrote

The protocol needs something to run against, and it works best on a problem you have already attempted, because then you have predictions to be wrong about.

Devpuff courses run everything in the browser, and Ask Puff is built for the step-2 pattern above: it explains what a line does and why an approach fails, without handing over the solution to the exercise you are working on. That constraint is deliberate, and it is the same one this post has been arguing for.

JavaScript Basics is a reasonable place to run the four steps for the first time, on problems small enough that rewriting from memory takes two minutes rather than twenty.

Related reading: Vibe Coding, and Exactly Where It Breaks for the failure mode at full scale, Will AI Replace Programmers for why reading code is now the higher-value skill, and Recursion Explained for a topic where predicting before running is the whole technique.