Agentic Coding in Practice
A course in fifteen chapters over three levels, built from the full git histories of three projects.
Format
Fifteen chapters, each a facilitator-led theory session followed by a practical session. Theory runs 15 minutes per insight, so a chapter's theory session takes 45 to 90 minutes. Each chapter's theory page gives its timings, and its exercises page times every exercise. Practical sessions are hands-on, with individual and paired exercises on the attendee's own project.
Target Audiences
The course serves two audiences through the same material with different emphasis:
Individual practitioners and small teams: Developers, tech leads, and solo builders who want to move beyond autocomplete-level AI tool usage. The individual pathway emphasises personal productivity, workflow discipline, and honest self-assessment.
Enterprise engineering teams: Engineering managers, platform teams, and technology leaders evaluating or scaling AI coding tools across organisations. The enterprise pathway emphasises governance, risk management, ROI validation, and team standardisation.
Both pathways use the same 71 Agentic Coding Insights (ACIs). The content is identical, and each chapter's theory page carries notes for both pathways: the framing, emphasis, and discussion prompts differ.
Prerequisites
- Software development experience (any language, any level beyond beginner)
- A laptop with terminal access
- Willingness to install and use Claude Code during practical sessions
- No prior AI coding tool experience required (101 covers setup)
Course Arc
The chapters are numbered the way undergraduate courses are: the first digit is the level, and each level builds on the one before. The third year's entry condition is fluency with a single agent, which is why the fleet comes last.
- 1xx, first year, new to agentic coding: one human and one agent, and the habits and mechanics that make a single session productive and safe.
- 2xx, second year, the practitioner with a method at project scale: specification, steel threads, rules and critics, verification, autopsies, evidence-based correction, and the publish pipeline.
- 3xx, third year, multi-agent fleets: coordination protocols, named nodes, whiteboards, the hypervisor role, validation nodes, chain of command, clean contexts versus forks, and the failure modes of agents working in parallel.
1xx, first year
| Chapter | Key question | Insights |
|---|---|---|
| 101: The Landscape | Where are we? | 6 |
| 102: Briefing the Agent | How do we brief the agent, and where does the briefing live? | 6 |
| 103: The Session | How do we keep what a session learns? | 3 |
| 104: Checking the Agent's Work | How do we know the agent's work is right, when the agent is the one telling us? | 4 |
2xx, second year
| Chapter | Key question | Insights |
|---|---|---|
| 201: Specification and the Work Unit | How do we define work so that done can be computed? | 6 |
| 202: Rules, Skills and Critics | How does a rule become something that holds? | 6 |
| 203: Structural Governance and Recovery | How do we keep one home for every fact, and recover when we have not? | 6 |
| 204: Instruments That Cannot Fail | How do we know our checks are checking? | 6 |
| 205: Testing with Agents | What does a test suite prove when an agent writes it and a model runs in it? | 4 |
| 206: Debugging and Diagnosis | How do we find the cause, rather than the most plausible story? | 4 |
| 207: Work Without a Test Suite | How do we verify work that no test can run? | 3 |
3xx, third year
| Chapter | Key question | Insights |
|---|---|---|
| 301: The Step Up | How does one human run a fleet? | 4 |
| 302: The Whiteboard and the Shared Tree | How do agents share a board and a codebase without losing each other's work? | 5 |
| 303: Command, the Pen and the Human | Who decides in a fleet, and how does a ruling reach every node? | 4 |
| 304: Verification and Failure in the Fleet | How does a fleet check itself, and how do we see it failing? | 4 |
Assessment Approach
This course does not use exams or certifications. Its self-assessment tool is the evaluation framework, which is course design rather than a finding from the record. It profiles a practice across seven dimensions. The six single-agent dimensions (autonomy level, context engineering support, session continuity, verification and review, team and enterprise readiness, and methodology ecosystem) are previewed in 101 and scored at the end of the first year, in 104. The seventh, multi-agent coordination, is added in 301. Attendees keep the profile for ongoing self-assessment.
The course's measure of success: attendees leave with a personal practice roadmap they will actually follow, based on honest assessment of where they are and where the evidence says the gains are largest.
Materials Provided
The course is self-contained. Attendees get:
- The syllabus: this document
- Theory for each of the fifteen chapters, with timings and teaching notes
- Exercises for each chapter, each with verification criteria and facilitator notes
- A reference card for each chapter: its key moves at a glance
- 71 ACIs: the insights, each with thesis, story, evidence, application, and anti-pattern, and each homed in one chapter
- Case studies: the MeetZaya failure, with 201, and the Lamplight fleet, with 301
- The evaluation framework: the seven-dimension self-assessment tool, labelled as framework rather than finding
- A reference shelf: the landscape survey, taxonomy, reading list, sample-repo spec, and course outline
- The build process: how the course was extracted from real development
Evidence Base
This course is not built from opinions or best-practice recommendations. Every insight is grounded in evidence extracted from real development, and cites the commits behind it:
- Three projects read in full: the git histories of Intent (7,052 commits since 15 November 2023), Lamplight (11,894 since 15 September 2025) and Laksa (3,999 since 11 November 2022), measured at their pins on 14 September 2026
- 313 evidence cards, each re-verified against its commits and challenged by a skeptic before a chapter used it
- The v0.1.0 extraction that came before them, with its six extraction lenses, recorded in How This Course Was Built
- One major project failure, MeetZaya, providing the failure case study: its technical record was measured for v0.1.0 and is not re-measured at the pins, and its strategic account is marked illustrative until an interview confirms it
The course teaches from evidence rather than authority. Every claim has a source.
About the Author
The course was developed by a practitioner who builds production software with agentic coding tools, across projects from command-line tools to Elixir umbrella applications. The methodology (Intent, steel threads, TCA) emerged from that practice. The course is the distillation of what worked, what failed, and what the data says about the difference.