The working loop

Predict, Write, Specify, Delegate, Audit, Defend

The agent can write the code. Only you can own it. To own a piece of C or C++ means to predict what it does to memory before it runs, explain it line by line afterward, and prove it with instruments.

1
Predict
You, no AI
A written prediction: output, memory state, operation count, and how sure you are.
2
Write
You, no AI
One small piece by hand, to build the mental model.
3
Specify
You
The interface, unit tests, complexity budget and ownership rules. In the Tutor phase: the question you will ask.
4
Delegate
The agent
The implementation from your spec, or an explanation in the Tutor phase. Prompts and transcript saved.
5
Audit
You and the tools
The Audit Report: tests, sanitizer and Valgrind output, your own cost derivation against a timing plot, defects, keep or rewrite.
6
Defend
You, live
A five-minute oral: why this bound, what input breaks it, where this memory is freed.

Never delegated, in any phase

Your first prediction · your first debugging hypothesis · the ownership and lifetime section of a spec · the final judgment that code is correct · the memory checkpoint

The loop. Every piece of work follows the same six steps, the working loop: Predict, Write, Specify, Delegate, Audit, Defend. You predict on paper what code will do, write a small piece by hand, specify what you want from the agent, let the agent do its part, audit the result with instruments (warnings, sanitizers, Valgrind, gdb, tests, timing runs), and defend your conclusion aloud. Chapter 2 teaches the loop in full, along with the stance behind it, verified constructivism: you build your own model of the machine, and you believe an agent only when the evidence agrees.

Five things are never handed to an agent: your first prediction, your first debugging hypothesis, the ownership and lifetime section of a specification, the final judgment that code is correct, and the memory checkpoint.

The phases. What the agent may do grows in three phases.

Tutor (Chapters 1 to 9, the C half). The agent explains concepts and compiler messages, quizzes you and generates practice. It writes no code you submit; in labs it may produce code for you to analyze.
Pair (Chapters 10 to 15). The agent may write small units from a specification you wrote first, and you audit every line.
Team (Chapters 16 to 20). You direct several agent sessions in separate roles (Writer, Reviewer, Tester) and make the final call.

In every phase, three parts of each chapter stay AI-free: the hand-worked concept section, the prediction exercise and the memory checkpoint.

The Audit Report. From the first programming assignment (Chapter 5) on, every assignment ends in an Audit Report of one to two pages in seven parts: specification, agent log, correctness evidence, memory-safety evidence, complexity analysis, defects found, and your decision to keep, rewrite or partly rewrite. Appendix A has the template and a filled example. Most of an assignment's grade comes from this report.

The work log. From Chapter 2 you keep a work log, one row per session (Appendix E). Before the session you write your estimated hours; before you ask anyone, your prediction and how sure you are ("I was 70% sure"). Afterward you record the result, the defects found and the instrument that found each. Each assignment ends with a calibration line: average confidence against hit rate. Chapter 19 uses it to compare estimates with actual hours.

The memory checkpoint. Every chapter ends with five questions answered on paper, agent and notes closed: a diagram, a prediction, a bug to find, terms to define. Concept and vocabulary are scored separately, and the answers are with your instructor. If you miss a question, reread that chapter's N.1 and N.2 before moving on.

The oral defense. Each assignment is followed by a five-minute conversation, usually with a teaching assistant, about your code. Three questions recur: Why does it cost what you say? What input breaks it? Where is this memory freed? A line you cannot explain counts as a line you did not write.

Reading order. In week 1, read Chapters 1 and 2 and work through Setting Up Your Workbench before your first lab. Then read the chapters in order; each builds on the memory model of the one before. Read every N.1 with a terminal open and run every listing. When the text says "Write your prediction before reading on," cover the page and do it. Chapter 20 (concurrency) is optional.

The three phases

Phase	Chapters	What the agent may do	Roles
Tutor	1 to 9	Explains concepts and compiler messages, quizzes you and makes practice problems. It writes no code you submit.	Tutor, Drill maker, Confused peer
Pair	10 to 15	Writes small units from a specification you wrote first. You audit every line.	adds Pair and Adversary
Team	16 to 20	Several agent sessions in separate roles. You direct them and make the final call.	Writer, Reviewer, Tester

Evidence and testimony

Chapter 2 sorts every claim you meet by where it comes from. Instruments give evidence. The agent gives testimony, which can be right and is often useful, but has to be checked. The figures for agent accuracy come from one study of a first-year C course (Taylor et al. 2024), so treat them as rough.

Source	Kind of claim	How reliable	How you check it
Compiler errors and warnings	Evidence	Very reliable that something is wrong; warnings have incomplete coverage	Treat warnings as errors; read the first error first
Sanitizers, Valgrind	Evidence	Few false positives; silent on paths a run never reaches	Run on every build; add inputs that reach more paths
Tests	Evidence	Only as good as the cases; a pass proves less than a failure	Write edge cases first
Debugger	Observation	Shows what is, not why	Compare with your own memory diagram
The agent on compile errors	Testimony	Often right (about 90% in one study)	Accept provisionally; confirm with a rebuild
The agent on runtime and memory errors	Testimony	Much weaker (about 75%), and as confident when wrong	Never accept without a sanitizer run and a hand trace
The agent on undefined behavior	Testimony	Least reliable; often describes what one compiler happened to do	Check a reference; run UBSan
Your own prediction	Conjecture	Starts weak and should improve	Compare with every run; log hits and misses

Chapter 2 also names the stance behind the loop, verified constructivism: you build your own model of the machine, and you treat the agent's output as testimony that instruments must confirm.

The loop in every chapter

Each chapter ends by saying what each step looks like for its topic. Pick a step to read it down the whole book.

Ch	Predict	Write	Specify	Delegate	Audit	Defend
1	each line's output, and any line with undefined behavior, before compiling.	the corrected version by hand, with no casts used to silence warnings.	one question for the tutor about the result you still cannot explain, with your guess.	the tutor explains under the tutor prompt; it writes no code you keep.	check the explanation with a UBSan build and rebuilds at `-O0` and `-O2`.	explain the result to a partner in one minute, naming the rule and the instrument.
2	you write the output of Listing 2.4, your confidence and a time estimate.	the instructor writes a short function by hand; you write your fix to Listing 2.4.	the instructor, then you, write a question for the tutor with a hypothesis.	the tutor explains; it writes no code anyone submits.	the instructor checks the tutor's claims with a rebuild, a sanitizer and a test; you check the claims about Listing 2.4.	you answer one Defend it question aloud in under two minutes.
3	counts for the three lab loops, as formulas and for n = 7, with confidence.	a recursive function by hand: `stn_factorial` (or a recursive helper for `stn_ipow`), overflow check first, with its stack drawing. You may submit a loop version instead (Section 3.1.9). PA1 begins.	a tutor question about one wrong count: your prediction, the counter's result, your explanation.	the tutor explains with questions and hints; no code.	the counter, a gdb backtrace at the deepest call, and the sanitizer build on Table 3.5.	explain the count formula to the TA in two minutes.
4	ten predict-the-output items on paper, with confidences.	`swap` and a function with two out-parameters (`stn_mean_sd` for PA1), by hand.	a question to the tutor about one wrong prediction, with the run that refuted it.	the tutor explains as numbered claims and writes no code you submit.	a gdb memory dump (`p`, `x/4dw`) checks each claim; a known-answer test checks your functions.	teach the confused peer that `sizeof(arr)` in a function is a pointer's size, with a run as evidence.
5	the bytes after two `strncpy` calls, with a confidence; each kernel's slowdown when n doubles.	a bounded string copy and the PA1 functions by hand, edge-case tests first.	the PA1 edge cases (negative, zero, NaN, non-convergence, float equality, overflow) in a table and in each function's comment, plus the question for the tutor.	a tutor review against your CWE checklist; an agent's PA1 version as comparison material, never submitted.	ASan, UBSan, gdb `x/8cb`, edge-case tests with `timeout`, an `-O2` run, and the timing plot against your counts, in the PA1 Audit Report.	your version against the agent's, and the plot's departures from n, n² and n³.
6	draw the stack and heap after each line of Listing 6.13 and predict the leak report, with your confidence.	by hand, a function that returns a new buffer of readings, its ownership comment written first.	a question for the tutor about one report line, with your hypothesis.	the tutor explains that line by asking questions, without code.	ASan and LSan, Valgrind on the `-O0` build, and the fail-the-k-th sweep.	for every pointer, say who owns it after each line and where it is freed on each path.
7
8	copy counts, growth counts and final capacity for 1,000 appends under +1 and doubling, and list drawings after three operations, each with a confidence.	`rvec_push` with doubling and `rlist_insert_after` by hand, with ownership comments in the header.	PA2's tests, including head-removal edge cases and the 1,000,000-append scale test with its capacity-change limit, plus the questions for the tutor.	a tutor quiz on cost and drill-maker sequences to diagram; no submitted code.	tests, AddressSanitizer and Valgrind, the copy counter, and a timing table and log-log sketch checked against your derivation.	the growth policy, the line where the old buffer dies, the line where the head changes.
9	the eight results of Listing 9.15 and the first 29 bytes of `one.bin`, on paper, with confidence.	`stn_pack_flags` (Listing 9.4), then the lab reader and its handlers, by hand.	the opaque `sensor_db.h` with its ownership comments, the `stn_log` status enum, and the question you put to the tutor about the dump.	the tutor explains one dump or `errno` message you have already annotated, and writes no code you submit.	truncated-file tests, the dump checked with `od -j -N`, ASan and UBSan on every build, Valgrind on your reader, and Listing 9.14's compile error.	why the struct is hidden, why the reader checks the count, what the file looks like when the power fails.
10
11
12
13
14
15
16
17
18
19	where two Writers will disagree on the fault rule, your corrected estimate, and the first defect the instruments will find.	the plan, the alerts header with its ownership and cost comments, and the memory trace of the opening case's merge, by hand.	`alerts.hpp`, the definition of done with its `make done` target, and the Tester's brief, with every Section 19.2 ambiguity decided.	the Tester, then Writers on separate branches, then a Reviewer per diff, each a separate session with only its role's inputs.	read each diff and its callers, classify each review, run `make done` after every merge, add a test, and compare actual hours with the estimate.	why you accepted each merge, where every allocation is freed, and why the quadratic check is right at the stated bound.
20	the counter's possible final values at 1,000 and 100,000 increments per thread, the interleavings behind them, and how many of 100 runs will be wrong.	by hand, the unsafe, mutex and atomic counters, and the fix to the agent's `size()` and `empty()`.	the locking plan: what is shared, who touches it, which lock guards it and for how long.	the Writer builds the thread-safe buffer from the plan, the Tester writes stress and late-consumer tests, the Reviewer tables every shared access.	TSan under stress, repeated runs under `timeout`, the Reviewer's table against the plan, and timing with and without the lock.	every lock's scope, every shared variable, and why a passing run is not evidence of no race.