Build a Claude Code agent that your team can test, govern and recover when something goes wrong. This practical course takes you from the agent loop to a production-readiness dossier: the controls, tests and operational evidence needed to review an agent before release.

You will design tool and permission boundaries, manage context and memory, evaluate model routing, work with MCP and hooks, and test failure and recovery paths. Practical labs ask you to implement controls and record evidence, not just follow a successful demo.

Across eight modules, the written lessons, worked examples, labs and assessments help you assemble a routing policy, context controls, evaluation cases, an observability plan, a recovery procedure and release evidence. Video material supports the course; a video is not promised for every lesson.

This is the hands-on course companion to Thomas De Vos's book, Claude Code: Building Production Agents That Actually Scale. The book is a separate product and an optional reference, not a required purchase. This course focuses on applying the ideas through practical work and assessments.

For software engineers, technical leads, platform engineers, solution architects and security engineers. You should be comfortable with a terminal, Git, configuration files, tests and normal software-delivery workflows. Prior experience with the Claude Agent SDK is not required.

Leanpub offers a 60-day refund policy, subject to its course exclusions: a course is not refundable after you generate its certificate or fail its last or sole permitted attempt. Read the current policy at leanpub.com/refunds before purchasing.

About the instructor

Thomas De Vos is an architect and technical author with more than 25 years of experience. He is a Google Cloud Generative AI Leader and Google Cloud Authorised Trainer. His teaching focuses on the engineering decisions, practical controls and evidence needed to operate AI systems responsibly.

Free sample: CC-001 lesson and practical lab

This written sample contains the first lesson and its practical lab. The course video, worksheet download and following knowledge-check assessment are not included in this sample. For the lab, use a blank document as your Agent Loop Canvas and record each boundary listed in the instructions.

An agent is not a clever answer. It is a sequence of decisions and side effects, with evidence and control at every boundary.

Estimated lesson time: 38 min

Learning objectives

• Trace a Claude Code task as model decisions, tool requests, observations and termination decisions.
• Distinguish a proposed tool call from an authorized and completed side effect.
• Design pre-action validation using schema checks, permissions, policy, sandboxing, state preconditions and approval.
• Verify postconditions and define stop, retry and escalation behaviour for a bounded run.

Start with the loop, not the chat transcript

Claude Code wraps a language model in an agentic harness. The model receives the current prompt, conversation, instructions and tool definitions. It can answer in text or request a tool. Claude Code executes an authorized request, returns the result to the model, and the model decides what to do next. The loop ends when the model produces a final response without another tool request, or when the runtime stops it.

The useful production unit is therefore not one answer. It is a chain of state transitions. Each transition should have an input, a proposed action, an authorization decision, an observed result and a new state. If the team stores only the final prose, it cannot reliably explain what changed or why.

Anthropic's Agent SDK documentation calls each model-and-tool round trip a turn. A single task can use many turns. In the example below, reading a file changes only the agent's knowledge; editing a file changes repository state; running tests produces new evidence; the final answer changes neither.

• Turn: 1. Model decision: Inspect manifests and repository rules. Runtime event: Read tools return CLAUDE.md and package files. State after the event: The agent knows scope, current versions and constraints.
• Turn: 2. Model decision: Propose a manifest edit. Runtime event: Permission and policy checks run before Edit. State after the event: Either no change, an approval request, or a tracked file change.
• Turn: 3. Model decision: Verify the candidate patch. Runtime event: Approved test command runs in the sandbox. State after the event: A test result and artifact become new evidence.
• Turn: 4. Model decision: Finish or repair. Runtime event: No tool call means the loop returns a result. State after the event: The run ends with status, evidence and remaining uncertainty.

Common misconception

The model does not directly 'use the terminal'. It requests a tool call. The Claude Code runtime, permissions, hooks and operating environment determine whether and how that call executes.

Validation is a stack of different questions

The earlier line - 'validate the proposed action before the side effect occurs' - was directionally right but educationally incomplete. Validation is not one magic function. It is a sequence of gates, and each gate answers a different question. Passing one gate does not imply the others passed.

Run deterministic checks before judgement-based ones. A malformed tool request should fail schema validation before it reaches a policy model or a human. A forbidden path should be denied by policy even if the patch itself looks correct. A permitted action can still need approval because the consequence is high.

1. Schema: is the tool name known, and are required fields present with valid types and normalized paths?
2. Authorization: is this tool and operation allowed, denied or always subject to approval for this project and identity?
3. Policy: does the target, command, data class, branch, amount or destination satisfy business and security rules?
4. Precondition: is the world still in the state on which the proposal was based - for example, the expected Git revision and a clean working tree?
5. Containment: can the command run inside the configured filesystem and network sandbox without broader host access?
6. Approval: if policy says 'ask', does an accountable person receive enough evidence to approve this exact action?
7. Execution and postcondition: after the side effect, did the intended state change occur, and did forbidden state remain unchanged?

Production note

A validator should return an explicit outcome: allow, deny, ask, or - where the integration supports it - rewrite a narrow input. It should also record the rule, evidence and reason.

How Claude Code enforces the pre-action boundary

Claude Code permissions provide allow, ask and deny rules. Deny takes precedence over ask, and ask over allow. Allow means pre-approved, not exclusive: a tool that is absent from the allow list can still follow the active permission flow. To remove or universally block capability, use deny rules or omit the tool from an SDK run.

A PreToolUse hook runs before the normal permission decision and can inspect a proposed call. This is the right place for controls that must evaluate every matching tool request, such as approved file paths or command patterns. A canUseTool callback in the Agent SDK handles unresolved approvals, but it is not a universal enforcement point because earlier rules can resolve a request first.

Sandboxing is a separate boundary. On supported systems it constrains Bash filesystem and network access using operating-system enforcement. It does not replace permissions, and it does not sandbox built-in Read, Edit or Write tools. Production design normally needs both.

Example: Illustrative project policy in .claude/settings.json

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Bash(npm test *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true
  }
}

Common misconception

A CLAUDE.md sentence such as 'never edit deployment files' is useful guidance, but it is context, not hard enforcement. Put non-negotiable restrictions in permissions, hooks, tool wrappers or the sandbox.

A worked validator for a dependency-update agent

Suppose the agent may propose changes to package.json and package-lock.json, run npm test, and prepare a draft pull request. It may not edit workflow files, read secrets, push to the default branch or merge. The model requests an Edit to .github/workflows/release.yml because a newer action version appears necessary.

A strong system does not ask whether the model sounds confident. It evaluates the action against the contract. The normalized path is outside the write allow-list, so the request is denied before execution. The denial becomes an observation in the loop: the agent can revise its plan, explain that the workflow change requires a different authorized process, or stop.

Example: Validator decision record - not an LLM opinion

{
  "decision": "deny",
  "tool": "Edit",
  "target": ".github/workflows/release.yml",
  "rule": "manifest-paths-only",
  "reason": "target is outside the approved write set",
  "observed_revision": "8f31c2a",
  "side_effect_occurred": false
}

Proposed action: Edit .github/workflows/release.yml at repository revision 8f31c2a.

1. Schema passes: Edit has a path and replacement content.
2. Path normalization resolves the target inside the repository; no traversal or symlink escape is accepted.
3. Authorization fails: the task contract permits writes only to package.json and package-lock.json.
4. The runtime records deny, rule=manifest-paths-only, proposal hash and current revision. No edit occurs.
5. Claude receives the denial reason and can propose an in-scope patch or escalate the workflow-file change to a human-owned task.

Result: The run remains useful without granting the model broader authority. A denied action is a controlled branch of the loop, not a runtime failure.

Postcondition checks prove what actually happened

Pre-action validation proves only that an attempt is permitted under the observed state. It does not prove success. A command can return an error after partially changing state; a network timeout can leave an external action completed but unconfirmed; a test can pass because the agent edited the test rather than fixed the product.

After each side effect, re-read the affected state and compare it with explicit postconditions. For a patch, inspect the diff, confirm only approved files changed, run the required immutable checks and retain their exit codes. For an external create operation, reconcile by idempotency key before retrying. The tool result should distinguish success, failure and unknown - not collapse all three into prose.

• Action: Edit manifest. Precondition: Expected revision; approved target. Postcondition: Diff contains only intended dependency fields. On uncertainty: Re-read file and diff; do not claim success.
• Action: Run tests. Precondition: Approved command and isolated environment. Postcondition: Required suite ran; exit status and artifacts captured. On uncertainty: Mark verification incomplete.
• Action: Create draft PR. Precondition: Authenticated bounded identity; branch exists. Postcondition: PR ID exists and is draft; no merge occurred. On uncertainty: Query by idempotency key before retry.
• Action: Finish run. Precondition: Acceptance criteria evaluated. Postcondition: Result contains status, evidence and unresolved items. On uncertainty: Return incomplete or escalated, not 'done'.

Common misconception

Exit code zero is evidence for a particular command, not proof that the whole task is correct. Verification must match the acceptance criteria and threat model.

Stopping is part of the design

An agent loop needs more than a success condition. Define maximum tool-use turns, elapsed time, spend, retries per action, repeated-state detection and escalation conditions. In the Agent SDK, maxTurns bounds tool-use round trips and maxBudgetUsd bounds estimated spend. When a limit is reached, the result reports a specific error subtype rather than pretending the task finished.

A useful termination policy distinguishes completed, safely incomplete, denied, escalated and failed. Stop when acceptance criteria pass; when the next required action is forbidden; when critical evidence is missing; when two attempts return the same failure without new information; or when a budget is exhausted. Continuing to 'try harder' without a state change is not autonomy. It is an unbounded loop.

Production note

The production loop is: observe → decide → propose → authorize → execute → verify → update state → continue or stop. Every arrow needs an owner and evidence.

Practical lab

Choose one real action - edit a file, create a ticket, send a message or open a pull request. Write its schema checks, allow/ask/deny policy, state preconditions, sandbox or tool boundary, approval packet, postconditions, idempotency rule and stop behaviour. Then test one allowed, one denied and one ambiguous outcome.

Deliverable: A completed Agent Loop Canvas plus three decision traces showing allow, deny and unknown outcomes.

Agents are non-deterministic by design. Same prompt, two runs, two outputs. That fact is not going away, and no model upgrade will fix it. The fix is structural. The harness, the layered set of files, tools, gates, and conventions around the agent that narrows the band of outputs to one you can ship. Reliability is not determinism. Reliability is "the band of outputs we get is acceptable, observable, and recoverable."

This course teaches harness engineering as a discipline. Not magic prompts. Not vendor tricks. Engineering practice applied to a new substrate. The learner builds the project harness first: tests, pre-commit gates, rule files, skills, hooks. Then the team harness, where contracts replace tickets and three touchpoints replace mid-flight approvals. Then the organization harness, where rule packs are versioned dependencies that teams consume rather than copy. Then the maintenance discipline (two flywheels, learning and pruning) that keeps any of it honest as the codebase moves underneath it.

The case studies are tools the author shipped along the way and learned from in public. Bridle taught the maintenance flywheels. Sellier taught that prescriptive starter kits adopt faster than build-your-own toolkits. Intent-driven-delivery taught that the team layer can be reified instead of talked about. Keystone is the synthesis. The chapter on it includes what the author got wrong, not only what shipped.

From Panic to Partnership — A Practical Framework for Human-AI Collaboration

You have installed the plugins. You have subscribed to the newsletters. You have read the threads, watched the demos, run the prompt engineering courses, and tried, with varying degrees of success, to integrate AI into your daily work.

And yet something is wrong.

The fast teams have got faster, and the broken teams have got more broken — at scale, at speed, with confidence. Senior engineers are quietly losing trust in code they did not write and cannot fully audit. Reviews are getting shorter while pull requests are getting longer. Tests pass that should not pass. Architecture drifts in directions nobody chose. The 2025 DORA report named what many of us already suspected: AI is an amplifier. It magnifies whatever engineering discipline — or lack of it — already exists.

This course is about what to do about that.

The Thesis

The quality of your AI-assisted work depends almost entirely on the quality of the collaboration space you design. Not on the model. Not on the temperature setting. Not on whether you say "please" in your prompts. On the creative, collective habitat in which human and artificial intelligence meet.

Most of the literature on AI for engineers stops at prompting. Prompting is one micro-skill at one level, and if you stay there, you are leaving most of the value on the table. The real leverage comes from designing the environment where collaboration happens: the documents that encode your team's accumulated wisdom, the architectural constraints that give AI the context it cannot intuit, the verification loops that catch drift before it compounds, the specifications that define intent precisely enough for a different kind of intelligence to act on.

This is not prompt engineering. It is habitat engineering — and it is the discipline that separates the engineers who thrive over the next decade from the ones who drown in their own AI-generated code.

What This Course Is

A professional development framework for human-AI collaboration, structured as a progression from awareness to sovereignty across six levels of literacy:

• Level 0 — Understand the landscape: what AI actually is, what it is not, and what kind of intelligence you are about to work with.
• Level 1 — Communicate effectively through prompts and structured context.
• Level 2 — Develop verification discipline: detect when AI output has drifted from reality.
• Level 3 — Design habitats: persistent, evolving collaboration environments that make good AI output the default rather than the exception.
• Level 4 — Work through specifications: formal, lossless encodings of intent that survive multiple implementations.
• Level 5 — Operate at the level of systems: orchestrate multiple AI agents within organisational structures you have deliberately designed.

Each level represents a qualitative shift in how you think about the collaboration, not just a quantitative improvement in your tool use.

The course is structured in two acts. Act I — The Thesis lays out the intellectual framework: the amplifier thesis, the two kinds of intelligence, the six levels, the three disciplines, the collaboration space itself as an engineering artefact. A tech lead can read Act I alone and walk away with a complete strategic picture. Act II — The Practice is a hands-on journey through the levels using working tools: building a slop detector, writing a living harness, designing architectural guardrails, running parallel agent workflows, authoring executable specifications, choosing your cognitive substrate deliberately, and ultimately scaling the practice across teams and portfolios.

Interludes and field notes provide breathing room between the dense chapters. Exercises throughout demand that you stop and try the thing rather than nod along.

What This Course Is Not

It is not a tool manual. Tools change quarterly. The disciplines in this framework have a longer shelf life because they are grounded in how intelligence — both human and artificial — actually works. Specific tools appear where they illustrate a concept; if you want a step-by-step guide to configuring your IDE plugin, this is the wrong course.

It is not an anti-AI polemic. I am not here to warn you about the dangers of artificial intelligence or to argue that real programmers do not use AI. That position is as useful as arguing that real navigators do not use charts.

It is not a prediction. Nobody knows what AI will be capable of in five years, and anyone who claims otherwise is selling something. What I can tell you is that the disciplines of designing good collaboration spaces, making implicit knowledge explicit, enforcing structural boundaries, and building feedback loops that catch drift are valuable regardless of what the next model can do. They were valuable before AI. They will be valuable after whatever comes next.

It does not promise a 10x productivity boost. It might, in specific contexts, for specific tasks, if you have designed the collaboration well. Or it might make you slightly faster at things that were not your bottleneck while introducing failure modes you have never encountered before. The honest answer depends on how seriously you take the design of the collaboration.

Who It Is For

Individual contributors who want to get seriously good at AI collaboration. Not "I can get Copilot to write a function" good. Seriously good. The kind of good where you design a working environment that makes your AI collaborator consistently produce output worth keeping, where you can assess the quality of generated code with the same rigour you bring to a human colleague's pull request, and where you understand the cognitive asymmetry between your intelligence and the AI's well enough to leverage it deliberately.

Tech leads and engineering managers who need to assess and grow their team's AI collaboration capability. You have team members at wildly different comfort levels — some enthusiastic but undisciplined, some sceptical but potentially brilliant collaborators given a framework that respects their craft. You need a shared vocabulary, a progression model, and concrete practices you can introduce without it feeling like a mandate from management. The course includes calibrated assessment instruments at each level, designed to give you a picture of where your team actually is, not where they think they are or where you hope they are.

Platform engineers and architects thinking beyond personal productivity to organisational capability. The final act covers multi-repo orchestration, governance audit cycles, portfolio-level literacy assessment, and the platform-builder discipline that makes good AI collaboration a property of the system rather than the individual.

The Philosophical Spine

There is a philosophical thread running through this course that I should be upfront about, because it will surface in places you might not expect.

The Stoic tradition — particularly Epictetus — provides the ethical backbone. The core insight is ancient and urgently relevant: distinguish what is in your control from what is not. You do not control the existence of AI, its pace of development, or whether your organisation adopts it. You do control the quality of the collaboration space you design, the rigour of your verification practices, and the clarity of your professional judgment.

Richard Gabriel's concept of habitability, borrowed from Christopher Alexander's architecture, supplies the design backbone. Gabriel asked a question most software methodologies ignored: is this code a good place to live? Not "is it correct?", but can the people who must understand it, change it, and grow it over years do so with comfort and confidence? This course extends that question into the AI era. If code is a habitat for programmers, then the entire development environment — code, configuration, documentation, conventions, specifications, agents, and the feedback loops that bind them — is a habitat for the combined intelligence of humans and AI working together. The inhabitants have changed. The design question has deepened. The principle remains.

The closing chapter borrows from Marcus Aurelius and Epictetus a final practice: the enchiridion — a personal handbook of hard-won principles, written for yourself, revised against reality, passed forward. By the time you finish the course, you will have started writing yours.

What You Will Walk Away With

A vocabulary precise enough to discuss AI collaboration with colleagues without arguing past each other. A six-level progression model you can locate yourself and your team on. Concrete practices for verification, harness engineering, specification-first development, parallel agent orchestration, and cost discipline. An assessment instrument calibrated against the framework. A philosophical posture that treats AI neither as saviour nor as threat, but as a powerful collaborator whose value depends entirely on the quality of the collaboration you design.

And — if you do the exercises rather than skim them — the beginning of a sovereign practice that survives whichever model is fashionable next quarter.

An Invitation

The engineers who thrive in the next decade will not be the ones who use the most AI or the least AI. They will be the ones who understand both kinds of intelligence well enough to design spaces where each contributes what it does best. They will be sovereign over their craft — not because they rejected AI, and not because they surrendered to it, but because they learned to be the architect of the collaboration rather than a passive consumer of its outputs.

That is what this course teaches. It is a progression. It requires practice. Some of it will be uncomfortable.

But the habitat is yours to design. Let's build it well.

You are a software engineer who is skeptical of AI hype.

You have seen the demos. You have tried the frameworks. You have watched your LangChain app hallucinate its way into disaster. And you thought: "There has to be a better way."

There is.

This course is a rebellion against "magic." It teaches you to build a working AI coding-agent foundation from scratch with pure Python. No LangChain. No Pydantic. No vector databases. Just code you can debug with print().

By the end, you will have built Nanocode, a terminal-based coding agent that:

• Reads, writes, and surgically edits files in your codebase
• Executes shell commands and self-corrects from errors
• Maps and searches code with pure Python
• Remembers context across sessions via a persistent scratchpad
• Separates planning from execution with plan and act modes
• Searches the web for current information

Nanocode is a teaching implementation. Act mode runs tools without per-operation approval or a filesystem/shell sandbox. You will learn that an agent is just four things:

1. The Brain - a stateless API call (Claude, DeepSeek, or Ollama)
2. The Tools - Python functions (Read, Write, Edit, Run, Search)
3. The Memory - a self-modifying Markdown file injected as the system prompt
4. The Loop - a while True that ties it all together

Along the way, you will test everything. You will build a FakeBrain test double that lets you run full pytest suites instantly - verifying complex agent logic without burning API credits. You will swap between cloud and local models with a single command, running the brain on your own laptop for free via Ollama.

In the last lesson, you will use your agent to build a complete Snake game in Pygame without writing a single line of code yourself. You speak the plan; the agent writes, runs, debugs, and fixes the code until the game is playable.

If you can read Python and want to understand what's actually happening inside AI agents, this course is for you.

The barrier to building autonomous AI systems has completely collapsed, but the chasm in true engineering understanding has never been deeper. Systems that impress in demos barely survive day one in production.

This course is the definitive, framework-agnostic guide for practitioners who want to move past fragile "prompt-and-pray" scripts and architect agentic systems that hold up under real production conditions.

Across twenty lessons, it builds from first principles to full multi-agent orchestration — not just what these systems do, but how they work architecturally and why they fail. You'll trace the complete arc from bag-of-words to self-attention, master RAG, LoRA, and the alignment frontier (DPO and GRPO), navigate the Six Levels of Agentic Autonomy, design three-tier memory systems that defeat context rot, orchestrate multi-agent systems with DAG-based task graphs without paying the complexity tax, and take absolute engineering ownership of production: evaluation frameworks, observability stacks, guardrail architectures, and kill-switch protocols designed before you need them.

Every lesson is reinforced with checkpoints to keep the concepts anchored: 20 quizzes and 38 exercises placed exactly where they consolidate what you've just learned, plus 4 bite-size FHD video lessons that use graphical demonstrations to make the hardest ideas click.

This course is for serious practitioners who aren't strangers to code or machine-learning fundamentals. If you're a software engineer, data scientist, or technical leader who wants to bridge the gap from "I can call an LLM" to "I can design, ship, and diagnose an autonomous system," it was written to equip you — not to impress you.

📖 This interactive course — twenty lessons with quizzes and exercises — is exclusive to Leanpub. For the full written treatment, see the book it's based on: The Agentic AI Book, also in print on Amazon.