Devpuff
Pricing
Log InStart Free
  1. Home
  2. Blog
  3. How to use ChatGPT to learn coding, not to avoid it
Artificial Intelligence

How to use ChatGPT to learn coding, not to avoid it

Using ChatGPT to learn coding works or wastes your time depending on how you prompt. Here is the test that tells you which one you are doing.

By Max Arthur
Co-Founder & Content Marketer·August 11, 2026·7 Min read
Two prompting paths from the same problem, one producing a finished answer and one producing an explanation followed by a practice attempt

You can learn faster with an AI assistant than without one, and you can also use it to produce working code while learning nothing. Both feel identical while you are doing them. That is the actual problem, and it is not solved by willpower or by a list of good prompts.

It is solved by a test you can apply afterwards: could you write this again tomorrow, with the tab closed? If the answer is no, you produced code rather than learned something. That is fine when you needed the code. It is a problem when you thought you were studying.

The research is more specific than the debate

The public argument treats AI as one thing you either use or avoid. A 2023 study of novices learning to program with LLM help found that framing is wrong: what mattered was how people prompted, not whether they did.

The study sorted learners into four approaches: single-prompt generation of a whole solution, step-by-step decomposition, a hybrid of their own code and generated code, and manual coding with no assistance. The result is worth reading twice. The paper reports that the AI Single Prompt approach "resulted in the highest correctness scores on code-authoring tasks, but the lowest correctness scores on subsequent code-modification tasks."

So the approach that looked best was the approach that left people least able to change the code afterwards. It won the task and lost the skill.

That is the sharpest available description of what going wrong looks like, and it is measurable: you can write it, and you cannot modify it. Modifying code is most of the job.

Four patterns that teach

These share one property. The model does work that is not the work you are trying to learn.

Explain, then quiz me. Ask for the concept without the solution, then ask to be tested on it.

Explain how JavaScript closures work, using a counter example. Do not solve my problem. Then ask me three questions about my code and wait for my answers before telling me if they are right.

The final clause matters. Without it, models tend to ask a question and answer it in the same breath.

Rubber duck in reverse. Explain your plan and ask for holes in it.

Here is how I plan to structure this feature, in my own words. What have I not thought about? Do not write the code.

You do the thinking; it does the review. This is close to what a good code review gives you, available at 2am.

Constrain it to a hint. When you are stuck, ask for the smallest possible nudge.

I am getting this error. Tell me which line to look at and what concept I am missing. Do not give me the fix.

Ask it to review what you wrote. After you have a working version, not before.

Here is my working solution. What would a senior developer change, and why? Rank the suggestions by how much they matter.

The ordering is the point. Reviewing your code teaches you something; being handed code to review teaches you much less, because you never held the problem in your head.

Three patterns that quietly do the work for you

"Write me a function that..." This is the single-prompt approach from the study. It produces correct code and the weakest retention. There is nothing wrong with it when you need output, but it is not studying.

Pasting an error and taking the fix. Debugging is a skill built by practice, and this replaces the practice. Read the error yourself first and form a hypothesis, even a wrong one. Then ask. A wrong hypothesis you corrected is worth more than a right answer you were handed.

Accepting an explanation you cannot check. Models state wrong things with the same confidence as right things. An explanation you cannot verify is not knowledge, it is a rumour you now believe. Run the code, or check the documentation, especially for anything version-specific.

The same task, both ways

Take a small, real task: remove duplicate values from an array.

The way that produces code. You ask for a function that removes duplicates. You get one, probably using a Set. You paste it in, it works, you move on. Elapsed time, about forty seconds. Tomorrow you know that "there is a Set trick" and could not write it unaided.

The way that produces skill. You try it yourself first, probably with a loop and an includes check. It works. Then you ask what a more experienced developer would do differently and why. You learn that Set stores only unique values by definition, and that checking membership in a Set is much cheaper than scanning an array for every element. Now you know a data structure, not a snippet, and you will recognise the next problem it solves.

Elapsed time, about ten minutes. The second version is slower on this task and faster on every later task that resembles it. That trade is the entire decision, and it is worth making consciously rather than by default.

The tell that you are in the first mode is that you could not explain, without looking, why the code works. If you can explain it, the speed cost you paid was not wasted.

The retrieval check, concretely

The test at the top of this page is easy to nod at and easy to skip. Here is a version with edges:

  1. Finish the task with whatever help you used.
  2. Close every tab.
  3. Wait until the next day.
  4. Write the same thing again from a blank file.

What you can reproduce, you learned. What you cannot, you copied. Do this on your own for the first week of any new topic and you will have an accurate picture of your real level, which is worth more than the feeling of progress.

There is a cheaper version for when a day is too long to wait: after generating something, delete it and retype it from memory, then compare. It catches the difference between "I read that and it made sense" and "I can produce that", which is the gap that surprises people in interviews.

When to close the tab

Two situations where the assistant is the wrong tool.

Anything version-specific. Frameworks change faster than training data settles. A confident answer about a library's current API is one of the least reliable things you can ask for, and the official documentation is both faster and correct. This is the same failure mode that makes vibe coding break in specific places.

The first hour with a new concept. Struggling is not wasted time, it is the mechanism. An assistant that removes the struggle in minute two removes the learning with it. Give a genuinely new idea an honest attempt before asking, then ask well.

The part that decides it

Nothing here depends on which model you use or how you word things. It depends on whether you are the one doing the thinking on the thing you are trying to learn.

An assistant is very good at the work around the work: explaining a concept a second way, reviewing what you wrote, generating practice problems, translating an error message into English. It is also very good at producing the exact artefact you were supposed to produce yourself, and it cannot tell the difference between those two requests. Only you can.

Use it deliberately, apply the retrieval check honestly, and the tool makes you faster. Use it by default and you will end up in the position the study measured: able to produce code you cannot change. If you are weighing up what that means for the career side of this, will AI replace programmers covers the evidence.

Want somewhere to practise where the answer is not one tab away? Start with a track and write the code yourself first.

Keep reading

More from the blog

Two similar package names side by side, one with millions of weekly downloads and one with single digits
August 8, 2026·7 min readArtificial Intelligence

AI hallucinations in code, and how to catch them

An AI hallucination in code is rarely gibberish. It is a package name that sounds real, and every plausible-but-wrong one tested was already on npm.

Read more
Two diverging projection lines over the same decade, one rising for software developers and one falling for computer programmers
August 5, 2026·8 min readArtificial Intelligence

Will AI replace programmers? An honest answer

Will AI replace programmers? No. The same agency projects developers up 15 percent and computer programmers down 6 percent over one decade.

Read more
{ }
✦

Ready to write some code?

Put this into practice - start your first free lesson. No setup, no credit card.

Start learning free
Devpuff

Learn to code by doing. One tiny, playful lesson at a time.

Learn
ProgramsCoursesPricing
Company
AboutBlogResourcesAffiliates
Support
Help CenterContactStatus
Programs
Frontend DevelopmentFull-Stack DevelopmentPython Developer
Courses
Advanced ReactAsync JavaScriptAsync PythonCSS BasicsCSS LayoutDSA Basics
Learn to Code
Learn JavaScriptLearn PythonLearn SQLLearn HTMLLearn CSSLearn ReactBrowse All Topics
Platform Comparisons
Devpuff vs CodecademyDevpuff vs MimoDevpuff vs Sololearn
© 2026 Devpuff. All rights reserved.Privacy PolicyTerms and ConditionsCookies PolicyRefund Policy
Devpuff vs freeCodeCamp
Read All Comparisons