How to Use AI Without Skipping the Learning

Finishing and understanding are separate outcomes

An unfamiliar task usually creates friction.

You read documentation. Try an approach. Misunderstand something. Read the error. Adjust your mental model.

Some of that effort is avoidable. Fighting an obscure configuration issue for three hours is not automatically a valuable education.

But some of the friction is where understanding develops.

If an assistant handles every confusing step, you may arrive at a working result without knowing which assumptions failed along the way.

That gap may stay invisible until the system behaves differently.

The feature works with one request. What happens with two? The retry succeeds in a test. What happens when the original operation completed but the response disappeared?

Understanding shows up when the situation changes.

There is research worth paying attention to

Anthropic studied 52 developers learning an unfamiliar Python library. Participants using AI assistance averaged 50% on a subsequent assessment, compared with 67% for those working without it. The difference in task completion speed was not statistically significant.

That is a specific experiment involving a specific task. It doesn’t tell us what every engineer will experience or establish the long-term effects of AI use.

Still, it raises a useful question: what did someone retain after completing the work?

The researchers also observed that interaction patterns mattered. Participants who used conceptual questions and explanations to build understanding tended to retain more than those who delegated the work.

I take that as a reason to examine how we use the tool, rather than treating all AI assistance as the same activity.

Anthropic’s coding-skills study

Make a prediction before requesting a fix

Here is a practice I would try.

When something fails, write down what you think happened before asking AI to solve it.

It can be one sentence:

“I think this request is being retried after the database transaction has already committed.”

Now you have a hypothesis.

Read the error. Look at the relevant logs. Identify what evidence would support or contradict your explanation.

Then bring the assistant into the investigation.

Ask it to challenge your hypothesis, identify missing evidence, or explain behavior you don’t understand.

You can still move quickly. The difference is that you remain involved in deciding what the evidence means.

Without that step, debugging can become a sequence of plausible edits with no explanation connecting them.

Use the assistant to expose gaps

“Explain this code” can be a useful question.

I would go further:

• Which assumptions does this implementation depend on?
• What happens if this operation runs twice?
• Which part of my explanation is wrong?
• What would fail if this dependency became unavailable?
• Give me a small example that distinguishes these two approaches.

These questions make the interaction more useful for learning because they give you something to reason about.

The answers still need verification. An explanation can be fluent and incorrect.

Use documentation, experiments, tests, and review to check it. The assistant should help you investigate, not become the only evidence for its own answer.

Check understanding after the task

Before calling an unfamiliar task finished, close the conversation and explain the result.

What was the problem? Why did this approach work? Which alternative did you reject? What remains uncertain?

You don’t need a performance in front of the whole team. A short note or a conversation with a reviewer can be enough.

If you can explain only what the code does line by line, keep going. Try explaining why the system needs that behavior.

That is often where the missing understanding becomes visible.

Companies need to make room for this

An engineer cannot protect learning alone if every incentive rewards immediate completion.

If a team wants people who can diagnose failures and review generated code, it needs to allow them to develop those abilities.

That means making room for investigation, explanation, and feedback. It means asking what someone learned from a task instead of treating every extra question as lost productivity.

The practices above are proposals, not a proven recipe. Teams should try them and examine whether they improve independent diagnosis and understanding.

AI can remove a lot of unnecessary effort.

I want us to be deliberate about the effort we keep.

Because the next difficult problem may require the understanding we were supposed to build on the last one.