The module carries two joined ideas. The first is that in agentic engineering, code is the agent’s output but the specification is the human’s: a precise document that gives the agent enough information to make autonomous decisions correctly, so that the human does not need to intervene at every step. A feature list is something different. The second is that the specification is never final. Requirements emerge from attempted solutions, so the specification written before a build is the first turn of a spiral, revised under contact with reality, rather than a contract fixed in advance. Writing a specification and running the rhythm that revises it are the same discipline seen at two time-scales.

The formal benchmark behind a complete specification is the five-criteria definition of an algorithm Donald Knuth set out in The Art of Computer Programming: finiteness, definiteness, input, output, effectiveness. A natural-language briefing cannot reach the precision of a formal algorithm. The trade-off in agentic engineering is to give up some formal precision in exchange for the ability to describe higher-level intent. The practical components below are aimed at the same five properties, and a briefing that ignores them is a wish, not a specification.

A complete specification contains the goal and its business rationale (so the agent can make better micro-decisions when the path is ambiguous), success criteria that are verifiable and not aspirational, architectural guidance that gives the agent strategic direction without dictating implementation steps, a validation approach that defines how correctness will be checked, and known pitfalls that an experienced developer would warn a colleague about.

Categories of specification gap map to categories of agent failure. Missing success criteria produce agents that terminate when the code runs rather than when it works. Missing business rationale produces agents that solve the literal problem in ways that violate the intent. Missing architectural guidance produces agents that choose structurally correct but contextually wrong approaches. The reverse-interview methodology is the practical technique: prompting the agent to ask questions until it has enough information to write the specification itself.

The specification produced for any task is a starting point, not a final commitment. This is the empiricist position seeded in Module 6. Rationalism holds that careful thought can yield a flawless design before any code is written; empiricism holds that humans are fallible and that iteration is structurally necessary. Brooks lands empiricist, and ASE pushes further still, because the agent itself behaves empirically and must be tested rather than reasoned about. The Lufthansa Flight 2904 case carries the empirical weight. The code followed the spec exactly. The spec was a correct description of normal landing and a wrong description of reality. People died. No proof, no spec, no formal method can validate the original objectives against reality; only contact with reality can.

The co-evolution model from Maher and from Cross and Dorst follows. Problem space and solution space evolve together rather than in sequence, with each step of the spiral revealing something about what was actually wanted. Brooks’s house example grounds the claim: a proposed design must be rejected before the underlying requirements become visible. In ASE every prompt-build cycle is one step of co-evolution, and the chat transcript is the literal mechanism by which problem and solution find each other. The spiral shape comes from Boehm, with Brooks’s contracting points as the practical refinement. Inside each turn the work runs fast and loose; between turns, intent is pinned down at named moments. The architectural contracting analogy carries the same idea: the client writes a program rather than a specification, the architect provides services rather than a product, conceptual designs serve as prototypes, and only at the end of the design process is a fixed-price construction contract signed.

A related tension is the one Donald Knuth named in the title of his life’s work. The apparent dichotomy is between programming as creative art and programming as mathematical science. Knuth refused to choose, treating the formal and the aesthetic as complementary rather than opposed. The curriculum’s structure-versus-flow tension is the same tension in a new vocabulary: structure is what makes flow sustainable as engineering, and flow is what keeps structure from becoming bureaucracy.

The mechanics of one turn are the practical core. A turn consists of intent revision (drawing on Module 6 and the specification components above), context update (Module 11), safety positioning (Module 12), the build itself, verification (Module 13), and review (Module 16). Multi-agent decomposition (Modules 14 and 15) and security posture (Module 17) enter as the additional dimensions that shape how the turn is structured. A project consists of many turns, and the discipline is to do each turn well.

Two judgment skills complete the module. The commit point is the decision at the end of each turn about what to lock, what goes back into the spec, and what remains open: lock too much too early and the empiricist position is sacrificed to false certainty; lock too little too late and the project never converges. Drift detection is the skill of recognising when the spiral is failing: turns that repeat without progress, scope that expands without milestone, intent that drifts from the original goal. Each signal has a matching intervention, and the full project arc closes the material, from inception to stable maintenance and on to ongoing operations.