Going Deeper

⏱ ~9 min read · 🎧 10 min listen · ✎ 3 quizzes · 🧪 ~60 min lab

This is the second optional track — Track B, for upskillers. Lesson 12 was for landing the role; this one is for what comes after the course, whether or not you change jobs (and if you are job-hunting, everything here doubles as interview depth). The shared spine, Lessons 1–11, made you dangerous across the whole FDE surface. This lesson maps where to go deeper — and, more importantly, hands you the system for deciding that yourself long after this course's facts have gone stale. Because they will.

Depth area 1: fine-tuning — mostly, the skill of saying no

Databricks' FDE posting lists fine-tuning alongside RAG and multi-agent systems as expected experience² — so yes, it belongs on your roadmap. But here's the field reality: most customer requests for fine-tuning are AI-judgment tests in disguise. The customer has heard the word, it sounds like "training the AI on our data," and it arrives as a requirement rather than a question. Your first move is never a training run — it's "what does the eval say the gap is?" A measured failure mode tells you which lever actually closes it.⁹

Learn fine-tuning deeply enough to run it when that last row is true — data curation, held-out evals before and after, regression checks — and confidently enough to decline it the other 90% of the time. "We measured the failure mode, and it's a retrieval problem, so fine-tuning would cost you months and fix nothing" is one of the highest-trust sentences an FDE can say to a customer. It's the same courage-to-say-no muscle from Lesson 10, now applied to a specific technique.⁷

Depth area 2: multi-agent systems in production

Anthropic's multi-agent research system essay is the best production writeup of the orchestrator-worker pattern: a lead agent plans and spawns parallel subagents, each with its own context window, and the architecture beat a single-agent baseline by 90.2% on their internal research eval.¹ The pattern pays when the task is genuinely parallelisable — breadth-first research, many independent subtasks — and the value of the answer exceeds the cost of getting it.¹

And that cost is the number to memorise: in Anthropic's data, agents burn about 4× the tokens of chat, and multi-agent systems about 15×.¹ The essay is equally blunt about operations: agents are stateful, errors compound, and debugging means full production tracing plus careful deploys (they use rainbow deployments to avoid breaking agents mid-flight).¹ So the FDE judgment call mirrors the fine-tuning one: single agent with good tools first; orchestrator-worker only when the eval shows a breadth problem a single context window can't hold — and the customer's economics survive the token bill.

Staying current without drowning

This field will outrun any course — including this one. The models named in these lessons will be superseded; some APIs will be deprecated. What shouldn't change is how you found out. This course was built with a specific source-hygiene discipline, and it's the most transferable thing in it: primary vendor docs over commentary, every link fetched and verified before it's cited, every claim dated, deprecations hunted actively. That last one has a fresh object lesson: OpenAI's Evals platform — a real product teams built on — is being retired, read-only from October 2026 and shut down a month later.⁴ A course (or a customer architecture) that leaned on it without a deprecation watch would simply be wrong within months.

On that last habit: a handful of practitioners have earned trust by being consistently early and consistently verifiable. Simon Willison for security and prompt-injection reality checks, posting near-daily⁵; Hamel Husain on evals as the centre of AI products⁶; Eugene Yan and the applied-llms group on tactical lessons from a year of shipping⁸; Chip Huyen on agent planning and failure modes⁷. Notice what they share: they show their work, they date their claims, and they say "this didn't work" in public. That's the filter for anyone you add to your list.

Contributing patterns back

The last depth area isn't consumption at all. Anthropic's FDE posting puts it in the job description: codify what worked into repeatable deployment patterns and feed them back to product and engineering.³ The habit generalises beyond any employer: write up an engagement (your Lesson 11 case study was the first rep), publish a small eval harness or MCP server, file the reproducible bug, answer the question in public. Contribution is also the highest-fidelity learning loop there is — nothing exposes a fuzzy understanding faster than writing it down where practitioners can check it. Every artifact in your portfolio repo is a candidate.

🧪 Practical steps: build your learning system (~60 min)

The final portfolio artifact is the one that keeps producing after the course ends: a personal learning system — small, scheduled, and verification-first. It also reads well in interviews: "here is how I stay current" with evidence is rarer than you'd think.

1. Build your source list — sources.md: 5–8 entries MAX. 2–3 vendor doc pages (e.g. the Claude docs release notes, the MCP spec), 2–3 practitioners (start from the four above, keep only who you'll actually read), 1–2 newsletters. For each: one line on WHY it earns its slot, and a check frequency. If you can't justify a slot, cut it — the cap is the feature.
2. Define a 30-minute weekly review ritual — ritual.md: what you scan in what order, what you deliberately skip, and the stop rule (a hard 30 minutes — when the timer ends, you're done). Write it as a checklist you can run half-asleep.
3. Start a claims-to-verify log — claims-log.md: a table with columns claim heard · source · verified? · date. Seed it with 3 real claims currently circulating in your feeds or your workplace (a model comparison, a "X is dead" take, a cost figure) and verify at least one against a primary source before you finish the lab.
4. Scope your next deep-dive project — deep-dive.md: one paragraph. What (e.g. a real fine-tuning run with before/after evals, or an orchestrator-worker build with token-cost accounting), why NOW (tie it to your re-scored gap map from Lesson 12), what artifact it produces, and a hard 4-week bound. Scoped like you'd scope a customer engagement — because that's the rep.
5. Save all four files to D:\Projects\FDE-Portfolio\l13-learning-system\ and commit.

Feedback loop: bring the four files back to me in chat and I'll review them like a sceptical peer — is the source list actually small and justified, would the ritual survive a busy month, is the deep-dive scoped tightly enough to finish? This artifact closes out the tracker in reference/artifact-tracker.html — and unlike the others, it's designed to still be in use a year from now.

You are a senior applied-AI engineer reviewing my personal learning system, built at the end of a Forward Deployed Engineer course. It has four parts: a capped source list (5–8 entries, each with a why and a check frequency), a 30-minute weekly review ritual with an explicit stop rule, a claims-to-verify log seeded with 3 current claims, and a one-paragraph scoped deep-dive project with a 4-week bound.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Source-list discipline: the list is genuinely small, every entry has a specific justification (not "good AI content"), and it mixes primary vendor docs with verifiable practitioners.
- Ritual sustainability: the 30-minute ritual would survive a busy month — concrete scan order, explicit skips, a hard stop rule, and nothing that depends on willpower.
- Deep-dive scoping tightness: the project names a concrete artifact, a reason it's the right gap NOW, and a 4-week bound that a sceptic would believe.

Be sceptical — challenge the flabbiest source-list entry and the most optimistic part of the deep-dive scope first. Then suggest one source to cut and one claim worth adding to the verification log. Finish with the single change that most improves the system's odds of still running in six months.

My learning system follows below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental model — don't scroll up. Wrong picks stay live.