6.5 Software Rejoins Engineering

The reorganization just described resembles older engineering practice. Civil, mechanical, electrical, aerospace, and systems engineers routinely answer consequential questions through reduced representations of what they build: load models, circuit schematics, state-space models, simulations, drawings, requirements, and analyses. A useful representation makes an important property cheaper or safer to reason about than the realized artifact itself.

Software has always modeled too, but source code occupied an unusually powerful position. It was symbolic, executable, cheap to copy, and precise enough to become both the artifact and the representation engineers most often worked through. Secondary models therefore had to repay a standing synchronization cost. That economic difference helps explain why model-heavy software methods remained concentrated in domains where the assurance payoff justified the burden.

6.5.1 The Disciplines That Got There First

Older engineering disciplines had stronger reasons to separate representation from realization. Fabrication could be expensive or irreversible; full-scale trials could be destructive; physical iteration could take weeks or months. A structural model could answer a loading question before concrete was poured. Circuit simulation could expose a design error before a mask set was fabricated. Finite-element analysis could explore stresses before a sequence of physical prototypes was machined and broken.

The common engineering move matters: 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.

6.5.2 Model-First Engineering

The Siemens reconstruction illustrates what this looks like in a model-first 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 clarify MAGE's relationship to conventional model-based engineering. 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. Commodity intelligence may make both ends of this spectrum cheaper: strong formalization where assurance warrants it, and selective Modeling and Alignment where complete specification does not. Section 6.5.5 returns to this economic consequence.

6.5.3 Why Software Came Late to Model-First Engineering

Software's economics differed from those of older engineering disciplines. 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. But producing, understanding, debugging, and changing that source consumed skilled engineering labor—and the source itself was already a precise, executable representation through which engineers reasoned about the system.

That blurred a distinction older engineering 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 presented 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" argument CITE0 is a useful historical extreme; MAGE relies only on the narrower claim that software design and implementation have traditionally been tightly coupled.

Secondary software models therefore 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.

Commodity intelligence changes both sides of that ledger. It lowers the skilled labor required to realize and revise software, and it can lower parts of the labor required to derive, update, reconcile, and check additional representations. Neither cost becomes zero. 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.

Figure 6.5-1 sets those three economic variables — and the change that moves them — in a single view.

6.5.4 The Language of Engineering

Models are the language of engineering because engineers rarely reason about every relevant property directly from the realized artifact. They choose a representation suited to the question: a schematic for connectivity, a state model for behavior, a finite-element model for stress, a requirements model for obligation. The representation is deliberately incomplete. Its value lies in making selected properties tractable.

Software can therefore recover a familiar engineering separation: obligations from realization, acceptable variation from arbitrary choice, evidence from assertion, and authority from advice. Models, tolerances, degrees of freedom, margin, and assurance give names to different parts of that separation.

Software increasingly can work the same way. Modeling externalizes engineering knowledge into representations appropriate to the question. Alignment is separate: it gives selected obligations authority through constraints, validators, permissions, gates, or other mechanisms appropriate to their decidability and consequence. Sometimes Alignment acts directly on code or action boundaries. Sometimes a model exposes a system-level property that makes new forms of analysis and stronger Alignment possible. Modeling expands semantic reach; Alignment decides what the environment will do with what has become legible.

These are the two inheritances traced in the preceding sections: engineering uses purposeful representations to make consequential properties tractable; AI uses external representations and machinery to extend what a finite reasoner can accomplish. MAGE brings these trajectories together at the level of software engineering. MAGE makes a stronger claim about centrality: as implementation becomes abundant, purposeful representations and the machinery that gives selected obligations authority become primary engineering surfaces rather than auxiliary artifacts around implementation.

A model maintains the correspondence it claims

A useful model need not be "equal to the code." It must maintain the correspondence it claims. An architectural model may say what dependencies are permitted, not merely mirror the dependencies that happen to exist. A behavioral model may represent allowed states rather than every implementation detail. The engineering obligation is to keep those relations honest enough that the representation remains fit for the questions asked of it.

The engineering pattern is familiar: models externalize structure, instruments produce evidence, constraints limit behavior, interlocks allocate authority, and the surrounding plant or process carries discipline that individual vigilance alone cannot. Across several older engineering fields, a broad architecture recurs: explicit representations, evidence-producing instruments, constraints, and allocated authority. The falling cost of creating and maintaining additional representations makes more of that architecture economical in software.

The representational moves are old. The enforcement moves are old. What is new is the substrate they surround: abundant probabilistic implementation operating autonomously over software, together with a falling cost of producing and maintaining the additional representations that make such work legible. The combination changes which old techniques are economical enough to become ordinary practice.

Figure 6.5-2 sets the two inheritances and MAGE's composition in a single view.

6.5.5 The Expanding Economics of Explicit Engineering

Models already earn value by helping engineers and agents reason about a system and by organizing claims and evidence for assurance. Where intent becomes sufficiently explicit and evaluation sufficiently closed, the same representations can support a further step: machine realization through generation or search.

This limiting case has long been familiar. Program synthesis, compiler optimization, model-driven engineering, configuration tuning, and formal methods all exploit engineering questions that can be represented precisely enough for machines to derive, search, transform, or verify solutions. Their historical reach has been partly economic. Creating specifications, models, proofs, generators, correspondence machinery, and verification infrastructure costs engineering effort. The strongest techniques therefore earned their keep most readily where assurance demands were high enough to justify that investment.

Commodity intelligence changes that calculation from both directions.

From the high-assurance end, it may reduce the cost of strong formalization. Agents can assist with specification, proof construction, invariant discovery, model construction, and the translation between engineering intent and formal artifacts. If those gains survive independent checking and trustworthy derivation, techniques once economical only for the most consequential systems may become worthwhile farther down the assurance spectrum.

From the informal end, commodity intelligence changes a different calculation. Explicit engineering structure need not determine the implementation completely to earn a return. A dependency model can make an architectural question tractable; a state machine can expose legal transitions; an invariant can support bounded checking; a schema or validator can give one obligation authority while leaving the rest of realization open. Cheaper representation, reconciliation, realization, and evaluation can therefore make some Modeling and Alignment worthwhile in systems for which full formalization remains uneconomic.

MAGE is principally concerned with this second movement. It does not require a common formal semantics, complete specification, or trustworthy derivation from model to implementation. It asks which consequential knowledge should be made explicit, which obligations should acquire authority, and which remaining degrees of freedom can safely be left to autonomous realization. At the upper limit, those degrees of freedom may shrink enough that generation, synthesis, or proof-directed realization becomes preferable. Most software need not reach that limit for explicit engineering structure to pay.

Figure 6.5-3 puts the two economic movements together.

The techniques are old; their economic range can change. Strong formal methods have historically earned their cost most readily where assurance justified substantial investment in specification and verification. Commodity intelligence may extend their economical range downward. MAGE predicts a complementary movement from ordinary software practice: explicit representations and authoritative obligations become worthwhile before complete formalization does. These are not competing predictions. Commodity intelligence can simultaneously make the strongest techniques economical for more systems and make partial but useful engineering structure economical for systems that remain far from full formalization.

The two movements should not be confused. A machine-generated proof checked by a small trusted kernel can reduce the cost of strong assurance without weakening its evidentiary standard. An agent-generated architecture model used to guide implementation can reduce reconstruction cost without providing anything like that guarantee. Both may be valuable. They occupy different points in the space of representation, authority, and evidence.

Nor should movement toward greater explicitness be mistaken for a maturity ladder. The appropriate endpoint depends on the engineering surface. A security protocol may warrant a formal state model while a neighboring user-interface decision remains intentionally open. One component may admit synthesis while another still requires iterative discovery. The economic unit remains the obligation or engineering surface, not the repository as a whole.

MAGE is also applicable at different engineering scales. An individual engineer can model the part of a system under active change and govern its realization. A team can connect those local models to shared architecture, ownership, and operational knowledge. A product can connect models and obligations across engineering surfaces, and an organization can carry selected policies, assurance obligations, and engineering knowledge across products.^** This interacts with Conway's law, which relates system structure to organizational communication structure ²2. Melvin E. Conway, “How Do Committees Invent?,” Datamation 14, no. 4 (1968): 28–31.. MAGE does not remove that coupling, but explicit models provide additional surfaces—such as architectural relations, security obligations, or assurance claims—around which responsibility can be organized across implementation boundaries. Purposeful models and explicit correspondence allow these scales to remain distinct while still informing and constraining one another. The important judgment can therefore remain at the level where it belongs rather than requiring either complete local autonomy or one organization-wide model.

Scale and assurance strength are separate choices. One engineer may use formal verification for a consequential protocol while a large organization relies mostly on design documents, tests, runtime evidence, and human judgment. Organization-wide adoption does not imply maximal formalization, nor does strong assurance require organization-wide adoption. MAGE can range from lightweight represented intent and selective checks to formal specifications and trustworthy derivation. What remains constant is the engineering problem: deciding what must be represented, what evidence is sufficient, which obligations should acquire authority, and which decisions still require judgment.

The frontier is not a destination

Neither frontier should be confused with a destination for software engineering as a whole. Search works when we know enough about what counts as success. Many consequential engineering questions remain open because the correct shape of the system is itself being discovered: which abstraction matters, which tradeoff users will accept, which failure will dominate in operation, or which requirement the organization actually intends. In those cases, implementation is not merely realization. It is an experiment that produces information about the specification. And even a question that is closed today may reopen as users, dependencies, organizations, regulations, workloads, or adversaries change. Software evolution therefore remains an outer loop around increasingly powerful episodes of automated realization ³3. M. M. Lehman and J. F. Ramil, “Software Evolution—Background, Theory, Practice,” Information Processing Letters 88 (2003): 33–44.. MAGE can turn sufficiently closed engineering questions into search problems when their consequential shape is knowable. It should not get there by pretending that unresolved uncertainty has disappeared.

The corresponding failure mode is premature closure. Explicit does not mean correct. If the organization does not yet know what users need or which tradeoff is acceptable, formalizing one conjecture merely makes the wrong target easier to optimize, and commodity intelligence can make the failure more consequential because it can elaborate the mistaken premise cheaply and at scale.

Engineering capital can also move the frontier within one system. A model built for today's migration can make tomorrow's change searchable; a differential harness can turn a future rewrite into cheap comparison; a validator can convert repeated judgment into evaluation. Engineering capital can therefore enlarge the region of work that later can be delegated safely to search.

MAGE predicts a moving boundary, not complete specification. Requirements emerge through use, organizations change, adversaries adapt, and systems alter the environments that generate their next requirements. Commodity intelligence can move both economic frontiers; it does not eliminate the world beyond them.

6.5.6 What Happened to the Cost?

Part V left an economic question hanging. DocAble reached an implementation scale one engineer could neither construct nor inspect directly, while substantial engineering effort accumulated around representation, evidence, control, and operation. What, economically, had changed?

The productivity answer is incomplete

The obvious answer — the agents made the programmer more productive — is not wrong so much as incomplete. It treats software production as the same work carried out with a larger coefficient in front of it. The case suggests something more structural. Implementation became dramatically cheaper, while scarce engineering effort moved elsewhere: deciding what accessible meant for unfamiliar document formats, finding useful abstractions, representing relationships that agents would otherwise reconstruct, constructing independent evidence, bounding autonomous work, and operating the environment that held the resulting system together. Part V already showed where that engineering judgment went.

Software engineering has priced this before

Software engineering has asked related questions before. Albrecht's Function Points separated functional size from source-code volume ⁴4. Allan J. Albrecht, “Measuring Application Development Productivity,” in “Proceedings of the Joint SHARE/GUIDE/IBM Application Development Symposium,” special issue, Proceedings of the Joint SHARE/GUIDE/IBM Application Development Symposium (Monterey, CA), 1979, 83–92.; Jones built function-point measurement into a broad empirical program on productivity, quality, and cost ⁵5. Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality, 3rd ed. (McGraw-Hill, 2008).; Boehm's COCOMO related size and project characteristics to effort and schedule ⁶6. Barry W. Boehm, Software Engineering Economics (Prentice-Hall, 1981).. These traditions caution against a simple "coding got cheaper" story: classical cost models were never mere counts of typing effort — integration, reliability, personnel, tools, complexity, and platform already mattered. MAGE makes a narrower conjecture: commodity intelligence may have changed their relative prices enough to shift the distribution of scarce engineering effort.

CAVEAT

Inset — The most conjectural claim in this book

The DocAble case establishes that implementation volume, direct human inspection, and engineering effort became radically decoupled in one production project. It does not establish a new general cost function for software engineering. We do not yet know how strongly implementation costs will fall across project classes, which other costs will then dominate, how model capability changes the balance, or whether investment in a governed engineering environment repays its carrying cost outside cases like the one studied here. The economics that follow are hypotheses and measurement questions, not results.

The conjecture, stated plainly

With that boundary in place, the conjecture can be stated plainly. Functional scope still costs something. Complexity still costs something. Integration, assurance, operations, and maintenance certainly do. But when a fleet produces and revises implementation at a rate no human team of comparable size could directly match, implementation labor may cease to dominate the marginal cost of many changes. Scarce effort moves toward the work surrounding realization: specifying intent, choosing abstractions, maintaining useful representations, constructing convincing evidence, resolving consequential ambiguity, and deciding what should acquire authority.

The environment has a carrying cost

MAGE adds a cost category that source-centric measures make easy to miss: the governed engineering environment itself. Models must be created and reconciled. Validators must be written and recalibrated. Skills and runbooks must be maintained. Gates impose friction, and observability has an operating cost. Every durable mechanism carries a price after its construction.

A model that once retired repeated reconstruction can decay into stale overhead; a validator can outlive the obligation it protected; a gate can cost more than the failure it prevents. Engineering capital depreciates. The economic question is therefore not whether more engineering structure is good in the abstract, but whether a particular investment retires enough future judgment, rework, or risk to justify its construction and its carrying cost.

The distinction is a stock-and-flow one. A flow of current engineering cost — realization, human judgment, evidence and assurance, environment operation, and the maintenance of models and mechanisms — funds a stock of engineering capital: models, skills, validators, architecture, and automation. That stock pays back through less future reconstruction, review, and rework, and through safer autonomous delegation, net of depreciation and carrying cost.

In that sense engineering capital is an economic claim as much as an architectural one. An engineering asset earns the name only when later work inherits useful capacity from it. Part V made that distinction explicitly: the roughly three-to-one ratio of support apparatus to production source described where source accumulated, not how much value it represented. The capital claim begins only where those structures reduce later reconstruction, review, rework, risk, or recovery cost.

The return appears across the product lifecycle. An architectural model can reduce the judgment required for later features or repairs; an incident converted into a runbook or deterministic mechanism can reduce the cost of later operations; durable traceability can reduce the cost of assurance after later changes. The effect is not tied to lifecycle labels. A maintenance change can expose a new engineering problem, while a feature realization under well-established obligations may require little new judgment. What matters is whether later work can inherit useful capacity from earlier engineering. Appendix F develops this lifecycle view.

The paradox changes what we should measure

This reframes the apparent DocAble paradox. The project did not make engineering free; it substituted abundant implementation capacity for one historically expensive input and spent scarce effort elsewhere — on abstractions, represented intent, independent evidence, operating structure, and repeated decisions about which failures deserved durable treatment. The implementation rate was real, and so were the engineering costs. The costs had moved. Whether they move the same way elsewhere is the open question.

If implementation volume becomes less predictive of scarce engineering effort, what should an agentic-era measure capture? Lines of model source are not the answer, and counting models, validators, or gates would repeat the mistake of treating artifact volume as value. The quantities that matter concern the work the environment retires: reconstruction avoided, human attention displaced from routine judgment, obligations made mechanically decidable, defect escape reduced, recovery shortened, or larger tasks delegated at matched quality. MAGE does not yet provide a calibrated unit for any of them.

Those quantities are measurable, but this book does not yet measure them. The old software price list appears to be changing; its replacement has not yet been measured.

6.5.7 What MAGE Claims Is New

MAGE does not claim to have discovered models, constraints, verification, external memory, structured reasoning, or autonomous software agents. Its claim is architectural and disciplinary. Much recent agentic software engineering has asked 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; to treat recurring judgment converted into durable structure as engineering capital; and to leave consequential semantic judgment with engineers where representation and mechanism cannot responsibly carry it. The tools are new; the underlying engineering arrangement is not.