The first useful thing AI did for me as a working programmer was answer questions at the speed of thought. Not search-engine speed, where you type a query, skim three Stack Overflow threads, read a man page, and come back to your editor having lost the thread of what you were doing. I mean: I have a question, I get an answer, I keep coding. The loop closes in seconds instead of minutes.

That is a real improvement. It is also, I think, a partial picture of what is actually happening. And the part that gets left out of most conversations about AI and learning is worth spending some time on.

The feedback loop problem

Anders Ericsson spent most of his career studying how experts become experts, and the consistent finding was that deliberate practice requires rapid, accurate feedback. You practice, you get corrective signal, you adjust. The shorter the loop, the faster the model in your head converges on something real. This is why a musician practicing scales with a teacher in the room improves faster than one practicing alone, and why medical students on clinical rotations learn more per week than in a lecture hall: the feedback is tighter, faster, more specific.

Classical learning has high-latency feedback baked in. You write code, you wait for the compiler, you run the tests, you read the error message, you search the docs, you try something, you wait again. For a beginner, the latency isn’t the annoying part: it is the whole thing. You don’t just wait for answers. You wait, you read, you form hypotheses, you try them, they fail, you revise. Each cycle deposits something in the mental model you are building.

AI compresses that cycle to seconds. For syntax, for API surface, for patterns you don’t know yet, this is genuinely transformative. Time-to-first-working-thing drops dramatically. The beginner who would have spent two hours fighting a type error now spends ten minutes. The senior engineer who would have spent an afternoon reading documentation for an unfamiliar library now spends twenty minutes getting oriented and an afternoon doing actual work.

This is the useful part, and it deserves the attention it gets.

The test is novel failure

Here is what I notice about junior engineers who have learned primarily by prompting.

They are faster. They ship something working much sooner than their counterparts from five years ago. When the task is within the distribution of things they have done before, or things the AI has done before, they are genuinely competent.

Put them in front of something outside that distribution and the gap opens immediately.

A race condition in Go that the AI has not seen the shape of before. A nil pointer dereference buried three layers deep inside an interface chain. A database query that performs fine at a thousand rows and collapses at a million. A memory leak that only appears under specific concurrency patterns. These are not exotic failures. They are the normal failures of software at non-trivial scale. What they require is not pattern-matching but reasoning: you have to hold a mental model of the system in your head, trace a chain of causation, form a hypothesis, find a way to test it.

That mental model is exactly what gets skipped when you learn primarily by prompting your way to working code. The code works. You don’t understand why. This feels like learning. It isn’t.

What struggle actually does

Geoff Colvin, in Talent Is Overrated, makes a point that sounds counterintuitive until you take it seriously: the output of practice is not the point of practice. The struggle is the mechanism. When you fight to debug a problem you have never seen, the resolution of that fight encodes something. The dead ends you explored, the wrong hypotheses you tested, the moment the correct explanation clicked: all of that leaves a trace in the mental model that makes the next unfamiliar problem faster to diagnose.

AI removes the struggle. Which means it removes the mechanism.

You get the output without the encoding. The code compiles, the tests pass, you move on. Nothing was deposited. The next time you encounter a structurally similar problem without AI assistance, you are back at zero. The code you shipped was real. The learning was not.

There is a specific failure mode that follows from this, one that I think is underappreciated. People who become fluent in prompting a domain they don’t deeply understand develop what I would call confident incompetence. They can get things done across a wide range of normal cases. They move fast, they ship things, they look productive. Until something goes wrong they cannot diagnose. At that point the gap between what they appear to know and what they actually know becomes visible all at once. And it is often larger than expected, because the prompting has been so effective at masking it.

Where AI actually helps

The description above sounds like an argument against using AI for learning. It isn’t. It is an argument about sequencing.

AI is best used after you have the mental model, not before it. Once you understand the territory, AI is a force multiplier. Once you know what a race condition is, what produces one, how to reason about shared mutable state, the AI becomes a fast way to write correct synchronization primitives you already understand but would otherwise have to type. Once you understand an API deeply enough to have expectations about its behavior, the AI helps you move through it at ten times the speed.

For an expert, AI is one of the most useful tools to appear in a long time. It handles the translation work that doesn’t require judgment, which frees up time and attention for the work that does. This is genuinely valuable.

For a beginner, the same tool is a shortcut that may bypass the infrastructure needed to use it well later. The beginner does not yet know what they don’t know. The struggle they are being spared is the process that would tell them.

Use the AI as a rubber duck, not an oracle. Talk to it, push against it, question what it gives you. If you can’t explain why the code it produced works, you don’t understand it yet. Understanding is the goal. Working code is the evidence you are getting there, not a substitute for it.

A new skill nobody is naming

There is a skill that has quietly become essential, and I have not seen it discussed clearly anywhere.

Before LLMs, the feedback loop in learning was slow enough and honest enough that you usually knew, roughly, how much you understood. If you didn’t understand something, you tended to fail at it. The failure was the signal. It was annoying, but it was accurate.

Now the feedback loop can close without you. You prompt, the AI produces, things work. The signal that would have told you whether you actually understood something has been replaced by a signal that tells you only whether the AI understood something. These are not the same thing, but they feel the same.

The new skill is metacognition: knowing whether you understand something versus knowing whether you can prompt something. This distinction did not matter much before, because the consequences of confusing them appeared quickly. Now the consequences can be deferred almost indefinitely, until you are deep enough into production, or a project, or a job, that the gap becomes expensive.

Cultivating this requires deliberate effort. After getting an answer from an AI, ask yourself: can I explain this without the AI’s help? Can I trace why it works? Can I predict what would break it? If the answer is no, you have the output but not the knowledge. That is worth knowing.

How I would learn something new today

I learned programming before LLMs existed. The resistance I feel to AI shortcuts in early learning is not nostalgia. It comes from having experienced what the struggle produces and from watching what happens to engineers who skipped it.

If I were learning a new technical domain today, the sequence I would use is this.

First principles first. Read the spec. Read the source when you can. Build the toy implementation, the thing that does only one thing badly. Understand the error messages as a language. Spend time in failure, because that is where the model is built.

This phase is slower. It is supposed to be slower. The point is not to produce working code as fast as possible. The point is to build the mental structure that makes the fast work later make sense.

Once the model is in place, once you can reason about why things fail and predict how the system will behave, then use the AI. Use it to write the boilerplate you already understand. Use it to explore API surface you can evaluate critically. Use it to move ten times faster through territory you have already mapped.

The order matters. First principles, then force multiplier. Not the other way around.

The uncomfortable implication

The story the industry tells about AI and learning tends to stop at the access argument: AI gives everyone access to instant expert guidance, which democratizes skill acquisition. This is true as far as it goes.

What it leaves out is that democratizing access to answers is not the same as democratizing the acquisition of understanding. Understanding requires the struggle. The struggle is what the AI most efficiently removes.

The engineers who will benefit most from AI over the next decade are not the ones who learn fastest by prompting. They are the ones who have the mental models deep enough to use AI output critically, to know when it is right and when it is plausible but wrong, to diagnose the failures it cannot see and build the things it cannot reason about.

Those mental models are built the old way. Slowly, under friction, by repeatedly failing at things that are just outside your current reach. AI does not change what builds them. It changes how tempting it is to skip the process that does.