A working practitioner doesn't hold a list of tutorials in their head. They hold a graph: shells beneath editors beneath build systems. Version control beneath deployment. Storage beneath networking beneath the distributed systems on top. Every advanced topic rests on supporting skills, and every supporting skill becomes the foundation for something harder.
This shape isn't a new observation. University catalogs have modeled prerequisites for decades. Roadmap sites visualize the web. What's missing isn't the map. It's a place to actually do the work the map points at — and infrastructure that keeps the work valid as the tools shift underneath it.
What a practitioner carries isn't a list of facts. It's judgment. Judgment is the sense of which approach fits a situation. It's the eye for which design won't survive its first scale event. It's the habit of reading what an error message means rather than what it says. Judgment is what separates someone who can follow a tutorial from someone you'd trust with production.
Judgment forms through a specific cycle: attempt something, get it wrong, understand why, fix it, carry the understanding forward. The mistake is the trigger. The fix is the lesson. Get something right on the first try and it's easy to mistake luck for skill.
Passive consumption can't substitute for this. Documentation helps. Videos help. An AI tutor helps. But none of them put you in the position of having been wrong, which is the position where understanding compounds.
People take real risks only when failure is cheap. When the cost of being wrong is a production outage, the rational move is to copy the config that worked last time and never experiment. Most learning environments either shelter you from failure — sandboxes, walkthroughs with no wrong answer — or expose you to its full cost. The first builds false confidence. The second builds risk aversion. Neither builds judgment.
Every wave of automation has reshaped a discipline the same way: by taking its mechanical layer off the practitioner, so the practitioner could spend that attention on the work the machine couldn't do. Calculators didn't end engineering — they took the arithmetic off the engineer's plate, freeing the engineer's attention for the design. IDEs didn't end programming. Spell-checkers didn't end writing. Each time, the chore disappeared and the larger task — the part that needed a person — expanded to fill the room.
AI is the same pattern at much larger scale. It has commoditized the mechanical layer — first-draft code, boilerplate, command recall, the act of producing the artifact rather than the judgment of what to produce. Someone with judgment can now direct it, evaluate its output, and steer it toward the right answer. Someone without judgment is in a worse position than before: wrong decisions deployed faster, with more confidence, at greater blast radius. "The tool wrote it" is not a review process. "It compiles" is not a quality bar.
Practitioners have spent decades writing the explanations, debugging sessions, and post-mortems that taught the next generation. That body of work didn't just train the next humans. It trained the machines. Every annotated config and "here's what went wrong" thread compounded into systems that can now reason about the work itself.
Those systems aren't replacements for a senior engineer — they don't have the judgment — but they're patient, fast, and available at 2am. The same body of knowledge that trained them can now be used, through them, to teach the next generation of humans faster.
Judgment built on simulators doesn't transfer. So we don't simulate. Your terminal connects to a real system; when a topic needs deeper access, you get a real machine with its own kernel.
Every lab validates the actual state of your environment, not whether you typed the right command. Multiple paths to the same outcome are valid, because in practice they have to be. Break something? Reset to the last checkpoint and try again. Failure is instant, free, and reversible.
Most lab platforms design failure out. We design it in. You'll inherit broken systems and fix them. You'll build from scratch with a working example as the target. Mistakes are the curriculum, not a thing to avoid.
Systems content rots fast. Nix flakes change. Kernel APIs drift. A debugging tutorial written eighteen months ago is often actively misleading today, and the half-life is getting shorter, not longer.
We treat course content as software with a supply chain. Every lab step is executable and tested in CI against real environments. The platform tracks upstream releases for every tool we teach. When a new version drops, the affected labs run automatically against it, and anything that breaks is flagged for human review before the next learner encounters it. Content doesn't drift quietly. It either passes or it gets fixed.
This is infrastructure-level work that nobody sees, and it's the difference between a learning platform you can trust and a graveyard of stale tutorials with a UI on top.
Each course is a deliberate arc, and the arcs link to each other: prerequisites are explicit, adjacent skills surface where they're relevant, and what you've mastered elsewhere doesn't have to be re-learned. We're not building a catalog of tutorials. We're building a connected map of what it means to be a systems practitioner.
AI sits inside the loop. When you're stuck, it helps you reason: the next thing to check, the assumption you didn't notice you were making, the question you should be asking. The work that builds judgment stays yours. Everything around it gets easier.
We start with Nix. The reasons Nix is hard to learn are the reasons LabCraft exists: documentation too terse for a new user, fragmented community knowledge, no clear path from beginner to fluent, and a tool that touches shells, package management, build systems, and OS internals at once. If we can teach Nix, we can teach the rest.
After Nix, the direction is downward — into the systems layer the cloud-native lab platforms don't touch. They stop where the cloud starts; this one is meant to go the other way. How fast and how far depends on demand.
Whether it's day one or year fifteen, the work is the same: build judgment in an environment designed for it. The platform makes that work cheaper.
GitHub, Google, or a magic link to your inbox — pick your way in.