Using AI to learn

AI tools can help you build a skill or quietly replace learning

Which one happens is rarely visible while it is happening — that is what makes this hard. This page starts with what goes wrong and how to notice it in yourself, then covers how the goal, and the right way to work, changes between an introductory course and an advanced one.

The core problem

Fluency is not competence

The main risk with AI is not dishonesty. It is that AI produces a very convincing feeling of understanding, and that feeling is not the same thing as the ability it resembles.

Reading a clear explanation of a solution activates much the same sense of "I've got this" as actually being able to produce one. But comprehension and production are different abilities, and only the second is what an exam, a whiteboard interview, or a bug at 2am will ask for. Psychologists call this a fluency illusion: material that is easy to process feels well learned. AI is exceptionally good at making things easy to process — which is genuinely useful when you are trying to understand something, and genuinely dangerous when you mistake the ease for the skill.

The gap does not announce itself. Nothing goes wrong at the moment you accept a solution you could not have written; everything still works, the assignment is submitted, the feedback is fine. The bill arrives later, and somewhere less convenient — which is why the pitfalls below are worth recognising early, while they are still cheap to correct.

What goes wrong

Seven pitfalls that stop you learning

These overlap and reinforce each other, and almost none of them involve a decision to stop learning. They are the ordinary ways it happens anyway. Each one comes with a warning sign you can check yourself against.

1. The illusion of understanding

Watching a solution appear is not the same as being able to produce one. The explanation is clear, it makes sense as you read it, and you move on. But "this makes sense" and "I could do this" are different states, and only the second survives contact with a closed-book exam.

Warning sign You follow the reasoning easily, then cannot start the same problem from a blank file an hour later.

2. Skipping the struggle that does the teaching

Being stuck is uncomfortable, and it is also where most of the learning happens. The effort of retrieving something half-remembered, trying an approach and seeing exactly why it fails, is the mechanism — not a delay before the mechanism starts. Asking at the first sign of friction removes precisely the part that would have made the concept stick.

Warning sign Your first move when stuck is the AI, within seconds, every time.

3. The deadline decides for you

Almost nobody sits down and decides to stop learning. What happens is 11pm the night before a hand-in, when whatever produces a working submission wins by default. The choice gets made by circumstance rather than intention — which is why the only reliable defence is structural rather than moral: start early enough that you can afford to learn, and decide your own rules while you are rested rather than at midnight.

Warning sign Your AI use rises sharply in the last 24 hours before every deadline.

4. Solutions above your level

AI will happily produce code using patterns, libraries and language features you have not met yet. It works, so you keep it. But you cannot judge whether it is appropriate, cannot debug it when it breaks, and cannot defend it if asked. It also skips the intermediate version — the clumsy, explicit implementation that would have taught you why the elegant one is better.

Warning sign There is a line in your submission you could not rewrite from memory or explain to a classmate.

5. You can't debug what you didn't build

Writing code builds a mental model of how it works, and that model is what you use when it breaks. Accepting code hands you the artifact without the model. The cost lands at the first real bug — often at the worst possible moment, and often when the AI cannot fix it either, because fixing it requires knowing what the program was supposed to do in the first place.

Warning sign Your only debugging strategy is to paste the error back in and hope.

6. Fundamentals never become automatic

Basic syntax, control flow and data structures have to become effortless before you can think about anything harder — working memory is small, and anything that is not automatic consumes it. Skipping the repetitions means the basics stay expensive forever, which quietly caps the difficulty of the problems you can take on, with or without AI in the room.

Warning sign You still cannot write a loop over a dictionary without looking up the syntax.

7. The feedback signal disappears

Coursework is a diagnostic — for you, and for whoever is teaching you. It is how both of you find out what you have not understood while there is still time to do something about it. If AI does the work, that signal goes quiet for everyone, and the gap surfaces at the exam instead, when it is too late to act on.

Warning sign You are doing well on coursework and noticeably worse on anything closed-book.

Diagnosis

Are you actually learning?

The honest way to answer this is not to reflect on how much you used AI, but to test what you can now do without it. Three checks, applied to something you finished recently:

The blank-file test. Could you write this again tomorrow, from nothing, without help? Not the same characters — the same working solution.
The line-by-line test. Can you say why each line is there, and what would break if you deleted it?
The debug test. If this failed on an input you had not thought about, would you know where to start looking?

If the answer is no, you have an artifact rather than a skill. That is completely fine when the artifact was the point. It is a problem when the skill was.

Tutor or contractor: the same tool, two modes

Most of the difference between AI that teaches you and AI that replaces you comes down to which of these you are doing. The tool is identical; what changes is who is doing the thinking.

As a contractor You describe an outcome and receive an artifact. Fast, effective, and it teaches you nothing — you end the session with code and the same abilities you started with.

As a tutor You do the work and it responds to it: explains a concept you name, critiques your attempt, asks what you think happens next, invents a similar problem for you to try. Slower, and you end the session able to do something new.

💡

Not everything is a learning task — and that's fine If you need a one-off script to rename some files, or a regex for a side project, delegating it is a sensible use of your time. The question worth asking is narrow: is this the skill I am currently supposed to be acquiring? Boilerplate in an algorithms course is not what is being assessed; the algorithm is. Writing a sort function in a data-structures course is the entire point. Same action, different answer, depending on what the work is for.

What to do instead

Guidance by course level

The pitfalls above bite hardest early, when the skills being built are the ones AI most easily replaces. As you progress, what is being assessed shifts — and so does the right way to work.

Intro programming courses

Use AI to build the skill, not bypass it

In an intro course, the point of an exercise is usually the struggle itself — tracing through a loop, finding your own off-by-one error, structuring a function from scratch. The core principle: ask AI to explain, not to produce.

Ask for an explanation of an error message or concept, not a fix.
Write your own first attempt before asking AI to review it.
Ask AI to generate extra practice problems similar to one you're stuck on.
Use AI to trace through your code line-by-line and explain what it's actually doing.
Set a rule for how long you'll struggle before asking — and let the timer, not your frustration, decide.
Treat every AI answer as something to question, not something to trust by default.

Advanced / upper-level courses

Use AI efficiently, like a professional

In advanced courses and in industry, what's being assessed shifts from "can you write this code" to "can you ship correct, maintainable software" — which includes knowing how to direct, review, and verify AI output as part of a real workflow.

Write a clear specification before prompting: scope, constraints, what "done" looks like.
Review AI-generated diffs like a teammate's pull request — line by line, not just "does it run".
Use agentic tools for boilerplate, migrations, and repetitive refactors; keep architecture decisions for yourself.
Run and read the test suite yourself — don't accept "tests pass" secondhand from a tool's summary.
Apply the same security and correctness review you'd apply to any code you didn't write yourself.
Know when not to delegate: novel algorithms, security-sensitive code, anything you can't yet verify is correct.

Worked example

Same bug, two different prompts

The difference between a prompt that builds skill and one that bypasses it is usually small.

Shortcut prompt Write a Python function that takes a list of numbers and returns the average.

Skill-building prompt I wrote this to compute the average of a list, but it crashes on an empty list: [code]. What should happen in that case, and where in my code should I add the check?

The first prompt asks for the assignment itself. The second keeps you as the author: you wrote the function, you're fixing the bug, and AI is only helping you reason about the edge case.

Summary

Entry-level vs. advanced, side by side

Aspect	Entry-level courses	Advanced courses
Goal of using AI	Build understanding of fundamentals	Ship correct, maintainable software efficiently
Best use	Explanations, debugging guidance, practice problems	Spec-first prompting, multi-file agentic tasks, review
Review habit	Question every answer before trusting it	Review AI diffs like a colleague's pull request
Tools most relevant	Copy-paste chat assistants	In-IDE chat, agentic CLI tools, background agents
Risk to watch	Bypassing the skill the exercise is meant to build	Shipping unreviewed or insecure AI-written code