I recently asked AI to explain the different types of databases to me.

It explained that relational databases are useful for certain kinds of data, time-series databases are useful for other kinds of data, and key-value databases are good when you need to quickly retrieve a value using a key.

The explanation made sense. I felt like I understood it.

Then I asked AI to quiz me.

One question described a system that needed to quickly retrieve a user’s login session using a session ID. I chose a key-value database because the session ID sounded like a key, and the session data sounded like a value.

I may have arrived at a reasonable answer, but I realized that my reasoning was shallow. I could recognize a pattern from the explanation, but I could not confidently explain why the other database types were insufficient. I understood the concepts in isolation, but I did not yet know how to apply them to a real situation.

That gap reminded me of a problem I, and I'm sure many other developers, used to experience before AI - tutorial hell.

I would watch tutorials or read documentation about tools like Next.js and Docker. By the end, the material felt familiar. I could recognize the terminology and follow the examples. But when I eventually had to use the tool myself, I would discover that I did not know what to do.

This is the trap commonly called tutorial hell.

A new version of tutorial hell

The traditional version of tutorial hell involves endlessly watching tutorials, taking courses, reading documentation, or collecting notes without building anything.

AI makes the trap more comfortable.

Instead of watching another tutorial, I can ask AI to explain the topic in a different way. I can ask follow-up questions, request examples, and keep going until the explanation feels clear. Since the interaction is conversational, it can feel more active than reading documentation.

However, it is still possible to remain passive, and it's not because the explanation is wrong. Rather, the problem is that understanding an explanation is not the same as being able to apply and use the idea independently.

I can recognize what a key-value database is. That does not necessarily mean I can choose a database for an unfamiliar system and explain the trade-offs. I can follow an Express.js tutorial. That does not necessarily mean I can build an API with Express.js when the tutorial is no longer telling me what to do.

This creates an illusion of competence where I feel like I am learning because I am receiving information and understanding it in the moment. But the real test comes when I have to make a decision, write the code, or troubleshoot a problem without being led.

Start with what you want to do

As of late, I think that learning should begin with a question:

What do I want to be able to do with this knowledge?

For example, why am I learning Express.js?

Maybe I am preparing for an interview and need to understand its concepts. In that case, reading the documentation and asking AI to quiz me may be appropriate.

But what if, instead, I want to build an API with Express.js. That requires a different kind of practice. In this case, I should define a small project and try to implement it.

I could ask AI to specify a simple project and scaffold the tests, but I would write the implementation myself. I would need to figure out how to initialize the app, declare routes, parse request bodies, and handle the relevant Express.js behavior.

The important thing is that the exercise should require me to perform the competency I am trying to develop.

Make the struggle deliberate

Building something with a tool is harder than reading about the tool. It involves uncertainty, failure, and decisions that tutorials often make for you.

That struggle is uncomfortable, so it is natural to avoid it. We gravitate toward activities that minimize discomfort: another explanation, another course, another example.

However, I'd like to emphasize that not all struggles are equal!

My current rule is this:

Keep the difficulties that directly exercise the skill you are trying to learn. Delegate the difficulties that merely enable the exercise.

If I am trying to learn Express.js, declaring routes is a deliberate difficulty. Initializing the application is a deliberate difficulty. Parsing a request body is a deliberate difficulty.

Building a frontend client to call the API may be incidental. Styling the client is probably incidental. Choosing whether to use an in-memory store or a database may also be incidental if my goal is specifically to learn Express.js.

Those decisions may still matter in a real project. They are just not necessarily the capability I am trying to practice in that particular exercise. I can use AI to help with them so that I can focus on Express.js.

The boundary changes depending on the goal. If I am learning database selection, then choosing between an in-memory store, a relational database, or a key-value database becomes the deliberate difficulty. If I am learning Express.js, the same decision may be incidental.

Use AI as a coach

This does not mean I should avoid AI while learning.

I am experimenting with using it as a coach rather than as a replacement for the work.

When I get stuck, I want to ask questions first instead of immediately requesting the solution. Being forced to come up with an answer can expose gaps in my mental model. It also gives me a chance to practice reasoning through the problem.

I also set a struggle timer. For example, if I cannot figure something out after 40 minutes, I can ask AI to show me the solution. At that point, getting the answer is not necessarily a failure. I have already attempted the problem and identified where I was stuck.

The important part is what happens afterward.

A few days later, I try the problem again. I remember the parts I struggled with previously, and I pay attention to whether I can get through them independently or with less guidance. If I can, then I have some evidence that I learned something. Instead of merely recognizing the solution that AI gave me, I become more capable of producing it on my own.

Get your reps in

I do not think one successful project is enough to prove that I understand a technology.

A single project may be completed through rote memorization, lucky guesses, or heavy assistance. Repeated exposure to different situations is what helps me determine whether I can transfer the knowledge.

For database selection, that might mean working through multiple scenarios and explaining not only why one database fits, but why the alternatives are insufficient.

For Express.js, it might mean building several small APIs with different requirements instead of following one large tutorial from beginning to end.

The goal is not to eliminate AI assistance completely. The goal is to need less assistance with the parts that matter.

I am still figuring out this process, but this is the simplest way I can think of to express my current learning model:

Struggle is needed to learn something, but make sure your struggles are deliberate.

Tutorials and AI explanations are useful for building an initial understanding. But if I want to become capable of using a tool, I eventually need to stop consuming explanations and start creating situations that require me to apply the knowledge.

That is how I am trying to escape tutorial hell: define what I want to be able to do, struggle with the parts that develop that ability, delegate the incidental work, and get my reps in.