How I Use AI Without Losing the Learning

I learned to write software as an adult, going back to school in my late forties, at the exact moment AI coding tools became good enough to write a lot of it for you. That timing cuts both ways. The same tool that can explain a concept I'm missing can also hand me a working answer that teaches me nothing — and on a hard day, the second one is very tempting.

So I've had to be deliberate about it. AI is a genuine part of how I work and how I learn. It is not the reason the work exists, and it is not allowed to stand in for understanding. The line between using it and being used by it is entirely about how you reach for it.

The move that quietly costs you

The trap isn't asking AI for help. The trap is pasting in a problem, getting back code that works, dropping it in, and moving on — without ever understanding why it works.

Do that once and you saved an hour. Do it as a habit and you've built on a foundation you can't inspect. The code runs until it doesn't, and when it breaks — and it will — you're standing in front of something you never actually understood, unable to fix the thing you supposedly built. You didn't learn. You borrowed an answer and called it knowledge.

For a student, that's not a shortcut. It's a debt with a due date.

How I actually use it

The same tool, pointed differently, is one of the best learning aids I've ever had:

• Explain, don't just solve. When something's over my head, I ask it to walk me through the concept — not to hand me finished code, but to get me to where I could write it myself. The goal is to understand the answer, not to possess it.
• A debugging partner, not an oracle. When I'm stuck, describing the problem to something that talks back helps me find it, the way explaining a bug to a colleague does. But I read the reasoning; I don't just paste the fix.
• A second opinion. I'll ask for alternative approaches, or where an idea of mine might fall apart. It's good at surfacing angles I hadn't considered. It is not good at being right by default, which is exactly why I check.
• Help with the boring parts. Research, first-draft documentation, finding the one relevant paragraph in a wall of docs. Real time saved, no understanding skipped.

The rule under all of it: I verify, and I own what ships

The non-negotiable is that I check the output and understand the architecture before anything goes into what I'm building. AI is confidently wrong often enough that trusting it blindly isn't a workflow, it's a liability. It invents APIs that don't exist, writes code that looks right and is subtly broken, and will happily explain a mistake to you with total conviction.

So nothing it produces gets a pass I wouldn't give my own first draft. I read it, I understand it, I test it, and if I can't explain what it does, it doesn't ship. Whatever the tool wrote, my name is on the result — and being responsible for the code means actually understanding it, not just accepting it.

Where this leaves me

Used one way, AI lets you skip the part where you become a developer. Used the other way, it's a patient tutor that never tires of your questions, available at the exact moment you're stuck — which, for an adult teaching himself a hard thing on limited time, is genuinely a gift.

The tool is the same. The difference is whether you're using it to avoid understanding or to reach it faster. I use it to reach it faster, and I check its work every time — because the point was never to produce code. The point was to become someone who can.