Following is not deciding
A tutorial has made every decision for you: the architecture, the library, the naming, what to do when it breaks. Those decisions are the job. Typing the code the instructor already wrote practises none of them, and the feeling of understanding that comes from watching it work is entirely real and entirely misleading.
The escape
- Watch the tutorial once. Then close it and rebuild from memory. You'll be stuck within four minutes — that stuck point is the first thing you actually didn't know, located precisely.
- Change the requirements. Build the same thing with a different feature, a different data source, a different constraint. Now you have to think.
- Build something nobody has made a tutorial for. Even if it's small, even if it's ugly. Especially if it's ugly.
- Read errors, don't paste them. The error message is the language telling you what's wrong. Skipping it is skipping the lesson.
The AI version of tutorial hell is worse
Asking an assistant for the code, pasting it, and watching it work is tutorial hell with the last friction removed. It compiles, it runs, and you have learned nothing at all — but faster, and with more confidence, which makes it more dangerous rather than less.
Used well, though, it is genuinely excellent: ask it to explain *why* your code is wrong, to review what you wrote, to ask you questions about a codebase. The rule is the same as everywhere else — you must produce something before you're allowed to see the answer. See the generation effect.