There is a huge difference between passively reading a tutorial and actually typing in commands or code from it into your terminal. And there is an even bigger difference between doing that and inverting the approach completely - attempting to solve the problem first, and only then reading about the available solutions.

I don’t know if there is an official term for it, but this style of learning wires something in your brain, both deepening understanding and making the knowledge more durable. Plus, it teaches you the meta-skill of adapting only partially suitable solutions to the actual problem you’re facing.

But you only benefit from it if you do things actively and with your own hands. Watching an agent scaffolding a project or chasing a bug doesn’t do the trick. I’d argue that it’s actually no different from passively reading a post on how someone else did it. The same pitfall - it only gives you an illusion of understanding. But it feels productive until it’s not.

Tutorial hell is a well-known gotcha, and I expect people to soon start talking about another yet very similar gotcha - overreliance on agents during learning. Both are caused by wasting time passively reading about someone else’s experience or watching someone else doing the job.

But learning by doing is hard! The less experienced you are, the harder it is to come up with a problem that would be solvable yet challenging, realistic yet structured, and self-assessment is virtually impossible until you reach a certain proficiency level.

First of all, learning should be hard. If it’s not hard, you’re not growing. However, it doesn’t mean that you shouldn’t use help. iximiuz Labs’ hands-on challenges were added as a learning format to address exactly these issues.

Each challenge presents you with a realistic problem: troubleshoot a failing daemon, configure Internet connectivity via a NAT gateway, forward a port from one VM to another, build a container image for a Node.js application, etc. The challenge also places you in a Linux playground configured to verify completeness. And you’re expected to make all the checks pass by running whatever commands you can think of in the playground’s terminal.

Focusing on the outcome is particularly important here. Instead of checking the exact steps to solve a problem, only the final result is assessed. There is always more than one way to crack a real-world task, and preserving the freedom of choice during the learning phase helps you better prepare for the job.

Of course, challenges come with hints and editorial solutions. But I recommend opening hints only if you’re stuck for too long, and checking the editorial solution only after you already solved the challenge - mainly to see if there is an alternative or more efficient approach.

What to do and what not to do when solving a challenge?

First of all, unless your goal is to learn how to use agents or other AI-powered tools, do not use them to solve a challenge. You will learn nothing. Instead, take some time to think about the problem. Research solutions. Type commands in the terminal, crash the playground, restart the challenge as many times as needed. Come join our Discord server and post your thoughts on the problem, ask clarifying questions - we’ve got a whole community of like-minded engineers, all going through the same learning journey.

Talking to ChatGPT or Claude while solving a challenge is perfectly fine and even encouraged. But do not copy/paste the challenge into the chat asking for a solution - it’d be no different from tasking an agent with it. Instead, treat it as “dynamic man pages”, a rubber duck, or a tireless conversation partner. Take everything it outputs with a grain of salt and cross-check it in the terminal and other sources.

And if your goal is to learn how to use agents, or compare Claude Code, Codex, OpenCode, and Pi, or try a fancy AI SRE tool to see how good it is at troubleshooting Kubernetes clusters, iximiuz Labs’ challenges are a perfect fit, too. Just don’t mix it with learning the foundational tech (Linux, containers, Kubernetes, networking). There should always be one learning target. Otherwise, there is no stable ground, and it’s the fast lane to getting lost - you should always be able to tell exactly what knowledge gap you’re currently covering.

What's next? Try learning by solving our hands-on challenges - there is over 200 already and counting! labs.iximiuz.com/challenges​