How to Learn to Code With AI (ChatGPT or Claude) Without Getting Stuck

You've been told to learn Python with ChatGPT. So you ask it for a program, it gives you forty working lines, you run them, they work, and two weeks later you can't write a loop from a blank file. That's the stall. It feels like progress because the screen shows green output, but you haven't done the part that builds skill.

The fix is to change what you ask the AI for. Ask for hints, questions and checks. Keep the typing, the predicting and the debugging for yourself. The rest of this post is that routine, with one real example I ran so the error messages below are genuine, not mocked up.

Why does learning to code with AI stall?

Because the assistant is very good at the exact thing a learner should be doing. Writing the code, finding the bug, explaining the error: each of those is a rep you skipped. Programming is learned the way an instrument is, by producing wrong output and working out why.

Three patterns show up again and again:

• Paste, run, forget. The code works, you've learned nothing, and the next exercise feels as hard as the first.
• Explanation that sounds right. The assistant explains a concept fluently and you nod along. Nodding isn't understanding. You find out you don't understand when you try to use it.
• Error roulette. Something breaks, you paste the error, apply whatever comes back, something else breaks. You never read an error yourself, so you never get faster at it.

None of these are the tool's fault. They're what happens when the easiest path is also the one that teaches least. You have to make the better path the default, and a setup prompt does that.

What setup prompt turns the AI into a tutor?

Paste this at the start of a new chat for each topic. It's an untested template in the sense that I haven't measured how well each model follows it, so test it yourself: ask for the answer to a simple exercise and see whether it holds the line.

You are a patient programming tutor. I'm a beginner learning [Python].
My goal this week: [write functions that take a list and return a result].

Rules:
1. Never give me a complete solution to an exercise unless I type
   "SHOW ANSWER". Give me a hint first, the smallest one that unsticks me.
2. When I paste code that fails, don't fix it. Ask me what I expected to happen
   and what actually happened. Then point to the line to look at.
3. When I paste code that works, ask me one question about it that checks I
   understand it (what happens if the input is empty? why this and not that?).
4. Keep explanations under 150 words and use my variable names.
5. If I ask for something that's much bigger than my current level, say so
   and suggest a smaller step.

Rule 2 is the one that matters most. Rule 5 is the one beginners forget to ask for: assistants rarely volunteer that your project idea is three levels too hard.

If your chatbot has a built-in learning mode, it's worth trying alongside this. OpenAI's help center describes a "study mode" in ChatGPT that asks questions and checks understanding rather than giving final answers (I couldn't open that page directly on 2026-10-08, it returned an access error, so I'm relying on the search summary of it). Reports of Anthropic's "learning mode" say it targets university accounts. Neither replaces your own rules above, because those are the ones you control.

How do you read an error message before asking for help?

Here's the real thing. I wrote this tiny program, a beginner-style function that averages exam marks, and ran it on Python 3.14.3 on 2026-10-08.

def average_marks(marks):
    total = 0
    for m in marks:
        total = total + m
    return total / len(marks)


scores = ["72", "85", "90"]
print(average_marks(scores))

It crashed with this:

Traceback (most recent call last):
  File "buggy.py", line 9, in <module>
    print(average_marks(scores))
          ~~~~~~~~~~~~~^^^^^^^^
  File "buggy.py", line 4, in average_marks
    total = total + m
            ~~~~~~^~~
TypeError: unsupported operand type(s) for +: 'int' and 'str'

(I shortened the file paths. Everything else is as Python printed it.)

Here's the reading routine, in order:

1. Last line first. TypeError: unsupported operand type(s) for +: 'int' and 'str'. Translation: you tried to use + between an integer and a piece of text.
2. Then the bottom-most line of your own code. That's total = total + m, line 4. The ~~~~^~~ markers underline what Python is complaining about.
3. Ask which two values are involved. total started as 0, an int. m is one item from marks. Look at where scores is defined: "72", with quotes. Text.
4. Form a guess before you ask anyone. "The marks are strings, so I have to turn them into numbers."

Now, and only now, go to the AI. Don't paste "fix this". Paste your guess:

My function crashes with TypeError: unsupported operand type(s) for +: 'int'
and 'str' on `total = total + m`. I think the items in the list are strings
because they have quotes. Is that right, and what are my options for dealing
with it? Don't write the whole function.

That prompt takes thirty seconds longer and gets you a conversation about the difference between converting at the start and converting inside the loop, instead of a pasted patch. It also means the next TypeError takes you ten seconds, not ten minutes.

How do you check the AI's code is actually right?

Never treat "it ran" as "it's correct". This fix runs too, and still has a problem:

def average_marks(marks):
    total = 0
    for m in marks:
        total = total + int(m)
    return total / len(marks)

Call it with an empty list and you get a ZeroDivisionError, because len(marks) is zero. It fixed the bug you reported and left one you didn't ask about.

So before you accept any code, write the checks first. Here's the version I ran, with three checks and one deliberate guard:

def average_marks(marks):
    if not marks:
        raise ValueError("no marks given")
    total = 0
    for m in marks:
        total = total + int(m)
    return total / len(marks)


# Checks written BEFORE trusting the fix
assert average_marks(["72", "85", "90"]) == 247 / 3
assert average_marks([10]) == 10
try:
    average_marks([])
except ValueError:
    print("empty list rejected")

print(round(average_marks(["72", "85", "90"]), 2))

Output:

empty list rejected
82.33

The 247 / 3 isn't magic. I added 72, 85 and 90 by hand first, then wrote the check, so the test doesn't just repeat the code's own logic. That's the habit: work out one answer on paper, then make the code agree with you. An assert that compares the function to itself proves nothing.

For every exercise, write three checks: a normal input, the smallest input, and an input that should fail. Ask the AI afterwards, "what inputs could break this that my checks missed?" That's a good question for it, because finding holes is cheaper than writing flawless code.

If the AI also writes the tests and the code in the same message, you've lost the independence that makes a test worth anything. Write at least one check yourself.

What small projects should a beginner build?

Pick things small enough that you could finish in one sitting and that have an answer you can verify. Roughly in this order:

For each one, the AI's job is the same: help you break it into steps, give hints when you're stuck, review the finished thing. Yours is typing every line.

When you finish, ask the model to review your code and list three things a more experienced person would change, then change one yourself. Don't paste the improved version wholesale. If you want a bigger, real-world first build once you're past these basics, Claude Code for non-coders walks through a full small tool, though it leans on the AI far more than this routine does.

How do you ask for hints instead of answers?

Hints come in sizes. Ask for the smallest one first and escalate only when needed.

Level 3 is the sweet spot. A parallel example forces you to transfer the idea, which is the actual skill. Level 5 is allowed; it just has a price: close the file, wait a day, and rewrite it without looking.

What does the AI get wrong when you're learning?

You can't judge what you don't know yet, which is the central problem of learning from a model. A few things to watch for, none of which I'm claiming as statistics, just patterns worth checking:

• Invented functions and library options. If a method name looks unfamiliar, look it up in the official docs for the language (docs.python.org for Python) before using it. The hallucinations lesson covers why this happens.
• Old advice. Tutorials and libraries change. Check the version you're using (python --version) and mention it in your prompt.
• Overbuilt answers. You ask for a loop and get classes, type hints and error handling. Ask "the simplest version a beginner would write".
• Confident explanations of things that are subtly wrong. The cure is to run small experiments. If it says "lists are copied when you assign them", test that in the REPL.

For the habit to stick, keep a running file of things the assistant got wrong. After a month you'll have a personal list of failure modes, which is more useful than any general advice. It also lines up with the patterns in vibe coding anti-patterns, where accepting AI error diagnosis without checking is item nine.

When should you stop using the AI for a problem?

Here are three signals that you've leaned too hard:

1. You can't explain your solution line by line without looking at it.
2. You've asked about the same concept four times. Close the chat, open a blank file and rewrite the last exercise cold.
3. A new problem of a familiar type takes you as long as the previous one. You're not getting faster, so you're borrowing the AI's skill instead of building yours.

A simple schedule that works for many learners: write the first attempt with no AI for a fixed time (say 20 minutes), then use hints, then review. As you improve, lengthen the no-AI window. This is a rule of thumb, not a result from a study.

How does this fit with a course or a roadmap?

An assistant is a poor curriculum designer. It follows your lead, and a beginner doesn't know what to lead with. Use a structured source for the order of topics and the AI for the in-between moments: the exercise you can't crack at 11pm, the error you can't parse, the review of your finished code.

If your goal is a job, the sequence matters. Fundamentals first, then projects, then the AI-specific material. The AI engineering roadmap for Indian developers sets that out for people who already code, and AI portfolio projects that get interviews is the next step once you can build things on your own. For better prompts in general, prompting for coding is the companion piece. The principles behind a good setup prompt are in the common prompting mistakes lesson.

A one-week plan to try

• Day 1: Paste the tutor prompt. Do three small exercises, typing everything.
• Day 2: Re-do one of them from a blank file with no AI. Note where you got stuck.
• Day 3: Cause three errors on purpose. Read each one yourself, write your guess, then check it with the AI.
• Day 4: Write the asserts for a new function before writing the function.
• Day 5: Build the word counter. Hints only, no answers.
• Day 6: Ask the AI to find inputs that break your word counter. Fix them.
• Day 7: Explain the whole week's code aloud, line by line. Where you stumble is next week's topic.

Do that and you'll have written, broken and fixed more code in a week than most learners do in a month of pasting.