AI Doesn’t Make You Learn Faster. It Changes What You Learn.

There is a small trap in the way we talk about AI and programming.

We say things like:

AI helps me code faster, so it helps me learn faster.

Sometimes that is true. But not always.

Finishing a task and learning from a task are related, but they are not the same thing. This sounds obvious when you say it slowly. It becomes less obvious when a model gives you a working answer in 10 seconds and your brain gets a tiny productivity cookie.

If you already know the domain, AI can be a very good accelerator. It can remove boilerplate, remind you of an API, generate boring tests, or help you compare two implementations.

But if you are still learning the domain, AI can also remove the exact friction that would have created understanding.

That is the uncomfortable part.

AI does not only change how quickly you finish the work. It changes which parts of the work you still do yourself. And that changes what you actually learn.

The research points to a useful distinction

Anthropic studied developers working with an unfamiliar async Python library. Some participants had AI assistance. Some did not. Afterward, researchers looked at things like understanding, code reading, and debugging ability.

The lazy takeaway would be “AI is bad for learning.” I do not think that is the right conclusion.

The more useful takeaway is this:

AI can help you produce an answer without helping you build the mental model behind the answer.

That distinction matters.

In the study, AI-assisted participants could get through the task, but they tended to show weaker understanding afterward. In that specific setup, the time savings also were not strong enough to make the trade-off obviously worth it.

I would not overgeneralize this into every possible learning situation. One study is not the whole universe. But the pattern feels familiar if you have used AI while learning a new stack.

You can get something running.

You can feel productive.

You can even ship the change.

But later, when the code breaks in a slightly different way, you may realize you never really learned why it worked.

The hidden cost is skipped reps

When people defend AI for learning, they often talk about access.

Access is real. A beginner can ask questions they were previously too embarrassed to ask. A developer can get an explanation at 11 PM without waiting for a coworker. A model can show three examples faster than documentation sometimes can.

That is useful.

But access to answers is not the whole learning process.

A lot of engineering skill is built in the annoying middle:

That loop is slow. It is also where the useful reps happen.

You learn what the API actually expects. You learn which errors matter and which ones are noise. You learn what an abstraction hides. You learn what “async” means when your code behaves differently than your mental picture.

If AI enters too early, it can remove the wrong friction.

Removing boilerplate is good.

Removing repetitive syntax lookup is usually fine.

Removing the part where you form a hypothesis, test it, and understand why it failed is more dangerous.

For example, imagine you are learning a new framework feature. You ask the model to implement it. The code works.

Nice.

But did you learn:

• which lines are required and which lines are just style?
• what assumptions the implementation makes?
• how to debug it when the next case is slightly different?
• what the framework is doing underneath?
• when not to use this pattern?

If the answer is no, the model did not really teach you the feature. It built a temporary bridge over the part you did not understand.

Sometimes that is fine. Deadlines exist. Production bugs do not care about your learning journey.

But if the goal is skill formation, skipped reps are not free.

Performance is not learning

This is the distinction I wish more engineers made explicit.

Performance means you completed the task.

Learning means you changed your future ability.

Those two things can happen together. They often do. But they do not have to.

A calculator improves arithmetic performance. It does not automatically make you better at arithmetic. Google Maps helps you reach a restaurant. It does not automatically make you understand the city.

AI can work the same way.

If I use it in a domain I already understand, it can speed me up with a relatively low downside. I can inspect the output. I can smell weird code. I can reject a bad abstraction. I can ask better follow-up questions because I know what matters.

If I use it in a domain where I do not have judgment yet, I may confuse this state:

The code runs.

with this state:

I understand the code.

Those are not the same.

A senior engineer using AI in a familiar stack and a beginner using AI to enter an unfamiliar stack are not doing the same activity.

One is accelerating execution.

The other may be outsourcing practice.

The “paste and pray” loop

The dangerous workflow is not asking AI for help. That is normal now.

The dangerous workflow is this:

run code
see error
ask AI
paste fix
run again
see another error
ask AI
paste fix

This feels like debugging, but often it is not.

Real debugging requires a hypothesis.

You think:

I believe this error happens because this value is undefined at this boundary.

Then you inspect the value. Maybe you are wrong. Good. Now you update your model.

In the paste-and-pray loop, the model does most of that work. You become the person moving text between the editor and the chat window.

Again, I am not judging this as a survival tactic. If production is broken, fix the thing. Use the model, search Stack Overflow, read logs, ask a coworker, sacrifice a keyboard if needed.

But as a default learning loop, it is weak.

You may solve today’s error and still be helpless when the same class of error appears tomorrow with different wording.

Not all AI usage is the same

I do not think the answer is “avoid AI while learning.” That is unrealistic and probably not useful.

The better question is:

What role is AI playing in the learning loop?

The difference is not whether AI is present.

The difference is whether you still do the model-building work.

How I would use AI when learning something new

If I am learning a new library, architecture pattern, or language feature, I would use AI with constraints.

Not because constraints are fun. They are not. But without them, the tool naturally pulls you toward the fastest answer, not the deepest understanding.

1. Try the first version manually

For the first pass, read the docs. Write the awkward version. Let the error message punch you in the face a little.

That friction is not wasted time. It gives you hooks.

When AI later explains the better approach, you have something to compare it against. Without that first attempt, the explanation can sound clear while still not sticking.

2. Ask for concepts before code

Instead of starting with:

Implement this for me.

try:

Explain the simplest version of this pattern.
What problem does it solve?
What assumptions does it make?
Where does it usually break?
Give me a small example, but do not optimize it yet.

This changes the model from a code vending machine into something closer to a tutor.

Still verify it. Models can be confidently wrong. But the direction is better.

3. Force yourself to predict

Before running generated code, ask yourself what should happen.

Before reading the model’s explanation, guess the cause of the bug.

Before accepting a fix, write down why you think it works.

This sounds small, but prediction is a big part of learning. If you never predict, you never test your own model.

4. Rewrite the important part without looking

After AI gives you an implementation, close the chat and rebuild the important part yourself.

You do not need to memorize every line. That is not the point.

The point is to check whether the structure is now in your head or still only in the chat transcript.

5. Use AI to challenge your explanation

A better prompt is often:

Here is my explanation of how this works. What am I missing?

or:

Ask me three debugging questions about this code. Do not give me the answer immediately.

This keeps you active. The model becomes a sparring partner instead of a designated hitter.

Why this matters for teams

This is not only an individual problem.

Teams will feel it too.

If junior engineers use AI mostly to produce answers, they may ship more code while building weaker foundations. That can look fine for a while. Pull requests still appear. Tickets still move. Demos still work.

The problem shows up later:

• code review becomes harder because the author cannot explain the trade-off
• debugging takes longer because the mental model is missing
• incidents are scarier because the generated code is now production code
• design discussions become shallow because people know the answer shape, not the reasoning

The hidden cost is not “AI writes bad code.” Sometimes it writes decent code.

The hidden cost is that the engineer may not know why the code is decent, where it is fragile, or how to change it safely.

That changes mentoring.

Code review cannot only ask:

• Does this work?
• Are tests passing?
• Is the style okay?

It also has to ask:

• Can the engineer explain the trade-off?
• Do they understand the failure mode?
• Can they debug the generated code without immediately asking the model again?
• Can they simplify it?
• Can they tell when the model invented something?

AI literacy is not just prompt fluency. Prompt fluency is useful, but it is not enough.

The more important skill is judgment.

What this means in practice

I would not treat AI as either a miracle tutor or learning poison. Both takes are too simple.

I would treat it as a tool that changes the learning environment.

That means:

• Use AI aggressively for work you already understand and can evaluate.
• Use AI carefully when the goal is to build a new mental model.
• Do not confuse working output with skill acquisition.
• Watch for workflows where the model does all the hypothesis generation.
• In teams, review understanding, not only code.

The uncomfortable part is that good learning often feels slower than AI-assisted output.

But that slowness is not always waste. Sometimes it is the work.

Final thought

AI can make you faster at producing software.

It does not automatically make you faster at becoming the kind of engineer who understands software.

That depends on which parts of the loop you keep for yourself.

If you give away typing, fine.

If you give away debugging, prediction, and model-building too early, do not be surprised when the working code leaves no skill behind.