How to read: the first four stages (module 6.1) are preparation—no production code is written during them. The next four (module 6.2, in cyan) are execution and verification. If the preparation is good, execution is fast; if you skip preparation, you’ll recognize all the problems described in track 4.
🧰 Before starting
What you need
- • One repository your, small, with tests that run.
- • A coding agent (Claude Code, Codex, Cursor — it doesn’t matter).
- • A new branch. None of this happens on the main branch.
- • 2 to 3 uninterrupted hours — or two 90-minute sessions.
How to choose the task
- • Small: fits in 3 to 5 files.
- • Verifiable: you can prove it’s done with a test.
- • Real: something that was actually on your list.
- • Reversible: no database migration or public contract change.
Learning path map
Detailed content
🧱 Exercise: Spec, Harness, and Loop
Steps 1 through 4 of the final project: choose the problem, write the full specification, set up the harness with limits, and design the execution loop—all before the first line of code.
Selecting a feature, bug, or legacy module from your own repository to use as the exercise case.
Choosing wrong is the most common way for the exercise to fail: a task that's too large prevents you from closing the loop, so you don't see the method working.
3 to 5 files · testable · reversible · something already on your list.
Applying module 1.2 to your case: problem, objective, scope, out of scope, inputs, outputs, contracts, errors, constraints, criteria, tests, and definition of done.
This is where the exercise pays off: while it’s still on paper, you’ll discover decisions you would have delegated without realizing it.
Verifiable criteria · explicit negative scope · every assumption becomes a question answered before coding.
Define tools, context, permissions, and limits: the AGENTS.md for module 2.1, the isolated branch/worktree, and the quick test command.
Without this, you’ll spend the entire exercise repeating constraints in chat—and some will slip through.
Implicit permission means full access · isolation makes mistakes cheap · documented test command.
The execution, testing, and correction cycle with a verifiable objective, attempt limit, stop condition for lack of progress, and human approval point.
Writing the loop beforehand is what keeps the session from turning into “try again” until you’re exhausted.
Objective = command · maximum attempts · same failure twice → stop · tests must remain untouched.
A simple file where you record time spent, attempts, cost, what the agent assumed, and where you had to step in.
Without a record, the exercise becomes an impression. With a record, it becomes the case you take to the team.
Measure your own practice · Human intervention is data · Compare before and after.
The final check before releasing the agent: a spec with verifiable criteria, QUESTIONS answered, AGENTS.md in place, an isolated branch, a working test command, and defined limits.
Every item missing here becomes an expensive fix in module 6.2—or a result that passes the tests but is wrong.
Good preparation = fast execution · no code yet · ready means ready.
🏁 Exercise: execution, gates, review, and delivery
Steps 5 through 8: implement the smallest possible change, run the build, lint, tests, and security checks, conduct the independent review, and prepare the pull request with evidence.
Run the loop defined in step 4, requiring the plan before implementation and the smallest change that satisfies the criteria.
Approving the plan takes two minutes and saves an hour of rework in the wrong direction.
Plan approved first · smallest change · actual test output pasted, never summarized.
Run the full module 3.3 test suite against the change and record the result of each gate.
That’s where you find out which gates your repository still lacks — and that list is a valuable outcome of the exercise.
A missing gate is also a result · no secrets, no new dependencies without approval · evidence attached.
Open a clean session and review the change using the module 3.2 prompt, receiving only the specification and diff.
This is the stage that most surprises people doing the exercise: the reviewer finds things the implementer defended with confidence.
Context independence · findings with severity · you decide what becomes a change.
Assemble the pull request with the spec, diff, actual test output, gate results, review findings, and what was out of scope.
A PR with evidence is reviewed in minutes; a PR without evidence is reviewed by word of mouth—or approved without being read.
Attached evidence > narrative · declare what was left out too · record human approval.
Reviewing the process itself: where you had to intervene, what assumptions the agent made, which gates were missing, and how much it cost.
Every intervention you make could become a rule, a gate, or an AGENTS.md item—that’s how the system improves on its own for the next task.
Intervention → rule · missing gate → backlog · learning recorded, not remembered.
The collection of the artifacts produced: spec template, AGENTS.md, loop template, rules, skills, gate checklist, review workflow, playbooks, and governance checklist.
This kit is what turns a two-day workshop into a permanent change in practice—because it goes back to the repository with you.
Versioned artifact > annotation · start with what you already used in the exercise · share it with the team.