Teach the course

The book is designed for a one-semester course with a traditional catalog description. Every catalog topic is kept. What changes is what students learn about each topic: what still holds, what replaces what breaks, and how to test the difference.

The semester project (Chapter 18) holds the course together. Each student acts as the engineering manager of a team of agents, building a system of their choosing through seven milestones (M0 to M6) and a final post-mortem and oral defense. Assign Chapter 18, Sections 18.1 to 18.3, in week one so the work log starts on day one, and the rest at the handoff. A mid-semester handoff gives every student a classmate's project to inherit, which brings maintenance of someone else's code into the course. Appendix G maps every lab to its milestone and suggests a fourteen-week schedule.

Labs are written to run with any agent harness. They name no tools in their procedures, because the tools will change before your students graduate. Students pre-register predictions before collecting data, so the course produces evidence, not just experience. Where a lab is costly, it comes in two paths. The leak test in Chapter 17 has a core path for every student (implement the small game, understand the bound, analyze supplied logs) and an extended path (the full four-condition audit at scale, about 8,000 model calls) with a cost and time worksheet. Both paths keep pre-registration and honest statements of uncertainty.

Chapter dependencies. Chapters 1 and 2 come first. After that, Part II can be taught in order or rearranged. The main dependencies are:

• Chapter 5 (size) before Chapter 6 (cost), which uses function points as an input.
• Chapter 8 (coordination) before Chapter 17 (the bound and the leak test).
• Chapter 12 (reviews) and Chapter 13 (testing) before Chapter 15 (reliability), which uses their verification layers.
• Chapter 16 (the four conditions) can be taught early, alongside Chapter 8, if you want students to use the conditions throughout.

Companion readings. Two 2026 books on agentic software engineering make good companions: Hassan's Agentic Software Engineering, written for engineering leaders, and Tantithamthavorn's Agentic Software Engineering: A Practical Guide for the AI-Native Engineer, written for students. Each Part II chapter has a short box headed "Where the companion books stand," which keeps only the disagreements that change that chapter's recommendation. The book can be read without either companion. Many tensions with them are productive, not contradictions: a written requirement can be ambiguous and still essential, and a separately configured reviewer is not self-correction. This book cites both as statements of practice, not as validation.

A suggested 14-week schedule

This is one way to fit the book into a semester. It is a suggestion, not a requirement; adapt it to your calendar. No week assigns more than two chapters, and the first four weeks assign five, not eight, because those are the weeks in which you also set up the log, write a specification and pre-register estimates.

Table G.5. Chapters by week.

Week	Chapters	Due at end of week	Notes
1	1, 2; and 18 (Sections 18.1 to 18.3)		Start the work log on day one; Chapter 1 lab
2	3	M0	Baseline session log due
3	4	M1	Proposal and executable specification
4	5		Count function points; no construction yet
5	6, 7	M2	Pre-registration closes; construction begins
6	8, 17		Coordination week; core leak test
7	16	M3	Role card; extended leak test is optional
8	9, 10		Two-part register; "Do Not" section
9	14; and 18 (Sections 18.4 to 18.8)	M4	Handoff at end of week; midterm if you give one
10	11		Characterization tests first
11	12		Three-arm inspection
12	13	M5	Handoff audit due
13	15; and 18 (re-read)		Fit the growth model; post-mortem draft due
14	None	M6; Final	Estimate vs. actual reveal; peer review; oral defense in the final slot

Chapter 18 is the guide to the project, not a chapter to learn in one sitting, so the table lists it in three readings: Sections 18.1 to 18.3 in week 1 (the project, its milestones and the work log), Sections 18.4 to 18.8 at the handoff, and the whole again in week 13. Weeks 2 to 4 carry one chapter each, because you are also writing a specification and counting function points; the work log runs from day one.

Five notes on the schedule.

1. The four conditions arrive early, in brief. Chapter 1 gives the four conditions for assurance in a box (condition 1 is incremental detection), and the Part II chapters from Chapter 6 on cite them by name. That box carries you until Chapter 16 in week 7, where they are developed and tested. Chapter 16 sits before M3 because M3 needs it, and so before Chapters 12, 13 and 15, whose roles it discusses. Treat the role descriptions in Sections 16.3 and 16.4 as a preview, and return to them in weeks 12 and 13 when reviews, testing and reliability have been taught; rerun your role's qualification suite then (Chapter 16, lab step 4).
2. The leak test has a core path. Every student does the core path in the coordination week (week 6): implement the small game, confirm the bound and analyze supplied logs. The extended path, about 8,000 model calls for four conditions at 1,000 rounds, is for volunteers or a group, and can run from week 6 alongside later chapters. Give students the cost and time worksheet before they choose (Chapter 17, Table 17.7).
3. The handoff splits the semester. Weeks 1 to 9 are greenfield, on your own project. Weeks 10 to 14 are brownfield, on the project you inherit. Chapters 11, 12, 13 and 15 are all taught against inherited code. Chapter 14 and the handoff share week 9, so start the package in week 8.
4. The two reveals come late. Estimate vs. actual (M6) and the handoff data (P8) need the full log, so they land in weeks 13 and 14. Pool the class's held-out estimates in week 14 (Appendix E, Section E.9), and treat the pooled results as exploratory.
5. Fewer weeks. In a 10-week term, the two-chapter cap will not hold. Assign Chapters 3, 5, 13 and 15 as reading with shortened labs, run only the core leak-test path, and combine weeks 2 and 3, 8 and 9, and 10 to 12. Say in the first class which chapters are reading only.

For practitioners and engineering leaders

If you manage engineers who use agents, start with Chapter 2, then read the chapters for the problems you have. Estimates that keep missing: Chapters 5, 6 and 7. Review queues that won't clear: Chapters 3, 6 and 12. Agents whose work you can't trust: Chapters 13, 15 and 16. Agent teams that coordinate in ways nobody designed: Chapters 8 and 17. Each replacement method (Section N.5) is meant to be usable on Monday, and each lab works as a pilot on a real team's data.

The semester project Open the map