There has never been a faster way to produce code that works than to ask an AI for it. There has also never been a faster way to end up with a program you can't understand, can't debug, and can't extend — because the AI wrote it and you just pressed paste. If your goal is a quick demo, that's fine. If your goal is to actually learn to code, it's a trap, and it's worth being clear about the difference.
Two different goals
Using AI to produce code and using AI to learn code are different activities that happen to look alike. The first optimises for a working output right now; you don't need to understand it. The second optimises for you understanding — so that next time, and the time after, you're the one who can build it, fix it, and reason about it. Both are legitimate. This is about the second, because that's the one that makes you a programmer rather than a person who owns a program.
The distinction matters because the industry is currently full of people discovering, painfully, that a folder of AI-generated code they don't understand isn't an asset — it's a liability with a deadline. Understanding is the thing that doesn't come for free, and it's exactly the thing AI will skip for you if you let it.
How to actually learn with it
The good news: the same tool that will happily do your thinking for you is, pointed correctly, one of the best coding tutors ever made. The trick is to make it teach rather than deliver.
Make it a tutor, not an autocomplete. Brief it: "Act as a coding tutor. Don't write the solution for me. Give me hints, ask what I've tried, and let me write the code." Now it's coaching you instead of replacing you.
Write it yourself; use AI to review. Invert the usual flow. You write the code, then ask the AI to review it — "what's wrong with this, what would you improve, what am I not seeing?" You get the feedback of a senior engineer without outsourcing the part that builds the skill.
Interrogate every solution. When it does show you code, don't just run it. Ask: "Why this approach? What are the alternatives and their trade-offs? What input would break this?" The answers are where the real learning is — that's the reasoning a good developer carries in their head.
Debug Socratically. Instead of "fix my bug," try: "Here's my code and the error. Don't fix it — ask me questions to help me find it myself." Debugging is most of real programming, and learning to do it is a skill you cannot paste.
Never run what you can't explain. The one rule that protects you from the whole trap. If you can't say, in plain words, what a line does and why it's there, don't ship it — ask until you can. Slower today, and far faster for the rest of your career.
Syntax is the easy part
Here's the deeper reason understanding matters, and the thing AI most tempts you to skip. Programming languages come and go, and their syntax is genuinely the easy, memorisable, look-up-able part — the part AI is best at and you need least. What makes someone good is the layer underneath: how computation actually works, how to choose the right data structure, why one algorithm is fast and another crawls, what can and can't be computed at all. That's the part that transfers across every language and every tool, and it's precisely the part a copy-paste habit never builds.
That's what the Computer Science node in the library is built to teach — not "here's the syntax for a loop," but the ideas that let you think like a programmer: Turing and what computation even means, algorithms and complexity, the famous open problems, the craft of getting a program provably right. With AI as the tutor and those ideas as the curriculum, you build the understanding first — and then the syntax, and the AI's help with it, actually pays off.
Learn to code, not to paste. The AI can carry the typing; make sure you're the one carrying the thinking.