What the Theory Claims

MAGE proposes a directional account of agentic software engineering. Its central claim is that agentic capacity acts through the engineered environment surrounding the work. Increasing implementation capacity should therefore have different effects depending on the representations, evidence, enforcement, and other engineering structure through which it acts.

Three claims carry most of the theory.

Environment fit moderates capacity. Additional agentic capacity should produce more durable throughput when the engineered environment fits the work, and more churn, escaped failure, repeated intervention, or control friction when it does not.

Representation creates leverage. A task-relevant and trustworthy representation can reduce the reconstruction required to answer an engineering question and can expose consequential distinctions at an abstraction more tractable than the underlying implementation. Its value should increase where reasoning would otherwise exceed the practical horizon of the reasoner.

Engineering capital amortizes judgment. Models, mechanisms, procedures, evidence, and other durable structures can reduce the reconstruction, repeated judgment, rework, or risk later work must purchase again. They provide that return only while they remain fit; stale or incoherent structure can instead become a cost.

These claims are conditional. MAGE does not predict that more modeling is always better, that every obligation should become deterministic, or that accumulated engineering machinery is intrinsically valuable. Representation, enforcement, and engineering capital cost something to build, maintain, coordinate, and use. Some consequential judgments remain contextual or too hard to observe reliably and properly remain matters for expert judgment.

The research agenda in this Part identifies ways to test these claims and the mechanisms proposed to explain them. MAGE is not presented as a finished law of agentic software engineering. It is an explanation that can be tested, refined, bounded, or rejected.

Part VII asks what follows for software engineering—and for the engineer—if that explanation is substantially right.