Volume One Recap: From Closed Loop to Evolution
After three chapters, the structural differences between Agent development and traditional development should have shifted from a set of vague symptoms to diagnosable problems. Intent loss is no longer "the Agent isn't smart enough" but a missing explicit spec in the context. Verification failure is no longer "the tests weren't written well" but the verification anchor targeting code instead of the spec. System decay is no longer "nobody maintains the docs" but the absence of a process that turns document evolution into an engineering action.
More importantly, all three problems now have concrete operational approaches. You have a structured method for going from intent to spec, a verification system anchored on the spec, and a change-package workflow for managing document evolution. These are not theoretical frameworks. The OKR case study took a one-sentence requirement all the way to 26/28 compliance checks passing, then evolved from the first feature's success to a delta merge for the second feature.
Volume One established the complete definition of a harness: closed-loop control ensures each execution is reliable; evolution ensures the closed loop itself does not degrade. Each chapter solves one problem; together they form a system that sustains itself over time.
Specification solves intent communication. An Agent processes only the information present in its context; unwritten intent is equivalent to nonexistent intent. Information layering (vision → architecture → feature → task) gives knowledge at different abstraction levels its proper home. Three dimensions (intent, acceptance, constraints) ensure that the critical questions at each layer are explicitly answered. A spec is not a one-time document but a continuous vehicle for intent alignment between humans and Agents. Humans are the sole judges of intent, because intent exists only in the human mind.
Verification solves execution confirmation. The anchor for verification is the spec, not the code. Tests verify behavioral correctness (did the code deliver the functionality the spec described?). Code review verifies semantic completeness (did the code drift from the spec's framework?). The two cover different dimensions; neither alone is sufficient. Verification must happen upfront, during execution, and in a modular fashion, because Agent drift occurs continuously throughout execution. Waiting until the end means facing dozens of issues erupting at once.
Evolution solves system maintenance. Specs become outdated. This is a structural inevitability. Every iteration creates drift between the spec and the code. An outdated spec causes the closed loop to protect the wrong target. The change-package workflow turns document evolution into a repeatable engineering action: each change gets a spec-level description, verification runs at creation time and again after merge, archives preserve the decision trail, and sync detection catches residual drift as a safety net.
The three chapters are not three independent tools. Specification provides the anchor for verification: without a good spec, verification does not know what it is verifying. Verification provides confidence for evolution: only when you can verify spec consistency do you dare make incremental updates. Evolution keeps the spec alive: a spec can continue serving as the verification anchor only if it is continuously updated. The three form a cycle. If any link breaks, the other two fail.
The executing agent of this system is the human. Humans write specs, humans do reviews, humans judge whether intent is aligned, humans maintain document evolution. At the current stage, one person developing a few features sequentially keeps the cost of each step manageable. But cost grows with project scale. When the number of features grows from single digits to dozens, the human effort for cross-checking, document maintenance, and sync detection can no longer be covered in half an hour per feature. This is not a flaw in the methodology but the natural boundary of the human-in-the-loop model.
The question for Volume Two is: how to let Agents take on more of the closed-loop maintenance while humans step back to a higher-level supervisory position. From sitting in front of the Agent guiding it step by step, to designing tasks for the Agent to complete autonomously, to dispatching multiple Agents to work in parallel. The prerequisite for this transition is the closed-loop and evolution mechanisms established in Volume One. Without specification, autonomous Agent execution is just automated Vibe Coding. Without verification, Agent output cannot be trusted. Without evolution, the system starts to decay after the first iteration. Letting go requires something to catch what falls.
Harness Engineering Playbook · AgentsZone Community