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.

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 changes 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 should be understood as pieces of a larger engineered substrate rather than as 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 Representation Engineering

As implementation becomes cheaper, engineers can spend more of their effort on the representations through which humans and machines reason about the system. Representation engineering is the work of choosing, creating, maintaining, and connecting those representations. Requirements, architectural views, state machines, dependency graphs, policies, measurement models, and other representations 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.

Part II 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. The consequence for software engineering is simpler. As implementation becomes cheaper, choosing and maintaining the representations through which later work can reason becomes a larger part of software engineering itself.

7.1.5 Where Engineering Effort Moves

Implementation shifts; responsibility does not. The fleet can assume more realization work; engineers must retain sufficient control to remain responsible for intent, abstraction, evidence, tradeoffs, and acceptance. The lifecycle keeps its phases—requirements, design, implementation, validation, operation—but the allocation of work within them changes. Figure 7.1-1 draws the shift.

Operational experience also becomes more valuable under this cost structure. A conventional review can solve an instance. A durable representation or mechanism can change what every later instance has to rediscover or decide. That is governance conversion when the lesson comes from failure, and ordinary engineering capital formation when it does not. Either way, the engineering question is the same: ask 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.

7.1.6 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 ²⁰20. 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 ²¹21. 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; Section 6.4 makes its parameterization and eventual use in engineering routing an empirical research question.

7.1.7 The Software Factory Risk

There is another possible trajectory. An organization can increase agentic capacity without substantially changing the representations through which it understands its software. Agents can receive more repository context, use more tools, execute broader changes, run tests, respond to failures, and operate increasingly large portions of the development lifecycle. Each improvement can make the software factory more productive.

But production capacity and engineering understanding are different quantities. An agent may successfully modify a system because it can reconstruct enough relevant context from source code, documentation, history, dependencies, tests, and telemetry. Another agent may review the result, automated checks may pass, and operational evidence may remain healthy. None of those mechanisms necessarily leaves behind an explicit account of the consequential properties of the resulting system. As implementation grows faster and less familiar, an organization can therefore become better at changing its software without becoming correspondingly better at explaining what that software is supposed to do and why it should be trusted.

The issue is engineering control. Engineers need not personally inspect every artifact or make every implementation decision. But they must retain an independent basis for understanding the consequential properties of the system, deciding which obligations govern it, evaluating the evidence for those claims, and changing the engineering environment when those claims no longer hold. That control ultimately serves responsibility: authority belongs not to the software factory but to the people and institutions answerable for what it produces.

This becomes an assurance problem when the organization must answer questions that production alone cannot settle. What obligations apply? Where are they represented? Which parts of the system realize them? What evidence supports that correspondence? What assumptions remain? What changed since the previous assessment? If answering those questions requires another agent to reconstruct the engineering case from code, tickets, logs, policies, and history, then assurance itself depends on another inference over the artifacts produced by the factory. Better reasoners and better context can make that reconstruction more reliable. They do not make the underlying engineering knowledge explicit or give its obligations independent enforcement.

This distinction survives improvements in agent capability. Future agents may reconstruct the engineering case so cheaply and reliably that explicit representations are unnecessary for many acts of production. That would solve an important cost and reliability problem. It would not establish independent engineering control if the organization's understanding of the system still depends on asking the producing machinery to reconstruct its own engineering case.

MAGE goes further by engineering the environment itself. Agents can help maintain not only implementation and the context needed to change it, but the representations through which the implementation remains understandable: architectural relationships, behavioral models, invariants, decision structures, provenance, measurements, and their claimed correspondences to the realized system. Analyses can then operate directly over those representations, and selected obligations can be checked independently of the agent that produced the change. This does not eliminate uncertainty or require complete formalization. It changes which questions must be reconstructed from implementation each time.

The distinction matters because machine-scale implementation creates an opportunity for machine-scale assurance. The engineering environment need not remain limited to representations and checks that humans could feasibly maintain and apply by hand. A machine can maintain thousands of explicit relationships, continuously reconcile derived models against implementation, run analyses after every change, and surface the residual judgments that still require human attention. The objective is not a factory that humans understand by inspecting everything it produces. That goal becomes less plausible as production scales. The objective is a factory that preserves the engineering structures through which consequential properties remain inspectable, challengeable, and governable.

A software factory should therefore be evaluated not only by how much software it can produce, but by whether the organization retains sufficient engineering control to remain responsible for what it produces: whether it can continue to understand, assure, govern, and change those systems as necessary.