Using an AI assistant can build your skill or replace it, and from the outside the two look almost the same. This article shows what research has found about the difference, and gives you a check you can run on your own recent prompts and agent tasks to see which one you are doing.
Three weeks ago you had never used the subsystem your team works in. Since then, with an assistant open beside the editor, you have closed eight tickets. Then a probe failure appears that you have not seen before.
You hand the log to the assistant, apply its suggestion, rebuild, and repeat twice. The error stops. You could not explain what any of the three changes did, or whether the last one fixed the fault or only hid it.
The question is not whether to use the tool. It is how to tell whether it is teaching you or doing the part you needed to learn.
What is the difference between AI-assisted learning and avoidance?
Education researchers separated two kinds of help seeking long before AI. Instrumental help seeking asks for only as much help, and the kind of help, needed to solve the problem yourself. Executive help seeking asks someone else to solve it for you, which is a sensible choice when learning is not the goal.
In one classroom study of 70 school students using tutoring software, those who clicked through the hints or guessed until the answer appeared tended to score lower afterwards. It showed a link, not a cause, and it was with children, so treat it as a pattern, not a rule.
Researchers also study help avoidance: not asking when you need to, which is a real risk for new engineers. Here, avoidance means something different: asking in a way that hands over the thinking.
My reading is that AI has lowered the cost of executive help. Asking a senior colleague for the third time in a day was uncomfortable, so you tried harder first. An assistant is instant, private and always available.
An assistant answers the request exactly as you typed it. It does not know which kind of help you needed.
Same assistant, same task, different results
A recent randomised study gave 52 engineers, mostly junior, a 35-minute task in an asynchronous Python library none of them had used. Half had an AI assistant. On a quiz immediately after, the assistant group averaged 50 per cent against 67 per cent for the group without it, and the largest gap was on debugging questions.
Retention was not measured, and nobody has tested this on kernel or embedded work. With those limits, the more useful finding is inside the AI group.
Three ways of using the assistant scored below 40 per cent: asking it for the whole task; starting with a question or two, then asking it for all the code; and relying on it to debug or check the code instead of to understand it. Three scored 65 per cent or more: asking conceptual questions, asking for code together with an explanation, and generating code, then using the assistant to check their own understanding of it.
That last pattern “looks nearly the same as the AI delegation group”, in the paper’s words.
The high and low groups were separated by one extra step after the answer arrived.
Each pattern covered only two to seven people who chose their own approach, and the authors say the patterns show association, not cause.
How to check which one you are doing
Take your last twenty prompts from real work, or the last twenty tasks you gave an agent. With inline completions, take one recent commit and every multi-line suggestion you accepted in it. Sort each item into three groups:
- A request for a result. “Write”, “fix”, “make this work”, a pasted error with no question, or a diff you accepted without being able to explain each changed file.
- A request for an explanation of something you had not tried to solve yourself first. Count it in the first group if you used the explanation without testing it, and in the third if you tested it.
- Your own attempt, sent for checking. A hypothesis, an explanation or code you wrote, with a question about it.
Then ask of each one: after the answer arrived, did you do anything with it apart from use it? If more than half sit in the first group with nothing done afterwards, the assistant did the part you needed to learn. Move one prompt a day into the third group.
Also notice why you opened the chat. Opening it to end the discomfort of not knowing, rather than to ask something specific, is often where executive help starts. Turning that feeling into a question is the subject of AI Can Fetch the Answer. Only You Can Notice the Question.
What the two kinds of request look like
From here on, the suggestions are practical ones that the studies above did not test. These prompts are illustrative, for a driver whose probe keeps deferring. A request for a result:
Fix this: [pasted dmesg output]Your own attempt, sent for checking:
My driver's probe keeps deferring (-EPROBE_DEFER). I think the
regulator it needs is not registered yet, because the PMIC driver
is built as a module and may not be loaded yet. Is that consistent
with this log? Do not give me a fix yet. Tell me what else I
should check to confirm it.If you have no hypothesis yet, ask only what each line of the log means. And the extra step, after the assistant has generated code for you:
Before I use this: what are the trade-offs of this approach
versus [the approach I would have tried], and what would break
if I removed the retry loop? I will answer first, then you
check my answer.With an agent, the extra step comes before the change. Ask for its plan first, and do not approve it until you can say which files it will touch and why. Then review a multi-file diff one file at a time, predicting each change before you open it.
Four mistakes that look reasonable
“I am in study mode, so I am learning.” This seems reasonable because the tool is designed to teach. Study modes in chat, and learning output styles in coding tools, do help.
Physics students using an AI tutor built to give one step at a time learned more than in an in-class active-learning session. But even that tutor would give the answer when a student demanded it, and these modes can be switched off. Guardrails are covered in Try First or Read First Is a Decision, Not a Temperament.
“I am fast, so I must be avoiding.” This seems reasonable because learning usually feels slow. But the conceptual-question pattern was the second fastest of all six, after asking for the whole task.
How fast you finished tells you very little. Who did the reasoning tells you most of it.
“I will stop using AI while I learn.” This seems reasonable because the group without an assistant did score higher on average. But the small high-scoring patterns averaged close to that group, and the skill worth building is using the tools that way.
“The error stopped, so I understand it.” This seems reasonable because a fix that runs looks like proof. But relying on the assistant to debug scored among the lowest, and an AI review bot passing your change is the same pattern. Unfamiliar failures are covered in The Mindset Behind Hard Debugging.
A checklist to confirm you learned it
Run this after an assistant did significant work in an area new to you:
- Close the session and write the commit message yourself: what changed, why, and whether it fixes the root cause or only the symptom.
- Change one input, timing or configuration value and predict the result before you run it. On hardware, change one thing per flash.
- The next time an error appears in that area, write your hypothesis before you paste anything. Record whether it was right.
- At the end of the week, check that your prompts in that area have moved from the first group towards the third.
If you cannot do the task a second time without the assistant, the first time was delivery, not learning.
Delivery is often what the job needs. Under a deadline, ship the fix, then spend ten minutes on this checklist before you close the ticket. Code nobody can explain is the subject of The Code Is Yours. The Understanding Is Not.
A mentor in a live session can hear which kind of help you are asking for, and can ask what you have already tried before answering. That is one reason TECH VEDA sessions are live and built around problem scenarios.
Where these findings come from
- Shen, J. H. and Tamkin, A. (2026). How AI Impacts Skill Formation.
- Companion summary: How AI assistance impacts the formation of coding skills, Anthropic, January 2026.
— Raghu Bharadwaj
