6.2 What the Theory Predicts

If the theory is right, we should observe certain consequences. This chapter states them generally—what we should expect to observe wherever MAGE applies. It states the predictions first; the next chapter asks where they should be expected to hold.

The predictions fall into three families: trustworthy representations, adaptive governance, and engineering economics. They follow from the theory; they are not findings of this book. Each is stated here as a named hypothesis; the research agenda that closes this Part turns those hypotheses into experimental designs.

6.2.1 Trustworthy Representations

Brownfield software raises the first problem immediately: can a useful engineering model be recovered from a system that was never built around one? An agent can extract structure from implementation, but description is not obligation. A model that perfectly mirrors defective behavior can simply canonize the defect. Useful induction must therefore distinguish what the system does from what an independently justified engineering claim says it should do.

Once a model exists, maintenance becomes a second problem. "Keep the model equal to the code" is too crude. A model of permitted dependencies should disagree with code that violates them. A requirements model may intentionally describe an intended state the current implementation has not reached. The engineering problem is to state and maintain the correspondence each model claims—for architecture, behavior, process, invariants, lineage, or other views—cheaply enough to expose meaningful divergence near the change that created it.

The third problem is quality. A model can be synchronized and still be useless. Test suites provide the familiar warning: an oracle can faithfully encode the implementation rather than the requirement, or cover one narrow realization while missing the property that matters.^** Oracle overfitting is well established. A steward of a widely watched coding benchmark audited the problems a strong model kept failing and found many carried flawed tests — too narrow, or checking behavior the task never described — alongside contamination that let exposure substitute for reasoning ¹1. OpenAI, “Why SWE-Bench Verified No Longer Measures Frontier Coding Capabilities,” OpenAI, February 2026, https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/.. The lesson predates the current era: automation that optimizes against a visible oracle satisfies the oracle while silently breaking what it does not check ²2. Edward K. Smith et al., “Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair,” in “Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (Esec/fse),” special issue, Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), 2015, 532–43, https://doi.org/10.1145/2786805.2786825.. Models need analogous evaluation. The field must measure not only fidelity to artifacts, but whether the representation captures the obligations and relations needed for the engineering decisions that use it.

H1 — Representation leverage. For tasks whose required reasoning state exceeds comfortable implementation-level inspection, a task-relevant and trustworthy model will reduce reasoning and reconstruction cost per acceptable realization, or increase task scale at matched quality, compared with reasoning from lower-level artifacts alone. The advantage should increase as the required reasoning state grows.

H2 — Representation integrity. The benefits predicted by H1 will decline or reverse when models are stale, irrelevant, or poorly matched to the task. Measures of model correspondence and obligation coverage should therefore predict later churn or defect escape beyond what conventional implementation-level metrics predict.

H3 — Representation-induced determinization. For some system-level obligations, replacing raw implementation as the reasoning surface with an explicit representation of the relevant state or relation will make a repeatable predicate feasible where per-change evaluation over the implementation otherwise requires semantic reconstruction.

H4 — Representation induction and innovation. Commodity intelligence can contribute useful engineering representations, first by inducing latent structure from existing systems and, more strongly, by proposing representations that make consequential engineering questions tractable in ways the existing set of representations does not. Where those representations can be independently validated and economically maintained, they should extend the effective reasoning horizon of later agents and human engineers.

6.2.2 Adaptive Governance

Governance conversion remains primarily an act of judgment. A failure occurs; someone decides whether it is local or structural; someone decides whether future work should inherit a model, constraint, validator, architectural change, procedure—or nothing at all. Agents can already implement many of those responses. The research problem is deciding which investment is warranted, what its cheapest adequate form is, and when judgment should remain where it is.

A small example makes the distinction concrete. Suppose agents repeatedly introduce direct database access from services that are expected to use a repository layer. Repairing each occurrence fixes the local change but leaves the next agent to make the same mistake. The team can instead represent the permitted access paths and add an architectural check that rejects violations. If later work stops reproducing the failure class and requires less review to enforce the boundary, the environment has learned something useful. If legitimate exceptions are common and engineers spend more time negotiating the check than repairing the original failures, the conversion has not produced useful engineering capital.

An adaptive environment also has to subtract. A system that automatically responds to every anomaly with another lint or gate will manufacture bureaucracy faster than capital. Useful adaptation must add, strengthen, reconcile, and retire. The obligation/mechanism census from Part III provides one way to observe this: important obligations with inadequate coverage are gaps; mechanisms that no longer trace to a purpose are candidate orphans. A useful adaptive system would reduce consequential gaps without simply increasing the number of mechanisms.

Organizations make the problem harder. The person who recognizes a failure may not own the shared infrastructure capable of retiring the class. A good diagnosis can therefore die as a local patch. What matters is not whether authority resides in one architect, but whether a working path connects diagnosis to change in the shared environment.

H5 — Mechanized assurance. For obligations that are sufficiently decidable and adequately covered, repeatable independent mechanisms will reduce defect escape at matched realized throughput compared with assurance that depends on producer compliance or proportional per-change human attention. For sound admission mechanisms over mechanically decidable obligations, the covered failure class should be excluded from admitted work even when producer reliability varies.

H6 — Governance conversion. For recurring failure classes, structural interventions targeted at the class will reduce subsequent recurrence or repeated human attention relative to local repair alone, after accounting for the intervention's carrying cost. The relationship will become non-monotonic when controls accumulate beyond their useful fit.

H7 — Learning propagation. Engineering lessons will reach later relevant work faster and more consistently, and will be less dependent on continued access to the people who first supplied them, when diagnosis is connected to authority to change shared, machine-actionable engineering structure than when the lesson remains local or must propagate primarily through interpersonal communication. Personnel turnover provides one natural test: where consequential judgment has become trustworthy shared structure, later work should lose less effective engineering capability when the originating engineer is absent.

6.2.3 Engineering Economics

The economic predictions are the least settled of the three families. Representation leverage and governance conversion can be observed directly within an engineered environment; estimating their economic return requires a counterfactual: what would the same work have cost without the asset, under comparable intelligence, quality, and task conditions? Model capability is changing at the same time, token prices are moving, organizations value human attention differently, and engineering assets depreciate. The hypotheses below therefore name quantities worth measuring, not coefficients MAGE claims to know.

The strongest economic claim in MAGE is easy to state and difficult to price: durable engineering structure can make later work cheaper or safer. The DocAble support ratio shows where source accumulated, not whether that stock was valuable. Removing one artifact will not necessarily reveal its contribution when the same knowledge survives across models, tests, code, and documentation. The environment's return may not divide cleanly among individual artifacts.

The quantities that matter are therefore returns and carrying costs. How much reconstruction, review, rework, defect risk, or recovery cost does an asset retire? How much compute, latency, maintenance, context, false-positive burden, and coordination does it impose? How does that balance change as the system moves and the asset depreciates?

One implication is that effective engineering capability may partly belong to the environment, not only to the foundation model or the people currently operating it. A weaker model operating over a richly represented, well-instrumented environment may outperform a stronger model over an opaque repository because the environment has performed some of the reasoning before the interaction begins. Whether environment quality substitutes for model capability, complements it, or does neither is an empirical question.

This suggests another way to measure engineering capital. Instead of trying to price each model, validator, or procedure separately, treat a commodity agent as a standardized consumer of the environment. Hold the reasoning engine and task family fixed, vary the engineered environment, and measure how much productive capability the environment contributes: task scale reached at matched quality, reconstruction cost, intervention burden, defect escape, and durable throughput. The measured difference is not a complete valuation of engineering capital, but it shows how much otherwise intangible engineering structure contributes.

H8 — Environment fit. Increasing agentic capacity will produce more durable throughput and lower human attention in environments that adequately represent and govern the work. Where the environment fits poorly, the same additional capacity will produce more churn, intervention, or defect escape. The research agenda takes up how Modeling and Alignment separate, combine, and route across task families.

Outer-loop corollary. If commodity intelligence primarily accelerates source-code production, its benefits should remain concentrated in the coding slice of software work and increasingly encounter downstream limits in review, testing, integration, and coordination. If MAGE's account is right, stronger governed engineering environments should allow the same intelligence to assume increasing portions of the surrounding realization loop—debugging, test construction, refactoring, integration, migration, and other bounded engineering activities—while preserving durable throughput without proportionate growth in human-attention burden.

H9 — Engineering-capital return and depreciation. Useful models, mechanisms, architectures, and procedures will produce measurable reductions in future reconstruction, human attention, rework, or risk over the surfaces they cover; those returns will decline as the assets lose fit, and environments that reconcile or retire depreciated assets will outperform otherwise comparable environments that merely accumulate machinery.

The nine hypotheses fall into three families, each paired with the main quantity a study would have to measure. Table 6.2-1 collects them.

The three families state what the theory predicts. The next chapter bounds where those predictions should hold; the research agenda that follows turns them into studies that could confirm or refute the account.