A5.7 · module hub
Programming with an agent
A5.1–A5.6 built the brief and the practice of running it. This module names the thesis the whole course has argued: a Claude agent is a fast, tireless implementer of well-specified slices; the human owns decomposition, judgement, and acceptance.
The value is the product of two roles, not their sum. The
agent supplies speed and implementation; the human supplies direction
— decomposition, judgement, acceptance. Speed alone, pointed nowhere, is a fast walk off a cliff;
direction alone, with no implementer, is a plan that never ships. Pick a role on the right to read what it
owns and the factor it contributes, all worked on the Portal's real
f6.1.llms.md brief.
The two roles · pick who owns what
The precise statement
The course has argued one thesis from A1 to here, and A5.7 states it plainly. Pragmatic programming with a Claude agent is a pairing of two roles. The agent supplies speed and implementation: it builds a specified slice fast and tirelessly, and it does not tire, drift, or skip steps across a long run. The human supplies direction: decomposition (cutting the work into thin slices), judgement (the calls a spec cannot make), and acceptance (reading the result against the spec's Definition of Done, never the agent's self-report).
The value of the pairing is the product of speed and direction, not their sum. Speed alone, pointed nowhere, is a fast walk off a cliff. Direction alone, with no implementer, is a plan that never ships. The two compound, and the rest of this module shows where the compounding helps and where it hurts.
The worked unit is f6.1.llms.md, the Portal's real brief for the Phoenix web
bootstrap over the unchanged facade. It specifies the slice down to requirements
F6.1-R1…R8, the task DAG T1→T7, and the
acceptance gates per agent story F6.1-AS1…AS4. Its own closing line is the
evidence the value is real on a specified slice: “each story is two-to-six files behind one
command and one gate, and every branch … is already specified — so the agent implements rather
than decides.” “So the agent implements rather than decides” is the thesis in one
clause: when the slice is specified, the agent's speed converts directly into progress, because nothing is
left for it to decide. That brief is built in the companion course at
the Phoenix request lifecycle.
Speed times direction
The product has a sign. The agent's speed is high and roughly constant; what changes between a good run and a bad one is the direction the spec set. On a well-specified slice the direction is right, and high speed carries the work a large step toward done. On an under-specified slice a decision is left to the agent, which it fills by improvising — and high speed carries the work a large step the wrong way.
Toggle the specification below. The model fixes the agent's speed at a high constant and reads the
direction from the brief: a well-specified slice scores +1, an under-specified one
−1. The readout reports the signed outcome — the same magnitude, with
the sign the spec chose. The lesson is upstream: the way to a large positive step is to specify the slice,
not to slow the agent.
The compounding · outcome = speed × direction
The agent is a fast implementer of well-specified slices; the human owns decomposition, judgement, and acceptance — and the value is the product, not the sum.
f6.1.llms.md specifies the slice down to F6.1-R1…R8,
the T1→T7 DAG, and the gates; the agent builds it fast because nothing is
left to decide.
The agent supplies speed; the workflow supplies direction; multiply them.
The three dives
Each dive takes one face of the thesis, in order: the pairing that produces the value, where the value is real, and the failure mode that turns speed against you. Read them in order — A5.7.1 starts with the two roles that compound.
The pairing
Speed from the agent times direction from the workflow — the two roles that compound, each necessary and neither sufficient.
Where the value is real
On a well-specified, thin, gated slice the agent's speed is a clean multiplier — two-to-six files behind one command and one gate.
The failure mode
On an under-specified slice the agent improvises, and speed multiplies the wrong direction — the fix is upstream, in the spec.
A5.7 names the thesis behind the practice; it ties back to A1's case for thin, provable slices (A1 · Why an agile agent workflow) and A1.05 “correct by definition”. After it, the A5.8 workshop runs the whole sequence on a real Portal rung. Return to the A5 module navigation to continue.
References
The sources this thesis draws on for pragmatic, value-driven programming with a coding agent, and where the course argues the same case and the worked brief is built.
Sources
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — pragmatic, value-first programming and the tracer-bullet discipline of turning a fixed contract into a built increment.
- Anthropic — Building effective agents — the agent as a fast implementer of a well-specified task, with the human holding the direction.
- Beck, K. — Extreme Programming Explained — thin slices, fast feedback, and the practices that keep speed pointed at value.
Related in this course
- A5.7.1 · The pairing
- A5.7.2 · Where the value is real
- A5.7.3 · The failure mode
- A1 · Why an agile agent workflow — the thesis of thin, provable slices, first.
- A1.05 · Correct by definition — a slice is done when it is provably done.
- A5 · The agent brief — the parent chapter.
- Companion · Phoenix (F6) — the chapter whose
f6.1.llms.mdis the worked slice.