My new Leanpub course is live: Claude Code: Building Production Agents That Actually Scale.
I wrote the book because too many Claude Code conversations stopped at capability. The agent edited the files, the tests went green, and the demo looked clever. Nobody could explain what would happen when a tool timed out after completing a side effect, an approval outlived the action it covered, or a retry repeated something expensive.
The course turns those production questions into work you have to do. You will implement controls, test the failure paths, and assemble evidence. Watching somebody else build a polished agent is not the same as proving that your own agent is bounded, observable, recoverable, and ready for review.
What the course teaches
The course has eight modules and 31 numbered lessons. It begins with the agent loop and works outward into the operating system around it:
- Foundations of a production agent
- The Claude Code primitive stack
- Owning the runtime with the Claude Agent SDK
- Securing and governing the agent boundary
- Evaluating agent behaviour before and after release
- Observability, reliability, and cost
- Scaling to a team-owned agent platform
- Remediating anti-patterns and planning the migration
The sequence matters. Teams often jump straight to orchestration or platform design because the demo already works. That skips the controls that make later scale safe. A shared agent platform only spreads the operating model you put underneath it. If that model cannot reconstruct a run or stop a repeated side effect, scaling makes the problem faster.
This is practical work
Each lesson combines focused instruction with an engineering task. The modules include labs, knowledge checks, graded assessments, capstones, workbooks, templates, rubrics, and solution guidance.
You will work through questions such as:
- Where should a permission be enforced so the model cannot negotiate around it?
- What evidence proves that a tool call achieved its postcondition?
- When should a workflow remain in the Claude Code CLI, and when does it need an SDK-owned runtime?
- How do you test retries, partial failure, stale approval, and duplicated side effects?
- What belongs in an agent timeline when a reviewer needs to reconstruct the run?
- How do you calibrate an LLM judge before using it as a release gate?
- How do you measure cost beyond token spend?
The answer is never to write a better prompt and move on. Prompts matter, but production behaviour also depends on tool contracts, runtime policy, context controls, evaluation data, telemetry, recovery procedures, and human authority.
The output is a production-readiness dossier
The course does not end with a certificate-shaped claim that you watched the material. The capstone work builds a production-readiness dossier for an agent system.
That dossier records the agent loop, model-routing policy, context controls, permission boundaries, evaluation cases, observability plan, recovery procedure, and release evidence. It gives an engineering or architecture review something concrete to inspect.
This is the standard I want teams to use when they say an agent is ready. A successful transcript is a useful artefact. It is not enough evidence for production.
Who it is for
I built the course for software engineers, technical leads, platform engineers, solution architects, and security engineers who already understand normal delivery work. You should be comfortable with a terminal, Git, configuration files, and tests. Previous Claude Agent SDK experience is not required.
The course is based on the production engineering behind my book, but it is not a narrated copy of the book. The course makes you apply the controls, complete the labs, pass the assessments, and produce the dossier.
If your Claude Code experiment is approaching real repositories, MCP servers, CI, production data, or team-wide adoption, this is the point where the operating model matters.