1.1 The Printer

Coding agents make implementation cheap enough to change the engineering problem. Describe a change and a capable agent can often build it quickly, at a scale that once required substantial human effort. But the agent may not build what you wanted. Reliable production still requires a sound specification, useful representations, and evidence that the result is acceptable.

Think of the agent first as a 3D printer: productive machinery that can realize an unusually broad range of engineering intent. A conventional machine tool arrives with a comparatively settled operation—cut here, drill there, fasten these parts. A 3D printer is more open-ended.^** I use open-ended here for a productive technology whose useful output classes are not fixed by the machine itself. The capability arrives before the engineering conventions for exploiting it. New artifact types, representations, interfaces, constraints, and operating practices are discovered as people learn what the technology is useful for. Writing and general-purpose computation offer earlier examples; commodity generative intelligence adds a similarly broad realization substrate to engineering. The same machine can fabricate a gear, a bracket, a housing, or a prosthetic part. Its productive capacity does not tell the engineer which object to make, what properties that object must satisfy, or which representation is adequate for realizing those properties.

That is the useful resemblance to commodity intelligence. A coding agent supplies broad realization capacity without supplying the engineering discipline for using it. The engineer must still decide which distinctions matter, what must be represented explicitly, which choices may remain open, and which boundaries the productive machinery may not cross. Open-ended capability therefore creates a second design problem: engineers must also design the forms, types, interfaces, constraints, and evidence through which that capability can be used reliably.

A 3D printer also makes clear that intent is not the same thing as fabrication instructions. A photograph can communicate the desired appearance of a part without specifying its internal geometry, material, tolerances, load paths, or allowable joints. The machine needs a representation adequate to the properties the part must have, together with constraints on how realization may proceed. Software agents can infer much more from an incomplete description than a physical printer can, but inference does not remove the distinction. That inferential capacity is precisely what makes the machinery powerful, but inference remains different from an engineered guarantee. The engineering problem is still to make important engineering intent available to the machinery in a form that can guide and govern realization.

Cheap implementation therefore creates a delegation opportunity, not an abdication opportunity. Engineers can delegate increasing amounts of realization while remaining responsible for the resulting system. The engineering problem is not how to keep humans performing work that machines can perform. It is how to delegate that work without surrendering the control required to understand, direct, evaluate, and change the resulting system.

When agents perform the implementation, more of the engineer's control over realization must act through the engineered environment. This is the level of indirection introduced in the Preface. Instead of expressing engineering intent primarily by writing the implementation, the engineer designs an environment through which autonomous implementation proceeds. That indirection creates a new engineering surface: representations can carry consequential knowledge, mechanisms can enforce obligations, and agents can remain free to choose among realizations that satisfy them. Figure 1.1-1 shows the shift.

In the printer metaphor, the governed engineering environment is the engineered instruction set around the productive machinery: the representations that tell it what matters, the boundaries that constrain realization, and the evidence used to decide whether the result is acceptable. Some of that environment helps the agent reason better; other parts remove selected judgments from the agent's discretion altogether.

1.1.1 The Engineering Object

Agent products and foundation models will continue to change.^** Engineering predates machine learning in its use of models as purposeful representations of systems. Machine learning later adopted the same word for a learned approximation of a function—also reasonably a model, but a different kind. This book gives the engineering usage precedence: unqualified model means a purposeful representation of an engineered system or some property of it. I therefore use foundation model for the trained machine-learning system and agent for the acting system built around one through a harness, tools, and working state. Where the distinction matters, I will not ask the reader to infer which "model" I mean. The durable engineering problem begins when an agent works autonomously on a system large enough, important enough, or long-lived enough that "it usually works" is not an acceptable standard.

The object of engineering therefore expands beyond the implementation. Engineers also design the environment through which autonomous work proceeds: what the agent can know, what it may do, what evidence it must produce, and which obligations the environment will enforce.

MAGE is principally about that environment. We will get to foundation models, harnesses, tools, hooks, skills, and workflows because their properties determine what can be engineered around them. But the method lies in how engineers represent what matters, how they enforce obligations, and how they decide which recurring judgments should become durable engineering structure.

In the printer metaphor, Parts II and III develop the two missing halves of the instruction package: Modeling makes consequential properties explicit; Alignment enforces selected obligations on what the printer is allowed to produce.

That environment need not simply reproduce the one built for human developers. Agents can consume and maintain representations at scales that would be impractical for people, and automated analyses can check properties that human review would otherwise have to reconstruct from implementation. The design question is therefore two-sided: what existing engineering machinery should agents inherit, and what stronger machinery becomes practical because the workers are now machines?

MAGE is not a general software-engineering method. It does not attempt to teach engineers which programming language to choose, which architectural or design pattern fits a system, or which verification technique is appropriate. Those questions draw on decades of accumulated software-engineering theory and practice. MAGE asks a different question: when such engineering knowledge matters to autonomous implementation, how should it be represented so that the machinery can use it, and which resulting obligations should constrain what the machinery may produce?

Commodity intelligence can also change which traditional engineering choices remain consequential. Consider the choice of a programming language. A human team might once have chosen Java over another suitable language simply because its developers already knew Java. If an agent can implement competently in either language, that constraint largely disappears: some language still has to be chosen, but the particular choice may no longer deserve much engineering attention. Other language choices remain consequential. A deployment target may require a particular toolchain, or a safety requirement may favor a language that provides a needed property. The relevant question is therefore not whether engineers have traditionally made a choice, but what property made the choice consequential.

The same distinction applies at larger scales. Suppose a service needs persistent storage. If either a relational or nonrelational database can satisfy every property that matters, choosing between them may simply be a degree of freedom left to realization. But if the system requires transactions across related records, a particular consistency model, or another property that distinguishes the alternatives, the choice becomes consequential. MAGE does not supply the database theory needed to make that judgment. It asks that the consequential property be represented—and, where necessary, enforced—rather than relying on each implementing agent to rediscover why the choice mattered.

Notice the distinction between unmodeled and free. A choice is unmodeled when the engineering representations do not state it; it is free only when engineering permits the alternatives. Suppose the model says nothing about which database to use. If either database really can satisfy every consequential property, the omission represents a genuine degree of freedom. But if one alternative would violate a security, consistency, or performance obligation, the choice was never free. The model simply failed to make the relevant obligation explicit.

That emphasis has important antecedents. AI research has repeatedly improved machine reasoning by changing the representations, memory, tools, and external machinery available to the reasoner. Recent agentic software-engineering systems similarly improve performance through retrieval, program structure, and purpose-built interfaces.^†† On the AI side: LLM+P translates natural-language problems into a classical planner ¹1. Bo Liu et al., “LLM+P: Empowering Large Language Models with Optimal Planning Proficiency,” 2023, https://doi.org/10.48550/arXiv.2304.11477.; MemGPT externalizes state into managed memory tiers ²2. Charles Packer et al., “Memgpt: Towards Llms as Operating Systems,” 2023, https://doi.org/10.48550/arXiv.2310.08560.; and Graph of Thoughts makes graph structure part of the reasoning process ³3. Maciej Besta et al., “Graph of Thoughts: Solving Elaborate Problems with Large Language Models,” in “Proceedings of the AAAI Conference on Artificial Intelligence,” special issue, Proceedings of the AAAI Conference on Artificial Intelligence 38, no. 16 (2024): 17682–90, https://doi.org/10.1609/aaai.v38i16.29720.. In agentic software engineering: RepoCoder retrieves repository-level context ⁴4. Fengji Zhang et al., “Repocoder: Repository-Level Code Completion Through Iterative Retrieval and Generation,” in “Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,” special issue, Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (Singapore), 2023, 2471–84.; SWE-agent engineers the agent-computer interface ⁵5. John Yang et al., “SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering,” in “Advances in Neural Information Processing Systems 37,” special issue, Advances in Neural Information Processing Systems 37, 2024.; and AutoCodeRover reasons over program structure rather than treating a project as merely files ⁶6. Yuntong Zhang et al., “Autocoderover: Autonomous Program Improvement,” in “Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA '24),” special issue, Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA '24) (New York), 2024, https://doi.org/10.1145/3650212.3680384.. The ambition predates foundation models: Rich and Waters's Programmer's Apprentice envisioned an AI system as a new agent in the software process, sharing explicit programming knowledge with the engineer across implementation, design, and requirements ⁷7. Charles Rich and Richard C. Waters, “The Programmer's Apprentice Project: A Research Overview,” Computer 21, no. 11 (1988): 10–25, https://doi.org/10.1109/2.86782.. Part VII returns to these traditions and to what commodity intelligence changes. MAGE changes the engineering object: the concern is not what a reasoner needs to solve one task, but the engineered environment through which autonomous software work proceeds over time.

1.1.2 Suspect the Setup First

The Printer suggests a useful diagnostic rule: suspect the engineered setup before inferring a machine limit. Observed performance is a property of the whole arrangement, not just the productive machinery.

A 3D printer separates productive capability from the instructions that condition it. A photograph may show what an object should look like, but appearance does not specify internal structure, material, tolerances, load paths, or fabrication constraints. A failed part can therefore reveal several different problems: the machine lacked capability; the model omitted a consequential property; the chosen material could not satisfy it; or the fabrication instructions permitted a realization that should have been ruled out.

Software agents blur this distinction because they can infer missing structure. A capable agent may produce an impressive result from a screenshot, prose request, or incomplete specification. But inferred completion is not an explicit statement of which properties must hold, which tradeoffs are acceptable, or what evidence establishes acceptance.

When an agent produces the wrong result, inspect first what the engineer controlled: the instructions, the representation of the problem, the task boundary, the available tools, and the evidence the work was required to satisfy. Sometimes the foundation model simply lacks the necessary capability. Failed output alone does not establish that diagnosis.

Abundant implementation raises the stakes. Capable agents can execute a bad direction with extraordinary speed. Velocity amplifies sound engineering and bad engineering alike.^‡‡ My field notes on this point were less measured: "Claude is the fastest road to hell."