Learning with AI

Share
Learning with AI

I wanted to learn Microsoft Agent Framework. I also knew that once I'd learned it, I'd be using AI to write code in it — like I do with every framework now. Which made the old learning order — read the docs, build toy examples by hand, bring AI in once I was competent — the wrong shape. I'd be building muscle memory for a workflow I wasn't going to use.

So I picked a target I already understood — Claude Code — and rebuilt a small version of it on top of MAF, with Claude in the room from step one. Seventeen steps, one git tag and one tutorial chapter per step. What we built is an agent harness — the layer around MAF that gives it the Claude Code feel: slash commands, plan mode, approval gates, session persistence, observability, compaction, skills, file memory, todos, sub-agents, MCP, and production-grade policy governance via Microsoft's Agent Governance Toolkit. The whole thing is on GitHub.

The interesting part isn't the agent. It's what learning with AI actually looked like when I committed to it from step one.

Three loops, one session

The whole workshop happened in a single Claude Code session. Two or three context compactions across the seventeen steps. I didn't plan it that way; it just kept making sense to continue rather than start fresh.

Three things were running in parallel the whole time:

  • Learning loop. I didn't know MAF when I started. The published samples had already drifted from the preview API — half the names in the docs no longer matched the names in the binaries. After the second compile error from a sample I gave up on docs. Claude would read the binaries directly to find the real names, and that habit became a survival pattern.
  • Building loop. A working mini-Claude-Code as the artifact. Not a toy — a thing I could actually use, with real session files on disk and real Anthropic calls going out.
  • Teaching loop. Each step had to end with a chapter someone else could follow. Goal, MAF concept, code walkthrough, verify, pitfalls, stretch. Same shape every time.

Running them concurrently made each one sharper. The teaching loop forced me to name what I'd just learned, which exposed the things I'd half-understood. The learning loop forced the building loop to be honest — I couldn't paper over a confusion with a "this is left as an exercise" because the next chapter would need it to work. The building loop kept the teaching loop concrete, because every claim had to compile.

Said more plainly: I wasn't using AI to learn MAF faster. I was using AI to learn MAF the way I'd use it. The two loops collapse into one. Otherwise you're rehearsing for the wrong play.

The chapters are the receipt for the learning. If I couldn't write the chapter cleanly, I hadn't understood the step well enough.

One step per sitting

The single rule that held the workshop together: a step is one sitting. One tag (step-00, step-01, …). One chapter. One clean commit prefixed [step-NN]. Then stop.

The temptation to sneak the next step's features in was constant. You finish Step 11 (skills) and immediately see how you'd wire memory in — it's two more methods on the same builder. Why not just do it now while you have the file open. But then Step 12's chapter has nothing left to teach, the diff becomes ambiguous, and someone reading step-12 checked out from step-11 finds work they didn't expect.

So I stopped. Committed Step 11. Tagged it. Then opened Step 12.

The discipline cost almost nothing in the moment and bought a lot at the end: git log --oneline reads like a table of contents, and a learner checking out step-08 gets exactly the state of the project at the end of Step 8 — no more, no less.

This is something the AI is genuinely good at, once you ask for it. Claude will happily expand scope if you let it. Tell it the rule and it holds the rule.

When the AI is the suspect

The piece of the workshop I learned the most from wasn't a feature. It was a bug.

Towards the end the agent crashed on a one-line question — context window blown, on a fresh session. Claude proposed a fix. I would have accepted it if I hadn't pushed back. "I started a fresh session, though." Claude proposed a second fix. "I deleted the sessions and it worked — is there a session bug?" A third. "Then put them back and measure what's actually being shipped."

The fourth attempt was a hermetic probe — measure exactly what was leaving the agent on a fresh turn. The numbers came back nowhere near the limit. Which meant the explosion was happening inside a tool call, not in the prompt itself. One of the tools was returning a quarter of a megabyte of output, which then landed in the next turn's history.

The fix was thirty lines. Getting there was the work.

The lesson wasn't about the bug. It was about pushback. When the AI is the one writing the code and diagnosing the bug and proposing the fix, the only thing keeping you from accepting a confident wrong answer is your willingness to say "no, that's not what I'm seeing, measure it again." Three times in a row, in this case.

That's the contract. The AI types fast. You hold the ground truth.

Probe broader than the framework

Step 17 was supposed to be hand-rolled budget enforcement — count tokens, abort when over limit, write some tests. A reasonable capstone for the workshop.

Before starting I noticed a sibling Microsoft project called the Agent Governance Toolkit. Public preview, MIT-licensed, with everything I was about to hand-build and a lot more: policy enforcement, rate limiting, circuit breakers, tamper-proof audit logging, prompt-injection detection, OWASP Agentic Top 10 coverage. It slotted into the MAF pipeline I'd already built in a single line.

The hand-rolled version would have taken a day and produced something dramatically less capable than what already existed.

I'd been probing MAF for sixteen steps. I hadn't been probing the neighbours of MAF. The capstone lesson the workshop wrote for me — and the reason Step 17 ended up being half the lines of code I'd planned — was that in a preview ecosystem you have to look sideways too, not just down the API surface you've already committed to. The thing you're about to build by hand may already exist one repo over.

The shape of learning, now

I keep the workshop the way it is — chapters, tags, scars and all — because it's a receipt, not a product. Proof I can work with MAF and make it do what I want. I'm still digesting the framework itself — that probably comes later, when I write each chapter up as its own article. But the working knowledge is there, which is the part the next project depends on. The chapters are the evidence. The git tags are the timeline. The bugs are honest about where I got things wrong the first time.

What I'd change next round is small — probe the framework's neighbours from day one, not from step seventeen.

But the shape — one session, three loops, one step per sitting, AI in the room from step one — I'd keep.

The chapters are slower than just writing the code. They're also the thing I can re-read when I need the framework back in my head — an artifact deeper than the commits. That's what learning with AI looks like when you commit to it. Slower at the keyboard, sharper in the head.


Drafted by Claude, shaped by me.