The Problem
TeachSim taught me LangGraph because the bot had to actually work, with real conversations running through it. GitHub Digest taught me about silent failure modes the same way, by breaking quietly until I went and figured out why. Both stuck because I needed the concept to function, not because I sat down and studied it first.
I already tried the conventional route once. (It probably applies to everything I do and learn throughout my life.) I opened Anthropic's own intro course for Claude Code, the official one, and gave up a few lessons in having retained almost nothing. Nice material, no stakes, nothing to actually break, so nothing stuck.
I want to go deeper into AI engineering now, not just orchestration around an API. Fast.ai for the fundamentals, then something heavier for the practitioner-level material. And I caught myself about to repeat the exact same pattern: open a course, start at lesson one, hope the urgency turns up eventually.
The Discovery
GitHub Digest is supposed to surface tools I wouldn't find by scrolling GitHub Trending. It's already done that for real: RTK, sst/opencode, playwright-mcp, and a course called AI Engineering From Scratch all came out of the pipeline, not a deliberate search.
The course is the part that actually got to me. I've shipped two production-ish projects on Claude Code and OpenCode, and the entire depth of my knowledge of either tool is "enough slash commands and CLAUDE.md conventions to get something running." I've never deliberately learned MCP, skills, subagents, hooks, plugins, or checkpoints. I just use whichever tool happens to work that day.
Stacking real ML fundamentals on top of that felt like a bad idea. I'd be fighting the tools and the material at the same time.
The Setup
Two machines, two networks I switch between. Claude Desktop with filesystem access is the constant supervisor on both: it reads the actual files, checks claims against source, catches scope creep before anything ships. OpenCode, tunneled to a small VPS running DeepSeek through OpenRouter, and the Claude Code VS Code extension are the interchangeable workers that do the typing.
I'd been treating both workers as interchangeable without understanding what makes them different underneath. That's the actual gap.
The supervisor role isn't theoretical, either. Yesterday's task started with the usual pre-flight check: start the tunnel, confirm it's up, then begin. Partway through, OpenCode, running on DeepSeek, killed the tunnel itself and took the whole pipeline down with it mid-task. Claude Code hasn't done anything like that so far. I've now got a "don't touch the tunnel process" rule that only applies to OpenCode, which is a guardrail I built by getting burned, not by reading ahead to Phase 4.
The Plan
Eight phases was designed pulling from three resources, claude-howto, Anthropic Academy's official course catalog, and opencode.school, none of those orderings made sense to follow as is so the curriculum runs on its own sequence instead:
| Phase | Theme |
|---|---|
| 0 | Foundations (a self-check, not a lesson — already know this) |
| 1 | MCP — extend what the agent can reach |
| 2 | Skills — formalize what it now knows how to use |
| 3 | Subagents — split work across multiple agents |
| 4 | Hooks — add guardrails before something destructive happens |
| 5 | Plugins — package it all into one install |
| 6 | Checkpoints — undo a bad session without losing real work |
| 7 | Final Results |
Each phase, I get to pick: solve a real problem in one of my live projects, or build against a notable open-source project picked because it's a strong production example, not a toy demo. For Phase 1, the real-project version is wiring GitHub's MCP server into GitHub Digest instead of hitting the REST API directly. The open-source version is installing playwright-mcp, Microsoft's own browser-automation server, and pointing it at something real.
I haven't done either yet. This is a design brief for a course I'm about to do slowly. The rule I'm holding myself to is that a phase isn't done when I've read about it, it's done when it produces a real fix in one of my actual projects.
Why MCP First
It's the one concept every later phase either uses or assumes you've used. Skills often wrap MCP calls. Subagents delegate to MCP-equipped agents. Hooks govern what an MCP server is allowed to touch. Start there and everything later has something concrete to point back at.
It's also the most demonstrable. Watching an agent drive a real browser for the first time is something you see happen. A permission setting from Phase 0 is correct and completely invisible. If I want this to survive contact with my own attention span, the visible payoff has to come first.
What's Coming Next
Skills, subagents, hooks, plugins, checkpoints, in that order, against real projects wherever I can manage it. After that's the actual point: Fast.ai, then the heavier material, with the tools already out of the way instead of competing for attention with the harder stuff.
Closing Thought
The bet is that learning the tools you already use makes you slower before it makes you faster. I could open OpenCode right now and ship something without understanding half of what's available to it. Spending real time on this first is a trade: less momentum this month for not relearning the same tool friction later, while I'm meant to be thinking about something harder. I'll find out if that's the right call once I've actually started.
This is part of an ongoing series: TeachSim, GitHub Digest, and now the plan for the tool-mastery work sitting underneath the next phase of learning AI engineering properly.
Find me on GitHub: github.com/mediblacksand