6.4 Software Engineering, Reorganized

Commodity intelligence does not invalidate software engineering. It changes its price 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 repeated human reconstruction increasingly expensive.

6.4.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. CITE0; Sukrit Kumar et al. CITE1. 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. CITE0. 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 CITE0, and its multi-method follow-through CITE1, 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 CITE2.

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 oversight, a fixed coding-time slice is no longer the right model of attainable leverage. MAGE is about crossing that boundary without losing engineering control.

The underlying moves are familiar: explicit specification, modular boundaries, constrained representations, formal analysis, model-based reasoning, and durable operational automation. Section 6.5 returns to that lineage.

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.

6.4.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 through which an agent acts 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 authority; what evidence work must produce; how representations remain aligned 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.

Figure 6.4-1 locates this shift against the immediately preceding agentic-SE tradition; the book's opening figure introduced it as a movement of engineering leverage, and here the same shift positions MAGE relative to the systems that precede it.

6.4.3 The Old Dream, with a New Substrate

The dream 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 very 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 authority, 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.

Three questions about the environment. AI research has long asked how to engineer around a reasoner: external memory, structured intermediate representations, planners, tools, and world models extend what a finite reasoner can accomplish. Recent agentic software engineering asks how to help that reasoner work on a repository: retrieval, program-aware search, purpose-built interfaces, tests, and specification inference make software tasks more tractable. MAGE asks how to engineer the environment in which autonomous software work occurs: the repository and agent remain inside the picture, but the first-class engineering objects expand to include purposeful system models, authoritative obligations, evidence, controls, and the machinery that keeps those structures useful over time. The progression is from engineering the reasoner's support, to engineering its access to software, to engineering the software-development environment itself.

6.4.4 Representation Engineering

One important professional competence is representation engineering: choosing, creating, maintaining, and connecting the artifacts through which humans and machines reason about a system.

Requirements, architecture, state machines, dependency graphs, invariants, scenarios, policies, measurement models, and context views are different representations built for different questions. The skill lies in choosing a representation that exposes the relevant property more cheaply than reconstructing it from the artifact, then maintaining the correspondence that representation claims as the system changes.

Representation engineering is therefore broader than context engineering. Retrieval asks which existing information to place before a reasoner; representation engineering asks whether the engineering question should be expressed in a different form in the first place. The distinction is between retrieving enough source to reconstruct an architectural relation and maintaining a dependency model in which that relation is already explicit. Both can be useful. Only the latter changes the object over which subsequent reasoning proceeds.

Representation engineering overlaps requirements engineering, architecture, programming languages, knowledge representation, formal methods, model-driven software engineering, and model-based systems engineering without replacing any of them. It also connects to a long AI tradition of engineering representations and external machinery around a reasoner, recently continued in foundation-model systems through memory, planning state, graphs, tools, and other explicit structure.^‖‖ External-representation moves in recent AI: LLM+P externalizes planning into a classical planner CITE0; MemGPT externalizes state into managed memory tiers CITE1; Graph of Thoughts externalizes intermediate reasoning as a graph CITE2; and WorldCoder externalizes a persistent world model as code CITE3. MAGE applies these representational moves to the engineered system and its development environment, not only to the reasoner itself. The agentic change is economic: these representations increasingly become active surfaces through which autonomous work is scoped, informed, checked, and reviewed.

The traditions emphasize different parts of the move. A type can make an invalid local state unrepresentable ¹⁶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 across views ¹⁸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).. MAGE is interested in the common engineering question beneath them: what representation makes the consequential property cheap enough to reason about, preserve, or govern?

The choice of representation also determines which assurance machinery becomes available. A closed type may exclude an invalid state directly. An explicit transition system permits search over reachable behaviors. A temporal specification permits claims over whole executions. Representation engineering is therefore partly the engineering of what can be checked: changing the representation can move a question from repeated semantic judgment into a mechanically evaluable domain.

Working at the model level

A useful model changes the grain of work. Instead of spending a reasoning window on implementation details irrelevant to the question, the agent or engineer can work over a representation that preserves the system state or intent that matters. A structural view can make dependencies legible; a behavioral view can expose legal transitions; an invariant registry can expose properties worth checking. The reasoner is no more intelligent than before. The question has been presented at a more useful abstraction.

Models do not remove essential complexity, and they introduce their own costs. They can omit the property that matters, encode the wrong abstraction, or drift from the relation they claim to describe. Earlier model-driven movements encountered those problems along with tooling, round-tripping, adoption, and generated-code quality. Commodity intelligence does not make those problems disappear. It can reduce authoring, derivation, and maintenance costs enough to reopen the question: how far should we model?

Keeping meaning synchronized

Agentic environments also make semantic inconsistency more expensive. The same architectural fact may appear in code, documentation, a prompt, a model, and a policy. Redundancy is not inherently bad; synchronized representations can make knowledge easier to recover and more resilient to the loss of any one source. The danger is unsynchronized duplication of meaning. Once the copies disagree, later reasoning no longer has a reliable source of truth. The engineering problem is therefore not eliminating every duplicate but making important correspondences explicit enough that disagreement becomes visible.

Reasoning compiled into the environment

Dynamic context injection (Section 4.5) provides a concrete example. The environment observes properties of the work and uses them to select the engineering knowledge that should enter the agent's context. The agent therefore need not reconstruct from the implementation which local models, constraints, or procedures matter before it can reason about the task.

This is a small instance of a larger shift: reasoning can be compiled into the engineering environment. The environment does not perform the agent's reasoning for it. It performs some of the recurring reasoning around it — determining what knowledge is relevant, making that knowledge available at the point of action, and preserving the relationship so that the next agent does not have to rediscover it. DCI does this for context selection; models, typed interfaces, lifecycle machinery, validators, and gates move other recurring judgments into durable structure with different degrees of authority.

6.4.5 Where Engineering Effort Moves

Implementation shifts; responsibility does not. The fleet can assume more realization work; engineers 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 6.4-2 draws the shift.

Operational experience also changes value under this price 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 proportionate authority, not maximal automation.

6.4.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 changes the magnitude of that problem, not 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 H 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.

The same 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.3 states it as an empirical question.