Skip to content
Chapter 7 — The Profession  ::  §7.2

§7.2 MAGE in the Engineering Tradition

MAGE does not depart from software engineering's modeling tradition. It recomposes ideas that software engineering, the older engineering disciplines, and artificial intelligence each developed over decades, under one changed economic condition: realization by commodity intelligence.

Software engineering has long possessed elaborate modeling techniques. Requirements models, architecture description, state machines, formal specification, types, model-driven engineering, and verification all predate the present moment by decades. What distinguished mainstream practice was the unusually powerful position code occupied. Source was symbolic, executable, cheap to copy, and precise enough to serve as artifact and representation at once. Economics, rather than a missing tradition, explains where model-heavy software methods concentrated.

7.2.1 Engineering Through Representations

Engineering disciplines, software engineering among them, reason about consequential systems through representations that preserve selected properties and omit the rest. Civil, mechanical, electrical, aerospace, and systems engineers work through load models, schematics, state-space models, simulations, drawings, and analyses. A useful representation makes an important property cheaper or safer to reason about than the realized artifact itself.

Models are the building blocks of engineering.** Here I mean model in the broad sense developed in Chapter 2: a purposeful reduction that preserves distinctions needed for some question. The claim is close to axiomatic under this book's definition of Engineering. A consequential system sufficiently simple to understand and direct without reasoning through reduced representations does not present the complexity for which engineering, in this sense, is required. A circuit schematic is not a circuit; a finite-element model is not a bridge; a process-flow diagram is not a refinery. Each is a purposeful reduction that preserves selected relationships so engineers can reason about them without reasoning directly over the realized artifact. The representation is useful because it leaves most of reality out.

Physical engineering makes the separation vivid. Fabrication can be expensive or irreversible, full-scale trials can be destructive, and physical iteration can take weeks or months. A structural model answers a loading question before concrete is poured. Circuit simulation exposes a design error before a mask set is fabricated. These examples earn their place because realization cost makes the gap between representation and artifact obvious, not because physical engineering discovered modeling while software did not.

The common engineering move is simple: ask the question over the cheapest representation that preserves the property you care about, then use evidence to justify realization. Mature engineering still uses prototypes, experiments, and direct inspection. Models do not replace the artifact. They organize the reasoning around it.

Software makes the same move through its own traditions. Requirements engineering externalizes obligations. Architecture exposes consequential structural relationships. Type systems and intermediate representations make selected program properties explicit. Formal methods construct representations over which stronger claims can be established. Model-driven and model-based approaches go further and make selected models primary engineering artifacts. These traditions differ substantially, and they share one move: represent the property at a level where it can be reasoned about.

The medium varies; the purpose does not. The analysis serves a decision. Salado makes this point directly by treating engineering as disciplined decision-making under uncertainty and competing objectives, rather than technical problem solving alone.11. Alejandro Salado, Rethink Engineering: Revolutionize the Way You Make Decisions (Educating Thinkers Press, 2026). Engineers model, calculate, measure, and experiment because consequential choices must be made: which design to pursue, what evidence to gather, which tradeoff to accept, or whether the resulting system is fit to proceed. A model earns its place when it stands in service of such a decision. MAGE shares that emphasis, and asks what happens when much of the work downstream of those decisions can be delegated to commodity intelligence.

7.2.2 Why Software Often Modeled Differently

Software shared this engineering tradition, and its economics often favored a different allocation of representational work.

Software realization was extraordinarily cheap; detailed design and implementation labor were not. Once source code existed, another compilation, execution, or copy of the program could usually be produced at negligible marginal cost. Producing, understanding, debugging, and changing that source consumed skilled engineering labor. The source was already a precise, executable representation through which engineers reasoned about the system.

That blurred a distinction the older disciplines could make more cleanly. A structural engineer reasons through a design before concrete is poured; a semiconductor designer simulates a circuit before fabrication. In software, the artifact handed to the cheap realizing mechanism, the compiler, is itself the product of an iterative design process. Reeves made the strongest version of this argument by calling source code the final software design. MAGE does not require that full claim. It requires only the narrower one: software design and implementation have historically been tightly coupled, and code has served simultaneously as realization, executable specification, and a primary surface for further reasoning.†† Jack W. Reeves's "code is design" argument22. Jack W. Reeves, “What Is Software Design?,” C++ Journal, 1992, https://www.developerdotstar.com/mag/articles/reeves_design.html. is a useful historical extreme; MAGE relies only on the narrower claim that software design and implementation have traditionally been tightly coupled.

Code's malleability then works against the engineer as a system evolves. Architecture, intent, constraints, and operational knowledge can stay implicit in an artifact whose structure keeps changing, and the system stays executable long after the knowledge needed to govern it has become hard to recover. The disciplines named in the previous section exist partly to hold that knowledge where continual change cannot quietly erase it.

Those secondary models faced an unusual economic test. The implementation was already precise, executable, and immediately available, while an architectural, behavioral, or process model imposed an additional correspondence burden. A model could be useful when authored and misleading after the implementation moved beyond the relation it claimed. Many projects therefore kept such representations thin unless their communication, reasoning, or assurance value repaid that standing synchronization cost. Figure 7.2-1 shows the three economic variables and what moves them.

Why software modeled differently: three economic states, and the change that shifts the price ratio between a model and its implementation A comparison across three columns. Older physical engineering: physical realization is expensive and slow, a design representation is necessary before realization, and model maintenance is amortized over expensive build and test cycles. Software historically: compilation and reproduction are cheap, detailed implementation and change labor are expensive, the code is itself an executable and precise representation, and maintaining a secondary model is a standing correspondence cost. Commodity intelligence: implementation labor falls, model derivation and reconciliation labor falls, and more live representations become economical. Software was never model-free; the economics simply favored thin models. A downward arrow resolves the three columns to a single claim: the model-to-implementation price ratio changes. WHY SOFTWARE MODELED DIFFERENTLY Older physical engineering physical realization: expensive / slow design representation: necessary before realization model maintenance: amortized over expensive build / test cycles Software, historically compilation / reproduction: cheap realization / change labor: expensive code itself: already executable & precise secondary-model correspondence: standing cost Commodity intelligence implementation labor falls model derivation / reconciliation labor falls more live representations become economical THE MODEL / IMPLEMENTATION PRICE RATIO CHANGES
Figure 7.2-1. Why software modeled differently. Software was never model-free. Compilation and reproduction were cheap, but producing and revising the detailed implementation required skilled labor, and code itself served as an executable engineering representation. Additional models therefore carried a standing correspondence cost. Commodity intelligence lowers both realization labor and parts of the cost of maintaining secondary representations, expanding the surfaces on which live models can repay their upkeep.

Commodity intelligence changes both sides of that ledger. It lowers the skilled labor required to realize and revise software, and it lowers parts of the labor required to derive, update, reconcile, and check additional representations. Neither cost becomes zero, and the governed environment that holds those representations carries its own construction and maintenance cost; the shift pays only where the structure future work inherits saves more reconstruction, rework, or risk than it costs to carry. The important change is that implementation and live modeling can become cheaper together, making model-mediated software engineering economical over surfaces where the synchronization tax once exceeded its return. §6.3 treated that boundary directly.

The claim is about price, and it stops there. Moving an economic boundary does not determine which representations will become primary. §7.1 walked through several places the displaced effort can settle and declined to name one, and nothing in this history overrides that restraint. What can be said here is historical: the price ratio between a model and the implementation it describes has moved, and surfaces that could never justify a maintained representation now sometimes can.

Implementation remains an important source of truth, and some properties are most naturally reasoned about there. A useful representation need not become authoritative. What changes is that code need no longer bear the whole burden of being the realization, the repository of system knowledge, and the surface over which engineering reasoning occurs.

7.2.3 Model-First Engineering as One Point in the Design Space

Model-first engineering occupies one end of the representational design space: consequential knowledge is made explicit before autonomous realization begins.

The Siemens reconstruction demonstrates one such equilibrium in a mature engineering culture. The public account describes persistent models carrying geometry, requirements, behavior, physical relationships, allowable change, and traceability before an agent enters the picture. Software can appear downstream as one realization among others. The agentic question is therefore not how to recover engineering structure from source code, but how to let autonomous tools operate safely through structure the organization already made explicit.

That inversion clarifies MAGE's position. Software-first agent systems largely ask, How do we make a codebase legible to an agent? A model-first discipline can ask, How do we let the agent work through the same engineering representations we already trust?

Degrees of freedom locate MAGE along this axis. A sufficiently complete model can determine realization closely enough that transformation, generation, or synthesis is the natural next step. MAGE includes that case, but does not require it. Its models can instead specify the obligations that matter and the tolerances those obligations permit while deliberately leaving other realization choices open. Those degrees of freedom are not defects in the model; they are choices engineering has no reason to settle in advance. Where tolerances become narrow and little consequential freedom remains, deterministic generation may be preferable. Where substantial freedom remains, autonomous realization can choose among acceptable implementations.

Cabot's vibe-driven model-based engineering proposes a contemporary software route toward the same end of the space, placing agents downstream of models much as a model-first engineering culture already does.33. Jordi Cabot, “Vibe-Driven Model-Based Engineering,” 2026, https://arxiv.org/abs/2604.10645. §7.1 weighed that proposal as one plausible equilibrium among several. What it adds here is the observation that the software proposal and the systems-engineering practice describe one arrangement approached from two directions.

MAGE includes this organization but does not privilege it. Which representations become primary is an empirical question about where the new prices land. A discipline may settle at different points for different systems, or for different properties of the same system.

7.2.4 Established Traditions, New Composition

The novelty of MAGE lies less in its individual mechanisms than in their composition around delegated realization. Each part of the arrangement has a long history, and those histories belong to fields that developed largely independently of one another. Figure 7.2-2 shows the two inheritances and where they meet.

Established traditions, new composition: engineering and AI traditions converge in MAGE Two columns of established traditions feed a central MAGE boundary. On the left, engineering traditions: model-based and model-driven engineering (explicit models); programming languages and compilers (types and constrained intermediate representations); formal methods (specifications and verification); systems and safety engineering (boundaries and control). On the right, AI traditions: knowledge representation; memory and planning state; structured reasoning; tools and interfaces. Both columns feed the MAGE boundary, inside which Modeling makes knowledge explicit and Alignment enforces selected obligations; the two meet in the Governed Engineering Environment. Governance conversion carries recurring judgment downward, out of the boundary, into engineering capital — durable structure inherited by subsequent work — toward trustworthy autonomy, the intended outcome outside the boundary. New economics under commodity intelligence drive the new composition; the provenance of the parts is old. ESTABLISHED TRADITIONS, NEW COMPOSITION ENGINEERING TRADITIONS MBSE / MDEexplicit models PL / compilerstypes · constrained IRs Formal methodsspecs · verification Systems / safetyboundaries · control AI TRADITIONS Knowledgerepresentationexplicit knowledge Memory ·planning stateexternal state Structured reasoningintermediate structure Tools · interfacesreasoner support MAGE Modeling make knowledge explicit Alignment enforce selected obligations Governed Engineering Environment representations · evidence · constraints · controls where both traditions meet — a first-class engineered object Engineering capital recurring judgment, made durable Trustworthy autonomy the intended outcome governance conversion inherited by subsequent work NEW ECONOMICS → NEW COMPOSITION commodity intelligence changes the price list, not the provenance of the parts
Figure 7.2-2. Established traditions, new composition. MAGE draws on two long-running traditions. Engineering disciplines developed explicit models, constrained representations, verification, and external control; AI repeatedly extended reasoners through knowledge representation, planning state, memory, structured reasoning, tools, and surrounding machinery. MAGE brings these inheritances together around autonomous software work: Modeling makes engineering knowledge explicit, Alignment enforces selected obligations independently, and both meet in the Governed Engineering Environment. Governance conversion carries recurring judgment into durable engineering capital. Commodity intelligence changes the economics of this composition, not the provenance of its parts.

Engineering supplies the first inheritance. Across its disciplines it externalized consequential knowledge into representations, constrained realization against those representations, established evidence that the constraints held, and controlled the transitions that carry consequence: a release, a certification, a change to a system already in service.

AI supplies the second. Its long history of improving reasoners runs substantially through structure placed outside the reasoner: knowledge representations holding what the system knows, planning state and memory holding what it is doing, tools and interfaces extending what it can act on, and intermediate reasoning structures holding partial work. §7.1 traces that line through recent systems. The reasoner improved because its surroundings did.

Commodity intelligence brings the two traditions into the same production system. Modeling makes engineering knowledge explicit so that autonomous work can be informed, scoped, checked, and reviewed through it. Alignment enforces selected obligations independently of the agent that produced the work. Both meet in the governed engineering environment, which holds the representations, the evidence, the constraints, and the controls as engineered objects rather than as project byproducts.

Governance conversion keeps that arrangement from settling into a static assembly. Recurring judgment becomes durable structure. Later work inherits that structure as engineering capital, and the accumulated capital earns the next extension of autonomy. Chapter 4 developed the conversion and the ratchet that keeps it open to correction.

Commodity intelligence changes the price list. It does not change the provenance of the parts.

7.2.5 What MAGE Claims Is New

The components of MAGE have deep precedents: models, constraints, verification, external memory, structured reasoning, and autonomous software agents. MAGE's claim concerns their architectural and disciplinary composition.

Much recent agentic software engineering asks how increasingly capable agents can perform work within the software-engineering environment they inherit. MAGE asks how that environment itself should be redesigned when autonomous implementation becomes a primary productive substrate.

Its answer is to make purposeful models, Alignment machinery, and the governed engineering environment first-class objects of software engineering, and to treat recurring judgment converted into durable structure as engineering capital. Consequential semantic judgment stays with engineers wherever representation and mechanism cannot responsibly carry it.

The claim is bounded in two directions. MAGE did not invent models, constraints, or controls, and it does not hold that model-first organization is where software engineering must arrive. What it claims is narrower: the arrangement is now buildable, and building it is an engineering problem in its own right.

Works Cited

  1. Salado, Alejandro. Rethink Engineering: Revolutionize the Way You Make Decisions. Educating Thinkers Press, 2026.
  2. Reeves, Jack W. “What Is Software Design?.” C++ Journal, 1992. https://www.developerdotstar.com/mag/articles/reeves_design.html.
  3. Cabot, Jordi. “Vibe-Driven Model-Based Engineering.” 2026. https://arxiv.org/abs/2604.10645.
© James C. Davis, 2026–present