Skip to content
Chapter 4 — MAGE in Motion: Engineering Through Models  ::  §4.1

§4.1 The Dynamics of MAGE

MAGE can look static when described one principle at a time. Chapter 2 introduced models as projections of consequential properties; Chapter 3 introduced Alignment as the mechanisms that establish and preserve correspondence between those models and a realization. A working engineering system, however, is dynamic. Models are discovered, realizations change, new properties become consequential, and knowledge accumulated during one change constrains the next.

Engineers do not interact with agents through a single interface. On the Modeling side of Figure 4.1-1, natural language, specifications, and models play different roles. Natural language supports inexpensive, fluid interaction: asking questions, expressing intent, exploring alternatives, and requesting changes. A specification makes obligations on an acceptable realization explicit. Models make selected properties and relationships explicit so that they can participate directly in reasoning about the system. These forms complement one another. A model does not eliminate conversation, and a specification does not eliminate either.

The return path is similarly varied. On the Alignment side, review, testing, and analysis provide different forms of evidence about the resulting realization. Review permits contextual human judgment. Testing observes selected executions. Analysis reasons about properties that may not be adequately established by sampled executions alone. The engineer interprets this evidence against the relevant specification and models, deciding whether the realization is acceptable, must change, or has exposed something that should change the engineer's understanding.

Engineer–agent interaction through Modeling and Alignment Two panels over one shared implementation node. Left panel, Modeling / Communicating: the engineer fans out through three parallel channels — natural language, specification, and models — which converge on the agent; the agent produces the implementation. Right panel, Alignment / Evaluating: the implementation yields a result, which fans out through three parallel channels — review, testing, and analysis — that converge back on the engineer. The same engineer appears at both upper ends; the single implementation node at the bottom is the hinge between communicating intent and evaluating evidence. MODELING / COMMUNICATING what do I know, intend, and need to make explicit? ALIGNMENT / EVALUATING what does the evidence justify believing or doing? engineer engineer natural language specification models review testing analysis agent result implementation
Figure 4.1-1. Engineer–agent interaction through Modeling and Alignment. Engineers communicate intent and knowledge through natural language, specifications, and models; delegated realization returns evidence through review, testing, and analysis. The channels are complementary rather than sequential. Modeling makes selected engineering knowledge available to guide realization, while Alignment provides evidence for evaluating and revising it.

The distinction is therefore directional rather than procedural. Modeling externalizes knowledge that can guide delegated work; Alignment brings evidence from that work back into engineering judgment. Neither side prescribes a fixed sequence of activities. An engineer may move among these interactions repeatedly during a single change.

Complementary does not mean equal in governing force. Natural language and specification remain useful throughout engineering, but neither maintains anything on its own: a specification states an obligation, and something must still establish and preserve it as the system changes. A consequential property should not depend on an engineer restating it in a prompt, an agent retaining it across a conversation, or a reviewer remembering to check it. Once such a property is sufficiently understood, Modeling makes it explicit and automated Alignment keeps the realization in correspondence with it. The objective is not to model every thought exchanged with an agent. It is to ensure that consequential properties do not remain dependent on those exchanges.

Three ideas describe the resulting dynamics: alignment can operate actively or passively; models can be brought into governance incrementally around an alignment kernel; and the models themselves can emerge from engineering work rather than being specified completely in advance.

4.1.1 Alignment Changes the System

The Alignment side of Figure 4.1-1 contains two distinct activities. Active alignment changes the realization to establish correspondence with a model. Passive alignment checks that correspondence as the realization continues to change. The first is corrective; the second is protective. Figure 4.1-2 shows the two modes and the handoff between them.

In active alignment, the current implementation may not satisfy a newly introduced model. The environment can expose the disagreement, agents can modify the implementation, and the result can be evaluated again. That loop continues until the realization satisfies the modeled obligations.

In passive alignment, a proposed change is evaluated against governing models and their obligations. The environment may reject the change, require evidence, constrain what an agent can do, or otherwise prevent the realization from drifting outside the modeled region.

Active alignment converges the system; passive alignment preserves the correspondence Two stacked panels. Top, active alignment (convergence): models M feed a pipeline of compare (detect gaps), modify (with agents), and evaluate (check alignment), producing the aligned system S-prime; a loop-back arrow labelled repeat until correspondence returns from evaluate to compare. A handoff arrow labelled once active alignment succeeds leads to the bottom panel, passive alignment (preservation): a proposed change delta-S enters evaluate (check against models), with the retained models M feeding in from above; the outcome is admit or reject, yielding the updated system S-prime, with a loop labelled continue protecting correspondence returning to the next proposed change. A closing note: the models, mechanisms, and governance remain in the governed engineering environment as engineering capital. Active alignment (convergence) use the models to change the system until it satisfies them M models compare detect gaps modify with agents evaluate check alignment aligned system S′ repeat until correspondence once active alignment succeeds … Passive alignment (preservation) the same models and mechanisms keep it aligned M models ΔS proposed change evaluate check against models updated system S′ admit or reject continue protecting correspondence models, mechanisms, and governance remain in the GEE as engineering capital for every later change
Figure 4.1-2. Active and passive alignment. Active alignment uses a model and its alignment mechanisms to transform a realization until the modeled obligations are satisfied. Once correspondence has been established, those models and mechanisms remain in the governed engineering environment as passive alignment: subsequent changes are evaluated against the established obligations so that correspondence is preserved.

The two modes normally occur in sequence. An engineer introduces a model because some consequential property deserves stronger representation and control. Active alignment brings the existing realization into correspondence with it. The model and its alignment mechanisms then remain in the GEE. What was the target of one engineering episode becomes a constraint on later ones.

Active alignment therefore produces engineering capital. The result is not merely code that now happens to satisfy an obligation. The environment has gained an explicit model of that obligation and machinery capable of evaluating subsequent changes against it. Future agents inherit that structure.

This matters because active alignment is not necessarily behavior preserving. Asking an agent to make a state machine explicit, replace an architectural boundary, separate storage from computation, or satisfy a new ownership model may require substantial changes to the realization. Those changes may satisfy the new model while damaging some other property that has not yet been made visible to the environment. That possibility creates an ordering problem.

4.1.2 Establish a Kernel Before Expanding

The first models brought into governance should protect the properties that subsequent transformations must not be allowed to damage. Together, these models form the alignment kernel.

The kernel does not introduce another class of model. Chapter 2 described different projections through which an engineer can represent consequential properties of a system: its behavior, structure, resources, deployment, ownership, and other concerns. Here the question is different: in what order should those models become governing constraints?

The answer need not follow the taxonomy. Active alignment can substantially change a system while bringing it into correspondence with a model. We should therefore first model and align the properties that subsequent transformations must not be allowed to damage. Additional models can then be introduced incrementally, with each active alignment performed subject to the constraints already established. Figure 4.1-3 shows the governed surface growing this way.

Incrementally extending the alignment kernel Left, a numbered four-step procedure: 1 identify the kernel — model the properties that must stay protected while the system changes; 2 actively align — use the models to change the system until it satisfies the kernel; 3 extend — add the next models, subject to the constraints already established; 4 repeat — each new model narrows what later change is allowed to do. Right, a flat concentric diagram: the kernel M1 sits at the centre, with M2, M3, and M4 as successively larger nested rings. An annotation notes that the governed surface grows over time; another that each new model is admitted under the constraints of the models inside it; and a third that active alignment operates within the protected region. 1 Identify the kernel model the properties that must stay protected while the system changes 2 Actively align use the models to change the system until it satisfies the kernel and all prior models 3 Extend add the next models, subject to the constraints already established 4 Repeat each new model narrows what later change is allowed to do kernel M1 M2 M3 M4 the governed surface grows over time … each new model is admitted under the constraints of the models inside it active alignment operates within the protected region
Figure 4.1-3. Incrementally extending the alignment kernel. The kernel contains the modeled properties that must already be protected while active alignment changes the system. Additional models extend the governed surface, but each new alignment operates subject to the constraints established by the models already in the kernel. The layers are not different classes of model; they show models such as those introduced in Chapter 2 becoming governing constraints over time.

The order is system-dependent. For a conventional information system, behavioral correctness and state management may belong in the initial kernel: later structural changes must preserve what the system does. For an embedded system, resource properties such as latency, memory, or energy may need to enter first. An implementation may contain unusual structure precisely because it satisfies a timing constraint. Asking an agent first to make an implicit state machine explicit could invite a reasonable-looking refactoring that removes those optimizations. If the timing model is already aligned and enforced, the agent remains free to restructure the implementation—but only within the performance envelope that must survive.

The sequence is therefore an engineering decision, not merely a documentation order.

The model projections in Chapter 2 were deliberately peers: each represented a different consequential aspect of the same realization. Once active alignment begins changing that realization, however, time matters. Aligning one projection can perturb properties represented by another. The models already under governance define the region within which the next transformation may safely operate.

The kernel can then grow. A newly aligned model becomes part of the protected environment for the next episode; another can be introduced, actively aligned, and retained. MAGE adoption can therefore proceed incrementally rather than requiring a complete model of the system before governance begins.

Nor should the kernel necessarily grow without bound. A model earns its place by making a consequential property cheaper to understand, predict, constrain, or evaluate than leaving that knowledge implicit. The objective is not maximum representation. It is sufficient control over consequential degrees of freedom.

4.1.3 Greenfield and Brownfield MAGE

Incremental adoption is easiest to see in a brownfield system. A realization already exists. Engineers can observe it, identify consequential properties, induce models from the implementation and their own knowledge, actively align the system where correspondence is missing, and retain the resulting models and mechanisms in the GEE. The governed surface grows around a system that was already running.

A greenfield project might appear to invite the opposite strategy: construct the models first, align implementation to them, and only then allow the system to emerge. That is sometimes appropriate when obligations are already well understood. It is not the general MAGE prescription.

Software engineering exists in part because software changes. Requirements turn out to be incomplete. Apparently obvious abstractions prove wrong. Interactions become consequential only after something runs. A specification can reduce degrees of freedom without eliminating uncertainty about which choices should ultimately be fixed.

Early in a project, some degrees of freedom therefore have information value. Cheap implementation can be used to explore them. A loose specification can produce one or several prototypes; those prototypes expose missing requirements, useful abstractions, resource constraints, awkward interactions, and assumptions that were invisible on paper. The engineer then has better evidence about what should become explicit structure.

Agentic implementation makes this strategy unusually cheap. In that setting, even vibe coding has a legitimate engineering role: it can serve as a kind of 3D printer for software, rapidly realizing a loose specification so that engineers can learn about the system they actually need. The mistake is not using cheap implementation. The mistake is confusing an exploratory realization with a sufficiently governed one.

Cheap implementation changes engineering experience in three related ways.

Engineering phenomena — Realization, comprehension, and connection amplification

Realization amplification: compressed exploration. Commodity intelligence lets an engineer turn an idea into something concrete enough to inspect, execute, measure, compare, or reject much faster than before. Alternatives that once would have been too expensive to try can become part of the engineering process.

Comprehension amplification: compressed understanding. Rapid realization also changes how quickly engineers can discover what they mean. Agile methods have long treated working software as a source of information: realization exposes misunderstandings that requirements and discussion leave hidden. Capable agents compress this feedback loop dramatically. An engineer can express an intent, inspect a realization, recognize that it is not quite what was intended, and revise the representation repeatedly in the time that one realization might previously have required. For properties that engineers can directly and reliably observe, realization therefore becomes a powerful instrument for refining intent itself.

Connection amplification: compressed experience. Agents surface related failures, observations, and design consequences in dense succession, where conventional development would have separated them by days or weeks. Their proximity can make relationships visible: several local failures reveal one architectural gap; a measurement exposes a missing model; one change makes the consequence of another immediately apparent.

The three describe one movement outward. Realization amplification acts on the artifact: it produces something concrete enough to observe. Comprehension amplification turns that observation back on intent, so what an engineer meant becomes clearer as what was built is inspected. Connection amplification carries the same evidence outward into the surrounding system, where relationships among separate observations become visible. None of the three is something an engineer performs. All three describe conditions the engineer now works inside.

In simpler terms:

  • You can build faster.
  • You can better understand what you meant to build.
  • You can better understand how what you built affects everything else you are trying to build.

But comprehension amplification is bounded by what the feedback makes visible. Ousterhout's guidance to measure one level deeper captures the danger:11. John Ousterhout, “Always Measure One Level Deeper,” Communications of the ACM 61, no. 7 (2018): 74–83. optimizing only for an immediately visible, high-level property can improve that property while degrading the structures that sustain it. A system can look simpler to a user while becoming more complex internally; a change can satisfy its functional goal while worsening performance, security, or maintainability. Fast realization therefore does not eliminate the need for models. It increases the importance of deciding which properties must be represented and measured beneath the surface being experienced, a question §4.4 takes up directly.

In DocAble, related failures sometimes arrived quickly enough that what first appeared to be separate defects became recognizable as symptoms of a missing architectural concept. The response was not another sequence of local repairs. The shared relationship became a system model, which in turn enabled static analyses that prevented several classes of failure. Speed had changed what the engineer could see.

The engineer still decides which alternatives are worth exploring, which realizations reveal a misunderstanding, and which apparent connections matter. When a connection reveals a recurring engineering lesson, governance conversion provides the next move: preserve that lesson in the environment so that later work inherits it. Once that knowledge is explicit, it can compound: later work begins with the model, constraint, evidence, or mechanism produced by earlier experience rather than reconstructing the same judgment. And because comprehension amplification exposes intent the engineers had underspecified, the environment accumulates not only knowledge for agents, but clarifications of the engineers' own intent.

Engineering move — Governance conversion

A recurring failure, a repeated judgment, or a newly discovered relationship is converted into durable engineering structure: a representation, a body of evidence, a procedure, or an enforced obligation. §3.4 develops the move in full.

This is the capture step, and it is a move an engineer makes rather than a condition the engineer observes. It does not decide what deserves capturing; that judgment stays with the engineer. It names what follows the decision: the lesson stops living in one person's memory and starts living in the environment that governs the next change.

The resulting loop is therefore more than generate and check. Cheap realization can accelerate learning about the system, while governance conversion changes the environment in response to that learning. What the engineer learns can become engineering capital.

The improvement loop has familiar ancestors: mistake-proofing,22. Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, trans. Andrew P. Dillon (Productivity Press, 1986). jidoka, continuous improvement, resilience engineering,33. E. Hollnagel et al., Resilience Engineering: Concepts and Precepts (Ashgate, 2006). and the postmortem discipline of converting incidents into durable changes.44. B. Beyer et al., Site Reliability Engineering: How Google Runs Production Systems (O'Reilly Media, 2016). Implementation abundance changes the economics: autonomous work can expose gaps faster than human attention can repeatedly absorb them, increasing the return on durable engineering structure.

loose specification → realize → observe → connect → model → align → retain

The engineers supervising this process do not begin without understanding. They had enough understanding to state the problem, write the loose specification, judge the prototype, and recognize what it gets wrong. The task is to move consequential parts of that understanding out of human memory and into explicit representations that agents and the engineering environment can use. Because agents can perform both realization and much of the mechanical work of model induction quickly, this transition need not be a long separate modeling phase.

Degrees of freedom provide the criterion for when that transition should occur. Leave a degree of freedom open while variation is producing useful information. Once a choice becomes sufficiently understood and consequential, represent it and, where justified, align the realization to it. What began as exploratory freedom becomes governed engineering knowledge.

Greenfield and brownfield MAGE therefore converge. Brownfield work begins with an existing realization and induces models from it. Greenfield work may begin with cheap realizations deliberately produced to learn what should be modeled. In both cases, engineering alternates among realization, observation, interpretation, modeling, alignment, and measurement. Realization amplification increases the experience available to learn from; comprehension amplification turns that experience back on what the engineers meant to build; connection amplification compresses the experience in time, so related observations arrive close enough together for what they share to become visible; governance conversion lets selected lessons survive the episode that produced them. The difference is where the first useful evidence comes from. Brownfield systems do pose one additional problem: the relevant models and obligations may already exist implicitly in implementation, tests, procedures, and organizational knowledge; §4.3 returns to how to recover them.

Works Cited

  1. Ousterhout, John. “Always Measure One Level Deeper.” Communications of the ACM 61, no. 7 (2018): 74–83.
  2. Shingo, Shigeo. Zero Quality Control: Source Inspection and the Poka-Yoke System. Translated by Andrew P. Dillon. Productivity Press, 1986.
  3. E. Hollnagel, D. D. Woods, N. Leveson. Resilience Engineering: Concepts and Precepts. Ashgate, 2006.
  4. B. Beyer, C. Jones, J. Petoff, N. R. Murphy. Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media, 2016.
© James C. Davis, 2026–present