Chapter 7 — The Profession  ::  §7.1

§7.1 The Reorganization of Software Work

Commodity intelligence does not invalidate software engineering. It changes its cost structure. When implementation consumes less of the engineering budget, the relative value of specification, architecture, modeling, validation, measurement, and governance rises. The profession changes not because its foundations failed, but because the bottleneck moved.

In software, MAGE is software engineering under changed economics. Many of its underlying moves are old: externalize intent, hide volatile decisions behind boundaries, test claims against evidence, automate repeatable operations, learn from failure. What changes is how far those moves can be carried when implementation and routine analysis become cheaper while autonomous work makes it increasingly expensive for humans to reconstruct the same knowledge repeatedly.

7.1.1 Was Implementation Ever the Bottleneck?

A reasonable objection begins with a fact: software engineers do not spend most of their workweek typing code. This result predates generative AI. Meyer et al., drawing on 5,971 responses from professional developers, found that software work spans a much broader mixture of development and non-development activities. More recently, Kumar et al. separated the developer workweek into sixteen activities; in their Microsoft sample, coding new features occupied roughly 11 percent of the actual week, alongside debugging, architecture and design, code review, testing, refactoring, environment work, security, communication, and other activities.^** André N. Meyer et al.;¹1. André N. Meyer et al., “Today Was a Good Day: The Daily Life of Software Developers,” IEEE Transactions on Software Engineering 47, no. 5 (2021): 863–80, https://doi.org/10.1109/TSE.2019.2904957. Sukrit Kumar et al..²2. 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. Kumar et al. distinguish sixteen activities and report approximately 12 percent of the actual week in communication and meetings, 11 percent in coding, 9 percent in debugging, 6 percent in architecture and design, and 5 percent in pull-request and code review.

Butler et al. turn that observation into a critique of contemporary GenAI.^†† These developer-time studies describe how work was allocated before today's stronger autonomous coding agents; I use them as evidence about work allocation, not as an empirical ceiling on what later bounded agents can perform. If the technology merely makes the coding slice faster, its whole-job effect has a low ceiling. Even if coding occupies only roughly 10–15 percent of the workweek, doubling performance on it cannot double developer productivity; faster source production can simply move pressure downstream into review, testing, integration, and other work. Their criticism applies well to GenAI used as individual code-generation assistance. It also supports a broader point MAGE shares: lines of generated code are not an engineering outcome, and handing developers a tool does not by itself redesign the system of work around them.^‡‡ Jenna Butler et al..³3. Jenna Butler et al., “Eight Myths on Software Engineering and GenAI,” Queue 24, no. 2 (2026), https://doi.org/10.1145/3807963. The article's "Writing Code Is the Bottleneck" discussion explicitly frames the problem as GenAI used primarily to accelerate code creation while the surrounding development loop remains unchanged.

The disagreement begins when that fixed slice is treated as a bound on agentic engineering. Time categories are not independent production stages. Software engineers learn about a design by realizing it: implementation exposes missing abstractions; debugging changes what we believe about behavior; tests expose underspecified obligations; refactoring discovers structure; deployment reveals couplings that static design did not anticipate. This interleaving is not a new observation. Ralph's Sensemaking–Coevolution–Implementation theory models software development as repeated movement among understanding the context, revising the problem and design together, and constructing, debugging, and deploying the artifact; a later multi-method study using more than 1,300 developers and four longitudinal cases strongly supported that process account.^§§ Paul Ralph, the Sensemaking–Coevolution–Implementation theory,⁴4. Paul Ralph, “The Sensemaking–Coevolution–Implementation Theory of Software Design,” Science of Computer Programming 101 (2015): 21–41, https://doi.org/10.1016/j.scico.2014.11.007. and its multi-method follow-through,⁵5. Paul Ralph, “Software Engineering Process Theory: A Multi-Method Comparison of Sensemaking–Coevolution–Implementation Theory and Function–Behavior–Structure Theory,” Information and Software Technology 70 (2016): 232–50, https://doi.org/10.1016/j.infsof.2015.06.010. which combined a survey of more than 1,300 developers with four longitudinal case studies and reported strong support for the SCI account. For an older and deliberately stronger version of the "implementation is design" argument, see Jack W. Reeves.⁶6. Jack W. Reeves, “What Is Software Design?,” C++ Journal, 1992, https://www.developerdotstar.com/mag/articles/reeves_design.html.

MAGE therefore uses implementation capacity in an economic rather than time-sheet sense. Every design hypothesis that has to be realized before the team can learn from it imposes a cost, even if the eventual keystrokes occupy only a small fraction of the calendar. Reduce that cost sufficiently and more alternatives become affordable, feedback arrives sooner, and intelligence can participate in more of the surrounding loop. Modern coding agents already reach beyond source generation into repository inspection, debugging, test construction, refactoring, tool execution, and multi-step changes. Whether they can safely take on still more of that loop is exactly the engineering question MAGE addresses.

This makes the disagreement empirically testable. If agents remain trapped in the IDE, the 15-percent argument largely wins. If governed agents can assume meaningful portions of debugging, testing, refactoring, integration, migration, and operation without proportionate growth in human review, a fixed coding-time slice is no longer the right model of attainable leverage. MAGE is about crossing that boundary without losing engineering control.

DevOps offers a particularly close precedent. Infrastructure as Code and Policy as Code moved knowledge that once lived in operating practice into executable artifacts. MAGE generalizes the move without insisting on code as the form: an engineering decision might become a type, model, schema, validator, permission, workflow, or documented review obligation. Useful engineering knowledge increasingly becomes structure later work can inherit; residual semantic judgment remains with people.

MAGE inherits the older disciplines rather than replacing them: explicit intent, short feedback, automated delivery, and governed autonomy solve different parts of the engineering problem.

7.1.2 Agents Entered an Implementation-Centered Discipline

The first generation of agentic software-engineering research inherited the engineering object already in front of it: a repository and a software-development task. The central question was how to make an increasingly capable reasoner perform that task more effectively.

The progression is instructive. RepoCoder retrieves repository-level information that would otherwise lie outside the immediate completion context.⁷7. 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 shows that the interface between an agent and its computer materially affects its ability to navigate repositories, edit files, and execute tests.⁸8. 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. AutoCodeRover goes further toward representation: rather than treating a project as merely a collection of files, it exploits program structure and an abstract syntax tree to localize and reason about changes.⁹9. 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. Later work extends the trajectory toward inferred intent, extracting specifications from the same artifacts.¹⁰10. Haifeng Ruan et al., “Specrover: Code Intent Extraction via Llms,” in “Proceedings of the 47th IEEE/ACM International Conference on Software Engineering,” special issue, Proceedings of the 47th IEEE/ACM International Conference on Software Engineering, 2025, https://doi.org/10.1109/ICSE55347.2025.00080. These systems differ substantially, but share an orientation: improving the machinery an agent uses to act on the software artifact.

MAGE accepts that machinery and enlarges the engineering object. The question is no longer only how an agent should navigate a repository, retrieve context, use tools, or construct a patch. It is what durable environment should be engineered around autonomous implementation: which system properties deserve explicit representation; which obligations deserve enforcement; what evidence work must produce; how representations remain in correspondence with the implementation; and how recurring judgment becomes machinery inherited by later work.

The difference is one of level, not opposition. Repository retrieval, structured code search, agent-computer interfaces, tests, and tool use all belong inside a governed engineering environment. MAGE's claim is that they are pieces of a larger engineered substrate rather than accessories to a coding agent.

7.1.3 The Old Dream, with a New Substrate

The ambition is older than the present substrate. In the 1980s, Charles Rich and Richard Waters's Programmer's Apprentice envisioned an AI system not merely as a programming tool but as an agent in the software process. The engineer would share programming knowledge with the Apprentice and delegate work across implementation, design, requirements, verification, explanation, and documentation.¹¹11. 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. Its internal representations made programming concepts explicit so that routine questions could be answered from represented knowledge rather than reconstructed from first principles.

The project realized important pieces of that vision, but under different constraints. Its intelligence depended heavily on programming knowledge deliberately encoded into specialized representations; Rich and Waters themselves observed that the economics failed when too much knowledge had to be supplied for each problem. Commodity intelligence changes that premise. A general-purpose reasoner can now arrive with substantial prior competence, enter an unfamiliar repository, use tools, interpret natural-language intent, and construct substantial implementations without the engineering organization first encoding everything it might need to know.

Old ideas therefore return throughout MAGE. The ambition of an intelligent programming partner is old. Explicit machine-usable engineering knowledge is old. Models, constraints, verification, feedback, and delegated realization are old. What changes is the economics. Earlier systems could demonstrate pieces of the vision; today's systems realize enough of it to expose the next-order engineering problems: keeping representations trustworthy, deciding which obligations deserve enforcement, producing evidence at agentic velocity, and converting recurring judgment into machinery that later work inherits.

MAGE does not depend on a historically novel ambition. It is an engineering account of what happens when much of that ambition becomes operational at production scale.

This history also shows a broader progression. AI has long engineered external machinery around finite reasoners through memory, structured representations, planners, tools, and world models. Agentic software engineering applies related machinery to work over repositories through retrieval, program-aware search, purpose-built interfaces, tests, and inferred specifications. MAGE moves the engineering boundary outward again: the repository and agent remain part of the system, while purposeful system models, enforced obligations, evidence, controls, and the machinery that maintains them become first-class objects of software engineering.

7.1.4 Where Engineering Effort Moves

As implementation becomes cheaper, the allocation of engineering work changes even if the eventual organization of that work remains uncertain. Delegation expands; responsibility remains. The fleet can assume more of the analysis, transformation, implementation, and routine remediation across the lifecycle; engineers must retain sufficient control to remain responsible for intent, abstraction, evidence, tradeoffs, and acceptance. Scarce human effort concentrates where that responsibility sits. We can say with more confidence that implementation becomes less dominant as a claim on human effort than we can say what replaces it. Figure 7.1-1 shows that movement.

Figure 7.1-1. Where Engineering Effort Moves. As the fleet assumes work across the lifecycle, the engineer increasingly works through the surrounding engineering environment: specifying intent, choosing consequential abstractions, evaluating evidence, resolving tradeoffs, and adapting the environment itself.

The figure identifies a broad redistribution of work, not the eventual form of software engineering. Its governed environment holds several kinds of machinery: models and context, permissions and constraints, evidence and validators, admission mechanisms, and operational controls. Nothing in the figure says that displaced engineering effort becomes modeling.

Where that displaced effort settles depends on which parts of the production system become cheaper and more reliable. Chapter 6 supplies the quantities. Satisfactory realization through a representation $R$ depends on whether consequential intent is encoded in it ($P(E\mid R)$), whether that encoding is interpreted correctly ($P(I\mid E,R)$), and whether the interpretation is realized correctly ($P(L\mid I,E,R)$). Governance carries a separate term, $q(T,R,A)$, the probability that an unacceptable candidate escapes the mechanisms governing an obligation. Cost enters through $c_R$, the cost of a realization attempt, and $C_{\text{carry}}$, the cost of keeping a representation and its enforcement machinery useful as the software changes. The engineer chooses the representation and the Alignment strategy together against those quantities.

Technological progress can move these terms independently. Reasoners can improve. So can the machinery for constructing and maintaining representations, the machinery for realizing them, and the machinery for detecting and refusing unacceptable results. These four are not a taxonomy of tools. They are the independent variables that prevent a single confident forecast. Table 7.1-1 sketches how each would redirect engineering effort. The correspondence is deliberately not one term per row: an improvement can change several terms at once, and representation machinery changes probabilities and costs alike.

Table 7.1-1. Possible movements of engineering effort. Improvements in different parts of the production system act on different terms of the Chapter 6 engineering problem. The trajectories can proceed independently and in combination, so the rows describe the pressures each would create rather than a forecast of a single future process.

Technological trajectory and terms affected	What becomes economical	Engineering effort moves toward
Reasoners improve: $P(I\mid E,R)\uparrow$, $P(L\mid I,E,R)\uparrow$	Reasoning successfully from less complete representations, and leaving more legitimate choices unresolved until realization	Choosing consequential distinctions, bounding degrees of freedom, and judging results rather than specifying every realization choice
Representation machinery improves: $P(E\mid R)\uparrow$, $P(I\mid E,R)\uparrow$, $C_{\text{carry}}\left(R\right)\downarrow$	Constructing, maintaining, reconciling, and querying explicit representations	Choosing abstractions, validating representations, and maintaining correspondence among them and with the system
Realization machinery improves: $P(L\mid I,E,R)\uparrow$, $c_R\downarrow$	Reliably transforming sufficiently complete representations into implementations, potentially deterministically	Specifying and validating what should be realized rather than supervising how it is implemented
Governance machinery improves: $q(T,R,A)\downarrow$, $C_{\text{carry}}\left(A\right)\downarrow$	Detecting, rejecting, or preventing unacceptable realizations independently of the producing reasoner	Choosing which obligations require enforcement, placing controls, and judging residual risk

Because these trajectories need not proceed together, commodity intelligence does not fix a single destination for software engineering. Better reasoners let engineering leave more legitimate freedom unresolved. The engineer states the consequential distinctions and lets realization choose among the acceptable possibilities. Chapter 6 bounds how far that can go. In the limit of a perfect reasoner, the probability of satisfactory realization approaches $P(E\mid R)$. Stronger reasoning cannot recover consequential intent that the representation never encoded. Capability therefore moves effort toward deciding which distinctions are consequential; it does not retire the obligation to encode them.

If explicit representations become cheap to construct, maintain, and reconcile, engineering can profitably externalize more consequential knowledge. That work is choosing, creating, maintaining, and connecting the representations through which humans and machines reason about the system. Requirements, architectural views, state machines, dependency graphs, policies, and measurement models answer different engineering questions. The skill is to choose a representation that makes the consequential property easier to reason about than reconstructing it from implementation, then maintain whatever correspondence that representation claims as the system changes.

This is different from context engineering. Retrieval can place more existing information before a reasoner; representation engineering can change the form in which the engineering question is expressed. An agent might retrieve enough source to reconstruct an architectural dependency, or work over a dependency model in which that relation is already explicit. The first improves access to the implementation; the second changes the representation over which reasoning proceeds.

None of this is a new representational or governance tradition. Requirements engineering, architecture, programming languages, formal methods, model-driven and model-based engineering, knowledge representation, safety and assurance engineering, and research on distributed cognition have long moved knowledge, reasoning, evidence, or control into explicit structures outside an individual engineer.^‖‖ External-representation moves in recent AI: LLM+P externalizes planning into a classical planner;¹²12. 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;¹³13. Charles Packer et al., “Memgpt: Towards Llms as Operating Systems,” 2023, https://doi.org/10.48550/arXiv.2310.08560. Graph of Thoughts externalizes intermediate reasoning as a graph;¹⁴14. 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. and WorldCoder externalizes a persistent world model as code.¹⁵15. Hao Tang et al., “Worldcoder, A Model-Based LLM Agent: Building World Models by Writing Code and Interacting with the Environment,” in “Advances in Neural Information Processing Systems 37,” special issue, Advances in Neural Information Processing Systems 37, 2024. A type can exclude an invalid local state;¹⁶16. Benjamin C. Pierce, Types and Programming Languages (MIT Press, 2002). an intermediate representation can expose the structure a transformation needs;¹⁷17. Andrew W. Appel, Modern Compiler Implementation in ML (Cambridge University Press, 1998). a systems model can connect requirements, behavior, architecture, and evidence.¹⁸18. Sanford Friedenthal et al., A Practical Guide to Sysml: The Systems Modeling Language, 3rd ed. (Morgan Kaufmann, 2014).¹⁹19. Marco Brambilla et al., Model-Driven Software Engineering in Practice, 2nd ed. (Morgan & Claypool, 2017). What changes with agentic software engineering is the economic importance of these representations: they can become active surfaces through which autonomous work is informed, scoped, checked, and reviewed.

Chapter 2 developed the modeling problem in detail: a representation is useful only for the questions its abstractions preserve, and it remains useful only while its claimed relationship to the system stays trustworthy. This trajectory changes the price of that work, not its nature. It does not establish that choosing and maintaining representations must become a larger part of software engineering. It makes that outcome economical.

If realization from a sufficiently complete representation becomes cheap and reliable, engineering effort moves further upstream. Little consequential freedom then remains downstream of the representation, and transformation or generation can replace autonomous realization wherever the representation determines the implementation. §7.2 examines the engineering tradition that already works this way.

If strong controls become cheap, engineering can tolerate more freedom in realization without granting that freedom equal authority over consequences. Cheap validators, monitors, and admission checks lower $q(T,R,A)$ without requiring the producing reasoner to be trusted. Effort then moves toward deciding which obligations deserve enforcement, placing the controls that enforce them, and judging the risk that remains. Under this trajectory an organization can become far more governed without becoming more model-driven.

Real engineering environments will combine these trajectories, often differently for different properties of the same system. A system might maintain an authoritative state model where invalid transitions are consequential, allow an agent wide implementation freedom locally, derive architectural views when a question needs them rather than maintain them, and enforce security and dependency obligations at admission.

The appropriate unit of analysis is therefore usually the engineering question or obligation, not the development methodology.

Model-driven engineering is one plausible destination, reached when improvements in representation and realization machinery reinforce one another. Cabot's proposal for vibe-driven model-based engineering keeps models as the pillar of development while letting AI assist their construction and, where a model determines the implementation, their realization through deterministic generators.²⁰20. Jordi Cabot, “Vibe-Driven Model-Based Engineering,” 2026, https://arxiv.org/abs/2604.10645. That is one combination of the trajectories in Table 7.1-1: AI lowers the cost of constructing and manipulating explicit models while model-based realization stays attractive. MAGE includes that future. It does not predict it. The opposite combination is equally available. If reasoners become good at reconstructing trustworthy task-specific representations from implementation, carrying separately maintained models may become less attractive for many questions.

Commodity intelligence changes the economics of representation and control without determining their eventual form.

More modeling need not mean more permanently maintained models. Agents can make it economical to construct a dependency graph, a state abstraction, a quantitative model, or another purposeful reduction for one consequential question and discard it afterward. Historically the construction cost demanded repeated reuse to justify itself, and cheap machine reasoning moves that threshold. A model can matter because reasoning passes through it, not because an organization preserves it forever.

Whatever technological trajectory dominates, operational experience becomes more valuable under the changed cost structure, because recurring engineering judgment creates an opportunity for durable improvement. A conventional review can solve an instance. Sometimes the same judgment keeps returning: a failure recurs, a relationship becomes apparent, or engineers repeatedly have to make the same decision. Chapter 4 calls the move from that experience to durable engineering structure governance conversion. The resulting model, control, or procedure becomes engineering capital when it allows later work to inherit what earlier work learned. Chapter 4 calls the practice by which such structures accumulate while remaining open to correction ratcheteering: the particular structure can be revised or replaced, but the consequential concern does not silently disappear. The engineering question is whether the judgment belongs in the next reviewer's head or whether future work should inherit it from the environment.

The answer is not always "mechanize." Guidance remains useful where interpretation is genuinely semantic; human review remains appropriate where consequence or ambiguity warrants it; and every new mechanism adds carrying cost. The goal is to mechanize where doing so pays, not to automate everything. Cheaper implementation settles the direction in which engineering work travels. Its destination is decided by engineering choices made one obligation at a time, under economics that have not finished moving.

7.1.5 Review When Implementation Is Abundant

Code review does not disappear when agents produce the code. Its center of gravity moves.

At low change volume, an experienced engineer can treat the diff itself as the principal reasoning surface. Read the implementation, reconstruct the surrounding architecture, infer the affected behavior, inspect the tests, decide whether the change belongs. That strategy stops scaling as implementation becomes abundant. The scarce resource is no longer the ability to produce another diff. It is the engineer's ability to determine what the change means.

This pressure predates agents. Long before agentic programming, empirical work at Microsoft found that larger changes were harder to review well: as more files were touched, the proportion of useful reviewer feedback declined, and large changes imposed greater reviewer effort.²¹21. Amiangshu Bosu et al., “Characteristics of Useful Code Reviews: An Empirical Study at Microsoft,” in “Proceedings of the 12th Working Conference on Mining Software Repositories (Msr),” special issue, Proceedings of the 12th Working Conference on Mining Software Repositories (MSR), 2015, 146–56, https://doi.org/10.1109/MSR.2015.21. Agentic generation makes that problem larger; it does not change its basic cognitive shape. The older result establishes that large changes tax human review and reduce useful feedback. It does not establish that explicit models would relieve the strain; models as the remedy are MAGE's proposal.

Greiler's more recent SCOPE proposal responds by changing the review operating model: detailed implementation review moves increasingly into the developer–agent loop, and team review becomes risk-proportional assurance over code together with higher-level artifacts and evidence.²²22. Michaela Greiler, “From Peer Review to Self-Review: The Epistemic Risk of Agentic Development,” July 2026, https://www.michaelagreiler.com/code-reviews-from-team-to-individual/. That proposal already includes agent review, developer attestation, risk-based team assurance, and accountability. SCOPE changes the operating model for review; MAGE additionally changes the surfaces available to the reviewer. When the environment holds explicit models of structure, behavior, ownership, execution, measurement, and provenance, those models become review surfaces in their own right. The engineer need not reconstruct every relevant property from the diff.

Explicit models provide intermediate review surfaces. A change can be projected onto component ownership, permitted dependencies, service edges, lifecycle states, deployment placement, user journeys, measurement obligations, and provenance. Deterministic mechanisms discharge the obligations that are mechanically decidable before scarce human attention is spent. The reviewer then spends attention on the remainder:

• Is the intended change desirable — the question a diff could never answer on its own.
• Do the models capture the relevant concern — or has the change moved a property no current representation exposes.
• Is the evidence sufficient — do the checks that ran actually bound the risk this change carries.
• Should the tradeoff be accepted — the residual judgment that stays with a person.

None of this removes code from review. It changes when the reviewer must descend to it. Implementation becomes one evidentiary surface among several, rather than the origin from which every system property must be reconstructed. The reviewer still reads the lines wherever implementation detail is where the risk lives. The models supply an index into the engineering significance of a change; they do not revoke the reviewer's authority to go look.

Review moves upstream, from inspecting realization toward evaluating intent, consequence, evidence, and the judgment that remains.

Appendix C collects representative forms of these models and shows how their authored and derived facts can be reconciled with the implementation; it develops the review surfaces as reusable model patterns rather than a prescribed catalog. Appendix I carries the within-case evidence on model coverage and correspondence. Those measurements speak to how much of the exercised system could be related to explicit models; they do not measure review time or review quality.

This shift in review surfaces has a broader implication: effective engineering capability may increasingly be a property of the environment as well as the foundation model. A weaker reasoner operating over accurate representations, well-routed context, strong tools, and independent evidence may outperform a stronger reasoner over an opaque repository. MAGE does not establish that substitution quantitatively; §6.4 makes its parameterization and eventual use in engineering routing an empirical research question.

7.1.6 Engineering the Production System

Chapter 5 distinguished two places engineering attention can go as realization becomes abundant. Engineers can spend increasing effort operating agentic machinery: supplying work and context, coordinating agents, inspecting output, and resolving exceptions. They can also engineer the production system around that machinery so that selected knowledge, evidence, and controls persist across acts of realization.

The distinction matters professionally because both futures can contain capable agents and very little human implementation. They differ in where scarce engineering judgment goes. MAGE predicts increasing value in the second kind of work: deciding which properties must remain under engineering control, choosing representations adequate to expose them, establishing the evidence required for acceptance, deciding which degrees of freedom can safely be delegated, and changing the engineering environment when experience shows those structures to be inadequate.

Making agents easier to operate is not the same as making software easier to engineer.

This is not a new lifecycle phase. Requirements, design, validation, operation, and maintenance remain. The change is that engineers increasingly exercise those responsibilities through the production system in which agents work. §7.2 and §7.4 ask what engineering traditions and capabilities prepare the profession for that role.

Works Cited

1. Meyer, André N., Earl T. Barr, Christian Bird, and Thomas Zimmermann. “Today Was a Good Day: The Daily Life of Software Developers.” IEEE Transactions on Software Engineering 47, no. 5 (2021): 863–80. https://doi.org/10.1109/TSE.2019.2904957.
2. Kumar, Sukrit, Drishti Goel, Thomas Zimmermann, Brian Houck, Balasubramanyan Ashok, and Chetan Bansal. “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.
3. Butler, Jenna, Brian Houck, Margaret-Anne Storey, Travis Lowdermilk, Steven Clarke, and Emerson Murphy-Hill. “Eight Myths on Software Engineering and GenAI.” Queue 24, no. 2 (2026). https://doi.org/10.1145/3807963.
4. Ralph, Paul. “The Sensemaking–Coevolution–Implementation Theory of Software Design.” Science of Computer Programming 101 (2015): 21–41. https://doi.org/10.1016/j.scico.2014.11.007.
5. Ralph, Paul. “Software Engineering Process Theory: A Multi-Method Comparison of Sensemaking–Coevolution–Implementation Theory and Function–Behavior–Structure Theory.” Information and Software Technology 70 (2016): 232–50. https://doi.org/10.1016/j.infsof.2015.06.010.
6. Reeves, Jack W. “What Is Software Design?.” C++ Journal, 1992. https://www.developerdotstar.com/mag/articles/reeves_design.html.
7. 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.
8. 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.
9. 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.
10. Ruan, Haifeng, Yuntong Zhang, and Abhik Roychoudhury. “Specrover: Code Intent Extraction via Llms.” In “Proceedings of the 47th IEEE/ACM International Conference on Software Engineering.” Special issue, Proceedings of the 47th IEEE/ACM International Conference on Software Engineering, 2025. https://doi.org/10.1109/ICSE55347.2025.00080.
11. 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.
12. 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.
13. Packer, Charles, Sarah Wooders, Kevin Lin, et al. “Memgpt: Towards Llms as Operating Systems.” 2023. https://doi.org/10.48550/arXiv.2310.08560.
14. 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.
15. Tang, Hao, Darren Key, and Kevin Ellis. “Worldcoder, A Model-Based LLM Agent: Building World Models by Writing Code and Interacting with the Environment.” In “Advances in Neural Information Processing Systems 37.” Special issue, Advances in Neural Information Processing Systems 37, 2024.
16. Pierce, Benjamin C. Types and Programming Languages. MIT Press, 2002.
17. Appel, Andrew W. Modern Compiler Implementation in ML. Cambridge University Press, 1998.
18. Friedenthal, Sanford, Alan Moore, and Rick Steiner. A Practical Guide to Sysml: The Systems Modeling Language. 3rd ed. Morgan Kaufmann, 2014.
19. Brambilla, Marco, Jordi Cabot, and Manuel Wimmer. Model-Driven Software Engineering in Practice. 2nd ed. Morgan & Claypool, 2017.
20. Cabot, Jordi. “Vibe-Driven Model-Based Engineering.” 2026. https://arxiv.org/abs/2604.10645.
21. Bosu, Amiangshu, Michaela Greiler, and Christian Bird. “Characteristics of Useful Code Reviews: An Empirical Study at Microsoft.” In “Proceedings of the 12th Working Conference on Mining Software Repositories (Msr).” Special issue, Proceedings of the 12th Working Conference on Mining Software Repositories (MSR), 2015, 146–56. https://doi.org/10.1109/MSR.2015.21.
22. Greiler, Michaela. “From Peer Review to Self-Review: The Epistemic Risk of Agentic Development.” July 2026. https://www.michaelagreiler.com/code-reviews-from-team-to-individual/.

© James C. Davis, 2026–present