A casual prompter and an agentic software engineer can sit at the same screen, use the same model, point at the same product, and produce different things. The difference between them is a discipline.

The discipline is the structured, auditable conduct of human-agent work for building software. It has principles, named artefacts, recognised failure modes, and standards a practitioner can be held to. A tool is always involved, but the discipline lives upstream of the tool and survives its replacement.

Tool skill is what a practitioner has after using a product for a while: knowledge of menus, shortcuts, and rough edges. Such knowledge decays the moment the product changes. The discipline does not decay, because it concerns the structure of the human-agent relationship rather than any one form of it.

Casual prompting and engineering can look identical from across the room. The difference shows up when somebody asks, a month later, what was actually requested, why this particular answer came back, and whether anyone is on the hook for it. Casual prompting cannot answer those questions. Engineering must. Specification, verification, and the audit trail are how the discipline answers them.

Three responsibilities belong to the human: framing the problem, specifying what good would look like, and judging what comes back. The agent’s responsibility is execution. Humans bring taste, context, accountability, and the capacity to decide whether the project should exist at all. Agents bring tireless production of plausible artefacts, broad coverage of patterns the human cannot recall, and indifference to fatigue.

The division collapses in predictable ways. The human treats execution as their responsibility, hand-edits the output line by line, and loses the audit trail. The human delegates judgment along with execution and accepts whatever the agent produced. The human delegates framing, lets the agent decide what the problem actually is, and ends up with confident output for the wrong question.

Four structural risks shadow the division even when it is held correctly. Skills no longer practised atrophy. Code produced rapidly through dialog can become opaque to the person who directed it. Accountability gets diffuse when human, agent, model provider, and deploying organisation all contributed. Models reproduce the assumptions of their training corpora. These risks do not disappear with experience. They are managed.

A workflow that cannot be inspected, replayed, or evaluated after the fact is craft. Engineering is accountable and reproducible. The auditability principle is the discipline’s defining commitment: every workflow must produce a record sufficient for someone other than the original engineer to reconstruct what was decided, why, and what happened.

The artefact that makes the commitment operational is the audit trail. It links intent to specification, to context, to agent trajectory, to output, to verification. A reviewer looking at it later can answer the three questions that distinguish engineering from sophisticated guesswork: was the right problem being solved, did the proposed solution match the specification, and did the actual output pass the gates the specification implied.

Classical software engineering struggled for decades to produce audit trails as a routine matter. Agentic engineering produces them as a byproduct of normal operation. The agent’s reasoning sits in the chat transcript. The tool calls are logged. The artefacts are committed. The verification gates record their own results. The discipline asks for this material to be preserved, named, and made navigable.

One turn of the workflow has seven parts. They run as the constituents of a single act rather than as sequential phases.

Intent is the human’s understanding of what is wanted. Specification is the precise document the agent receives, sufficient for it to make autonomous decisions correctly. Context is what the engineer deliberately puts in front of the agent. Plan is the sequence of actions the agent generates given the context. Execution is the agent’s invocation of its tools to act on the world. Verification is the gate the output must pass before it enters the project. The audit trail records the whole thing.

The course teaches one part of the anatomy per module across Part 3. Module 6 develops intent. Module 10 develops specification. Module 11 develops context engineering. Module 12 develops the safety layer that protects execution. Module 13 develops verification. Module 16 develops review. Module 18 returns to the rhythm that connects them into a living project.

Two positions divide the history of software engineering. The rationalist holds that careful thought yields a design before any code is written, and that the design can be specified completely enough to be implemented faithfully. The empiricist holds that humans are fallible, that intent cannot be fully known before the work begins, and that design must proceed through build-evaluate-revise cycles.

ASE is empiricist by structural necessity. The agent itself behaves empirically. The output of any given prompt is a sample from a probability distribution rather than the deterministic execution of a specification. Tests reveal what the model produced; reasoning about what the model should have produced is insufficient. The agent must be tested, observed, corrected, and tested again.

The position preserves the value of upfront thought. Framing the problem, writing a coherent specification, and curating the context are all upstream work that pays off in fewer wasted turns. The position holds that the upstream work cannot complete itself before the work begins. Specification and build co-evolve.

The problem space and the solution space evolve together rather than in sequence. The framer thinks they want X. The agent produces something resembling X. The framer sees the result and realises what was actually wanted is Y, or X minus some constraint, or X reframed for a different user. The build teaches the framer what the framer wanted.

This claim originates in design research and is established empirically there: studies of expert designers show that requirements emerge from attempted solutions rather than from prior reflection. The position is older than agentic engineering, but agentic engineering is the form of software development in which the claim is most easily observed.

In ASE the chat transcript is the literal mechanism of co-evolution. Each prompt-build cycle is one step. A specification that did not move during the project has not been tested against reality. The discipline asks the framer to let it move, and to record the motion.

The evolutionary spiral is the operational form the co-evolutionary claim takes. A project runs as a sequence of turns. Inside each turn the work is fast and loose: the agent produces, the human reads, the human asks for revisions, the agent produces again. Between turns the work is pinned down: the specification is updated, the context file absorbs what was learned, what is done is named done, and the next turn begins from a clean restore point.

The architectural contracting analogy carries the idea in a different vocabulary. The client writes a programme of needs rather than a specification of solutions. The architect provides services rather than a finished product. Conceptual designs serve as prototypes. Only at the end of the design process is a fixed-price construction contract signed. The spiral has the same shape: open work inside the turn, contracting between turns, an increasingly definite product over many turns.

Two judgment skills make or break the rhythm. The commit point is the decision at the end of each turn about what to lock, what goes back into the specification, and what remains open. Drift detection is the skill of noticing when the spiral is failing: going in circles, expanding scope, losing its original intent. Both are learned through practice.

The evolutionary spiral can be contrasted with spec-driven approaches that treat intent as fixed before the build begins. Spec-driven approaches produce a complete specification first, treat the build as faithful implementation of that specification, and treat any change to the specification mid-build as scope creep to be controlled.

Spec-driven approaches are right about the value of upfront thought. They are right that a well-specified problem produces better output than an underspecified one. They are wrong, in agentic engineering specifically, when they treat the specification as a closed contract. Intent moves under contact with reality, and the spec-driven framing treats this movement as a defect rather than as the central mechanism by which the framer discovers what they wanted.

The evolutionary spiral preserves what is right about spec-driven approaches. Upfront thinking matters. A complete-enough specification produces better turns. What the spiral adds is the recognition that the project lives through multiple turns, that the specification must be allowed to move between turns, and that the audit trail must record the motion.