You finish a feature with AI.
The page loads. The API responds. The error is gone.
Then a requirement changes, and you’re unsure which part of the code to touch.
Does that mean using AI was a mistake? Not necessarily. But it raises a question worth asking:
Did the task leave you with a working feature, a better understanding—or both?
As developers, we need to deliver work. We also need to develop the judgment to maintain it. Those goals can support each other, but they don’t automatically move at the same speed.
Imagine asking AI to build a product filter.
It adds a dropdown, stores the selected category, and filters the list. You try a few categories. Everything works.
Now the requirement changes:
“Keep the filter selected after a refresh, and let users share the filtered page.”
Can you explain where the current selection lives? Can you decide whether it belongs in the URL, browser storage, or somewhere else?
You can still consult documentation or ask for help. The useful question is whether you can reason about the change before requesting another implementation.
A completed feature shows that a solution exists. Adapting it gives you more evidence of what you understand.
A January 2026 study by Anthropic researchers examined developers learning Trio, an unfamiliar Python library.
The researchers recruited 52 mostly junior engineers. Participants completed coding tasks with or without AI assistance, then took an assessment. Average scores were 50% in the AI-assisted group and 67% in the group without AI assistance.
The difference in completion time was not statistically significant.
That deserves attention, but it needs context: this was a short experiment involving one unfamiliar library and an immediate assessment. It doesn’t establish that every use of AI weakens learning, or tell us what happens across years of professional work.
The researchers also observed different interaction patterns. Participants who asked conceptual questions or worked through explanations tended to show stronger understanding than those who heavily delegated the work.
Those patterns were observational, not separately randomized. They suggest useful questions about our habits; they don’t prove that a particular prompting technique guarantees learning.
Read the study summary and its limitations. AI can explain code clearly. That’s helpful.
But an explanation making sense while you read it isn’t the same as being able to apply the idea later.
Consider authentication. You read an explanation of access tokens and think you understand the flow.
Then a token expires halfway through a session.
Where does the failure appear? What should the frontend do? Which part belongs on the server? Could a retry repeat an operation?
You don’t need every answer immediately. Being able to identify what you need to investigate is already valuable.
One way to check your understanding is to make a prediction before running the code:
“If the API returns an empty array, this component should show the empty state.”
Then test it.
When the result differs from your prediction, you’ve found something specific to learn.
You don’t need to stop using AI or rebuild every feature from memory. Try this with one unfamiliar part of your next task.
Write a short explanation in your own words.
For a form, describe: “I’m not sure what happens here” is a useful finding. It’s more actionable than “I need to get better at backend development.”
Change a requirement in a development branch.
For the product filter, make the selected category appear in the URL. Before implementing it, decide what should happen when:
Use documentation. Ask questions. But form an initial approach before accepting a generated one.
Use a disposable example or development environment.
Send invalid input, return an empty result, or simulate a failed request. Before asking AI to fix it, record:
This isn’t an exam. It’s a way to discover whether the implementation matches your mental model.
“Fix this” is sometimes an appropriate request. It just shouldn’t be the only interaction available to you.
Try:
“Don’t edit the code yet. Identify two plausible causes and suggest how I can distinguish between them.”
Or:
“Here is my explanation of this function. Which parts are inaccurate or missing?”
For a new concept: “Give me a small exercise using this idea. Let me attempt it before showing a solution.”
Check the answers against documentation and observed behaviour. An explanation can be wrong even when it sounds coherent.
There’s a reasonable counterargument: work has deadlines. Spending an hour studying familiar boilerplate may add little value.
That’s fair.
The point isn’t to maximize manual effort. It’s to be deliberate about where understanding matters.
If you already understand the pattern, delegating repetitive implementation can be sensible. If the feature introduces unfamiliar permissions, payment behaviour, database updates, or failure handling, reserve time to review and test those decisions. Teams have a role here too. Expecting juniors to deliver faster while removing time for questions, review, and practice creates a difficult learning environment.
Counting completed tasks won’t tell you everything about your development.
Occasionally ask:
You can use AI and still make progress on all four.
The goal is to finish work while retaining enough understanding to take responsibility for it.
Think of one feature you recently built with AI: what could you now explain or change that you couldn’t before? What part still feels unclear?
Shen, J. H., and Tamkin, A. How AI Impacts Skill Formation.
The workflow suggested in this article is a practical recommendation, not a validated learning intervention.