I was on a trail the other and somebody had left a note for everyone passing through: "Use AI at your own risk."

I found it funny at the time. But it's also a good message to keep in mind. I remember when AI first started showing up and it felt like everything was suddenly possible — while at the same time there was all this concern about jobs disappearing and everything else that comes with a big shift. I'm not here to tell you what's going to happen in the future. Who knows. What I want to think about is how to use AI with a bit of intention, and still get all the good stuff out of it.

A little example. Not long ago my sister and her husband opened a restaurant, and she asked if I could build them a website — menu, the usual stuff. I'd built websites before and this one was pretty straightforward, so I decided I'd use it to practice my Next.js skills, something I'd only been exposed to once. Knowing I had AI on my side, I started the project.

The timeline was short. I quickly realized I wasn't going to be able to properly study every concept I needed to ship this website in time. But the website got shipped, no problem. How? I mean, that's pretty easy to figure out. Yes, I used AI. Heavily.

Was I happy with how the website turned out? Yes, pretty much. Did I actually learn any Next.js? Not at all. It did all the job for me — I was just prompting it. The design was mine and I knew what I wanted, so that part was me, and it definitely accelerated the process. But none of that helped me get or solidify any knowledge.

And that's what I think people get wrong about AI. Sure, it made building so easy that anyone can do it with no real effort. But AI didn't remove the need to understand things. It removed the need to understand things in order to produce output — and those two got confused.

Does it actually matter that I didn't learn?

Earlier this year, Anthropic ran a study on 52 developers, mostly juniors, all with at least a year of Python experience. The task was to learn a new library (Trio, for async programming) that none of them had used before. Half were given AI assistance, half worked without it. Everyone took a comprehension quiz afterwards.

The AI group scored an average of 50% on the quiz. The no-AI group scored 67% — a 17-point gap, roughly two letter grades. And here's the kicker: the AI group didn't even save meaningful time. The productivity gain wasn't statistically significant, because so much time went into writing prompts and reading responses. (Study here.)

A separate study — Bastani et al. at Wharton, on nearly 1,000 high school math students — found something similar. Students using unrestricted ChatGPT scored 48% higher on practice problems while they had access. But once the access was removed and they had to work on their own, the same students scored 17% lower than students who had never used AI at all. (Study here.)

Two very different setups, similar direction of results. Using AI to do things for you affects your ability to do those things on your own later. People who lean on AI without engaging with the problem never develop the skills the problem was there to build in the first place.

Not all AI use is the same

Now — should we then not use AI? No. We don't have to choose. But we do have to use the tool properly.

Here's the more interesting part of the Anthropic study. The researchers didn't just compare AI vs no-AI — they looked at how people used AI, and grouped participants into six interaction patterns. The low-scoring patterns all averaged under 40% on the quiz. The high-scoring patterns averaged 65% or higher.

The low-scoring patterns all had something in common: they used AI to do the work and skipped the friction. AI Delegation was the clearest version — hand it all to AI, ship fast, fail the quiz. Progressive Reliance and Iterative Debugging looked more engaged on the surface (a few questions, some debugging), but ended in the same place: leaning on AI for the actual thinking.

The high-scoring patterns all did the opposite — they used AI, but they made themselves stay in the driver's seat. Generation-Then-Comprehension and Hybrid Code-Explanation always paired code with an explanation and slowed down to understand it. And the best of them was Conceptual Inquiry — asking about the concept, not the answer. This group never asked for generated code at all. They hit errors and solved them themselves. They were the second-fastest overall — only the pure delegation group beat them — and they were the largest cohort in the entire study. Seven people out of the whole AI arm figured out how to use the tool without letting it think for them, and they were rewarded for it in both speed and understanding.

You might argue the sample sizes are small and don't prove much on their own. Fair. But the patterns hold across studies, and the developers themselves reported the same thing: they felt lazy, skipped reading the docs, noticed gaps in their understanding. That's exactly how I felt building my sister's website. Everything worked, and I could kind of guess how it worked — but I definitely had gaps, and I didn't understand the technology the way I should have.

So the tool isn't the problem. It's how you're holding it. And I'll admit — I'm the first one guilty of delegation, because sometimes I want the easy solution even when I know it's not good for me long-term. Yes, Next.js is on the list of things I need to sit down and actually learn.

So what do I do differently now?

I was pretty sick of following tutorials for projects I didn't care about and not seeing real progress. It's not the tutorials' fault — the people who make them do a great job explaining core concepts. I'd just seen so many of them, and I was annoyed with myself that I wasn't moving forward.

So I started a big project I'd wanted to do for a long time, and I decided that instead of having AI do the heavy lifting, I'd treat it as a learning opportunity. This project matters to me. I want to understand how it works. I want to make my own design decisions. I want to know how all the inner parts connect.

I knew a bit of React going in — I'd followed tutorials and built websites with it before, but never to the point where I really understood how it works or how it's supposed to work. So that's where I started. I decided I'd consult AI on every decision, have it contradict or challenge my ideas, tell me the trade-offs, review my code and tell me how to improve and structure it.

When I hit a new concept or something unfamiliar, I ask what it does and why it's needed in that situation. If I'm still unsure, I ask how it's supposed to work code-wise, and then try to write it myself. If I'm unsure about syntax, I ask for a documentation reference and go read that section.

At some point I found myself enjoying reading documentation. A side effect I wasn't even hoping for.

Even when I'm stuck, my head hurts, and I just want a simple solution — I still don't accept finished code. I try to identify why it's hard, what specifically I'm not getting, and then go through it again.

And here's the fun part: forming a hypothesis about why something doesn't work, bringing it to AI, and being all hyped up about something I figured out. Sometimes I'm right. Sometimes partially right. Sometimes not even close. But it makes you think like a developer, trying to solve the problem, which is an invaluable skill to have. Nobody knows all the answers. The gem is not being discouraged when you don't — it's just something you'll figure out.

AI is still involved in this. A lot. Because when you don't have anyone to help you figure things out — and you will get stuck, a lot — it means you're not alone. You have something to correct you and point you in the right direction.

A prompt you can try

Here's the prompt I use, if you want to try it yourself:

You are my coding tutor, and I'm learning by building a real project. Your job is to help me understand, not to build it for me. Follow these rules:
1. Don't give me code. When I'm stuck, explain the concept in plain language — use analogies and examples. Let me write the actual code myself.
2. Concept before implementation. Before we build a feature, explain the idea behind it and why it works, so I understand the reasoning, not just the syntax.
3. Make me try first. For anything I could reason out myself (logic, structure, language features), make me attempt it before you explain. Don't accept "I don't know" as an answer — re-explain a different way and push me to try again. A wrong attempt is useful; it shows you where my understanding actually is.
4. But just tell me the un-guessable stuff. For things I can't derive — external API details, library specifics, syntax I've genuinely never seen — explain them directly instead of making me guess.
5. Ask before assuming. If my request is ambiguous, ask me a quick clarifying question instead of guessing what I meant.
6. Protect me from scope creep. When I get excited and want to build something that depends on things I haven't built yet, flag it and help me note it for later instead of derailing.
7. Hold the map. Keep track of where we are and what's next, so I can focus on the step in front of me.
Tell me when I'm doing well and when I'm wrong — I want honest feedback, not just encouragement.

One last thing

It sounds like a lot of work, so this is my first and most important piece of advice: build something you actually care about. For me it's a library tracking app — something I desperately need. For you it can be anything, as long as you care about it. Because if you don't care enough, you'll drop it easily.

I have so many ideas and I keep writing them down, but nothing ever quite lands yet, because I'm at the beginning of it all and it takes time to figure things out — while mentally I'm so far ahead, with plans and dreams about how it's going to look down the road. And the road feels endless.

It won't feel like this forever. I know a lot of things now, and I know the next three months on this project will take me much further, because so much of it builds on the foundation and the concepts I drilled into my head early on. But the gap between how long you assume something should take and how long it actually takes is a challenge of its own.

So stick around long enough for those things to start working in your favour. You gather knowledge in little shards, until eventually you have a mosaic where every piece makes sense and you understand why it's there.

Also — follow my journey to see if I pull it off.

Best,
V