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. What does not arrive automatically with that capacity is a sound specification, a useful representation of the system, or evidence that the result is acceptable. Implementation speed amplifies the engineering around it.

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 to 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. The engineering problem is still to make consequential intent available to the machinery in a form that can guide and govern realization.

When agents perform the implementation, engineering leverage moves into the engineered environment. 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.

Where engineering leverage acts Two pipelines are stacked for contrast. In the classical pipeline the engineer builds the implementation directly, so the implementation is the primary engineered object: Engineer, then Implementation, then Product. In the agentic pipeline agents build the implementation inside an engineered environment the engineer constructs, so the environment becomes the primary engineered lever: Engineer, then Engineered Environment, then Agents, then Implementation, then Product. A rust badge marks the primary node in each row; it moves upstream from the implementation to the environment. A footer strip unpacks the environment into models, obligations, evidence, controls, and infrastructure. WHERE ENGINEERING LEVERAGE ACTS CLASSICAL engineer writes the implementation Engineer Implementation primary engineered object Product AGENTIC agents write the implementation Engineer Engineered Environment primary engineered lever Agents Implementation Product Governed Engineering Environment the engineered instructions around autonomous realization models · obligations · evidence · controls · infrastructure
Figure 1.1-1. Where engineering leverage acts. When engineers write most implementation directly, much of their engineering leverage acts through the code. When agents provide abundant realization capacity, more of that leverage moves into the governed engineering environment—the software analogue of the models, fabrication constraints, process instructions, and acceptance criteria surrounding a 3D printer. The environment represents consequential intent, constrains realization, and evaluates what the fleet produces.

Table 1.1-1 sets each part of the metaphor beside its engineering counterpart.

Table 1.1-1. Reading the Printer metaphor. The correspondence separates realization capacity from the engineering structure that makes a realization trustworthy.
3D printingAgentic software engineering
desired artifactintended system/change
engineering/CAD representationspurposeful models
material + fabrication constraintsobligations + action boundaries
printeragent / agent fleet
slicing / machine processharness + workflows + tools
inspection / metrologytests + analyses + measurements
accept/reject criteriaacceptance obligations + admission authority
fabricated partrealized implementation

1.1.1 The Engineering Object

Agent products and foundation models will continue to change.** Engineering predates machine learning in its use of model to mean a purposeful representation of a system. 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 give obligations authority, 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 gives selected properties authority over what the printer is allowed to produce.

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 CITE0; MemGPT externalizes state into managed memory tiers CITE1; and Graph of Thoughts makes graph structure part of the reasoning process CITE2. In agentic software engineering: RepoCoder retrieves repository-level context CITE3; SWE-agent engineers the agent-computer interface CITE4; and AutoCodeRover reasons over program structure rather than treating a project as merely files CITE5. 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 CITE6. Part VI returns to these traditions and to what commodity intelligence changes. MAGE changes the engineering object: the concern is not principally 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. Those are different diagnoses.

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."

Works Cited

  1. Liu, Bo, Yuqian Jiang, Xiaohan Zhang, et al. “LLM+P: Empowering Large Language Models with Optimal Planning Proficiency.” 2023. https://doi.org/10.48550/arXiv.2304.11477.
  2. Packer, Charles, Sarah Wooders, Kevin Lin, et al. “Memgpt: Towards Llms as Operating Systems.” 2023. https://doi.org/10.48550/arXiv.2310.08560.
  3. Besta, Maciej, Nils Blach, Ales Kubicek, 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.
  4. Zhang, Fengji, Bei Chen, Yue 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.
  5. Yang, John, Carlos E. Jimenez, Alexander Wettig, 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.
  6. Zhang, Yuntong, Haifeng Ruan, Zhiyuan Fan, and Abhik Roychoudhury. “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.
  7. Rich, Charles, 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.
© James C. Davis, 2026–present