6.3 What the Theory Predicts

The scope conditions imply observable consequences. Section 6.2 stated where MAGE should apply. This chapter asks what we should observe when it does.

The predictions fall into three families: trustworthy representations, adaptive governance, and engineering economics. They are predictions derived from the theory, not findings of this book.

6.3.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 required by the engineering decisions made through it.

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

H2 — Representation integrity. Stale, irrelevant, or poorly chosen models will reduce or reverse the benefit in H1; measures of model correspondence and obligation coverage should therefore predict later churn or defect escape beyond conventional implementation-level metrics.

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.

6.3.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 frontier is deciding which investment is warranted, what its cheapest adequate form is, and when judgment should remain where it is.

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 observable surface: 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. The relevant organizational variable is not whether authority resides in one architect, but whether a functioning path connects diagnosis to shared environmental change.

H4 — Mechanized assurance. For obligations that are sufficiently decidable and adequately covered, repeatable independent mechanisms will reduce defect escape relative to assurance that requires proportional per-change human attention; the advantage should widen as autonomous throughput increases.

H5 — 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, net of the intervention's carrying cost. The relationship will become non-monotonic when controls accumulate beyond their useful fit.

H6 — Learning propagation. Engineering lessons will reach later relevant work faster and more consistently when diagnosis is connected to authority over shared, machine-actionable environmental structure than when the lesson remains local or must propagate primarily through interpersonal communication.

6.3.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 the same work would 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 define 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. Nor will removing one artifact necessarily reveal its contribution when the same knowledge survives across models, tests, code, and documentation. The environment's return may not decompose artifact by artifact.

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 agent capability may partly belong to the environment, not only to the foundation model. 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 operationalize 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 makes otherwise intangible engineering structure empirically visible.

H7 — Environment moderation. The effect of increasing agentic capacity on durable throughput, defect escape, and human-attention burden will depend on environment quality: capacity gains should translate into more durable progress in stronger environments and into more churn or intervention in weaker ones.

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.

H8 — 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 eight hypotheses divide across the three families, each paired with the core quantity a study would have to measure. Table 6.3-1 collects them.

6.3.4 How Could We Test This?

The hypotheses do not require eight unrelated studies. Three designs cover much of the program.

Multi-project longitudinal design

This design should vary or observe engineered-environment quality while tracking durable throughput, defect escape, and human-attention burden over weeks or months. The strongest version is a crossed experiment: several reasoning engines from weaker to frontier, several otherwise comparable environments from thinly to richly engineered, and the same task families across every cell. The interaction would distinguish three possibilities. If richer environments primarily substitute for raw model capability, weaker models should close part of the gap in stronger environments. If the two are complementary, the strongest models should gain most from strong environments. If environment quality contributes little, the cells should move mainly with model capability. This design bears directly on H1, H7, and H8.

The crossed experiment should also measure the distribution of human work and the productive capacity stored outside the agent. Hold the task family and reasoning engine fixed, vary environment quality, and record how much human attention remains across coding, debugging, test construction, review, environment setup, integration, recovery, and other activity classes, alongside task scale, reconstruction cost, intervention burden, defect escape, and durable throughput. A richer environment that reduces only code-production time would support the narrower productivity account; one that shifts several classes of realization work out of repeated human execution while maintaining quality would support MAGE's broader account of how engineering work shifts. Kumar et al.'s sixteen activity classes provide an existing measurement vocabulary, avoiding the need for another MAGE-specific taxonomy ³3. Sukrit Kumar et al., “Time Warp: The Gap between Developers' Ideal Vs Actual Workweeks in an AI-Driven Era,” in “Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-Seip),” special issue, Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2025, 12–22, https://doi.org/10.1109/ICSE-SEIP66354.2025.00007..

Subsystem-level design

It should compare engineering surfaces that differ in representation and governance while holding as much surrounding repository context constant as possible. Track model correspondence, reconstruction effort, intervention, churn, and defect escape. Stepped introduction of a model or mechanism is particularly useful because the same subsystem supplies its own pre-intervention baseline. This design tests whether representation leverage, determinization, and mechanized assurance appear where the theory predicts rather than merely correlating with generally well-run projects.

Event-centered longitudinal design

It should follow one failure class through its whole life: first occurrence, repeat exposure, structural recognition, local repair, any durable conversion, propagation to later work, later recurrence, and eventual maintenance or retirement of the resulting asset. This is the strongest way to separate "the engineer got better" from "the environment learned." Applied across organizations, it also tests whether authority pathways determine whether a local diagnosis becomes shared engineering capital.

What the designs still need

All three designs require credible measures of durable throughput, human-attention burden, environment quality, and engineering-capital return. Until those are available, support ratio, mechanism count, and repository size should remain descriptive rather than proxies for maturity or value.^†† Candidate measures such as development completeness, redundant-encoding density, and agent-legibility remain exploratory and are not part of MAGE's canonical vocabulary.

Commodity intelligence may make some of these experiments unusually tractable: the reasoning engine, repository state, task family, and engineered environment can be held approximately fixed while one representation or mechanism varies.

The theory has now specified its mechanisms, scope conditions, and testable consequences. The remaining chapters ask what follows for software engineering if the account is substantially right.