7.3 The Engineer

The preceding chapters moved from MAGE to software engineering and then to engineering more broadly. The final question returns to the person responsible for the system. If agents can increasingly implement changes, maintain models, run analyses, and propose engineering moves, what remains the engineer's work?

The answer is not whatever tasks machines happen to perform poorly today. The engineer must retain informed control over the resulting system and remain responsible for it: for what the system is supposed to mean, which distinctions matter, which properties should hold, which representations deserve trust, what evidence is sufficient, which obligations should be enforced, and which tradeoffs are acceptable.

7.3.1 Authority Follows Competence and Responsibility

MAGE increases both the leverage of engineering knowledge and the consequences of getting it wrong. An agent can increasingly carry much of the method itself: recognize a modeling opportunity, choose among known model families, construct a state machine, query a dependency graph, propose an invariant, or suggest that recurring inspection become machinery. Appendix E packages that repertoire in the Self-Governance mastery skill. As the repertoire becomes machine-readable, the engineer is distinguished less by recalling the available moves than by judging where they apply. An agent's command of the repertoire does not establish that a chosen abstraction captures what matters, that a proposed invariant expresses the intended property, or that the resulting tradeoff is acceptable. Those judgments remain engineering work.

Professional authority

Engineering authority is not merely technical. Societies entrust engineers with consequential decisions because engineers are expected to understand the systems they certify and to stand behind them. The institutional details differ across domains, but the principle holds: the authority to make consequential engineering decisions requires both sufficient control over the system and responsibility for the decisions made. Engineers can carry legal, professional, and sometimes personal liability for the decisions they sign. An AI system can generate an artifact or assemble evidence. It cannot assume the professional responsibility attached to an engineer's judgment.

Other engineering professions make answerability institutionally explicit through professional licensure. In U.S. professional-engineering practice, the concept of responsible charge attaches authority to the engineer exercising direct control and supervision over consequential engineering work; licensed engineers are also subject to enforceable ethical and legal duties directed toward public health, safety, and welfare.^** On responsible charge — direct control and supervision by the engineer exercising professional judgment — see NSPE Position Statement No. 10-1778 (rev. May 2024) ¹1. National Society of Professional Engineers, “Responsible Charge,” 2024.; on the statutory duties and practice exemptions that bound where licensed authority is required, NSPE Position Statement No. 09-0173 (rev. November 2023) ²2. National Society of Professional Engineers, “Licensure Exemptions,” 2023..

Requiring engineers to be able to understand and challenge agentic decisions is therefore not merely an organizational preference. It is part of the basis on which consequential engineering authority can legitimately be exercised.

The converse matters too. If engineers cannot retain sufficient control over a system making consequential decisions to exercise that authority responsibly, withholding the authority is itself a legitimate—and sometimes necessary—engineering outcome.

The judgment frontier

One social purpose of the engineer is to be entrusted with, and answerable for, technical work too complex or consequential for ordinary individuals to undertake for themselves.³3. George Bugliarello, “The Social Function of Engineering: A Current Assessment,” in Engineering as a Social Enterprise, Engineering as a Social Enterprise (National Academy Press, 1991). A small bridge across the ditch in my parents' yard allowed the neighborhood kids to visit more easily, but a few boards crossing a span of three feet did not call for a structural engineer. The Golden Gate Bridge did. Large engineering organizations extend the same principle internally: a chief engineer may be answerable for a system assembled through layers of engineers and specialists, below which lie tasks simple enough that engineering expertise is no longer needed either to perform the work or to establish that it was done correctly. GenAI can push that boundary downward. If machine intelligence can reliably perform more of the work, fewer human engineers may be needed to build the same system. Nothing about engineering requires preserving jobs that no longer require engineering judgment.

But there is another boundary: the judgment frontier. Part VI showed that some obligations cannot yet be reduced to mechanical checks. A capable reasoner must still decide whether the evidence is enough, whether a tradeoff is acceptable, or whether something is simply right for its purpose. Better GenAI will move this frontier too. We may entrust machine intelligence with judgments that in 2026 we reserve for experienced engineers, including increasingly contextual and qualitative ones. Yet technical capability and social authority are different things. Society may accept an engineering organization with far fewer human engineers before it accepts one with none: no human professional entrusted with the work, no human being who can be called to account for its judgments, and only machine intelligence standing behind the result.^†† Contemporary calls for greater social control over advanced AI have argued that decisions about powerful systems should not be left solely to the organizations developing them, but should reflect broader social judgment.⁴4. Future of Life Institute, “Pause Giant AI Experiments: An Open Letter,” 2023. Frank Herbert imagined an extreme version of such a choice in Dune: after the Butlerian Jihad, its fictional society prohibits "thinking machines" and deliberately preserves human capacities to perform work that machines might otherwise perform.⁵5. Frank Herbert, Dune (Chilton Book Company, 1965). Herbert's answer is extreme, but the underlying question is real: societies must decide not only what machine intelligence can do, but what roles they are willing to surrender to it and what human capacity they wish to preserve. The frontier is therefore not only what machines can judge. It is what society is willing to let them judge on our behalf.

Resilience gives another reason to preserve the human side of that frontier. A society whose engineering capacity exists only through machine intelligence has made that intelligence critical infrastructure. If the models become unavailable, untrustworthy, compromised, or controlled by someone else, the society has no independent engineering capacity to fall back on. Some human engineering competence may therefore remain valuable even when it is no longer the cheapest way to produce engineering work.

Other industries have learned the same lesson about efficiency and reserve capacity. Systems optimized around lean inventories and just-in-time supply can be highly efficient in ordinary conditions while leaving too little cushion when a common disruption arrives. The COVID-19 pandemic made that tradeoff unusually visible.⁶6. National Academies of Sciences, Engineering, and Medicine, Building Resilience into the Nation's Medical Product Supply Chains, technical report (Washington, DC, 2022), https://doi.org/10.17226/26420. In consequential industries, resilience can go beyond prudent management and become an explicit engineering obligation. U.S. pharmaceutical manufacturing rules require an "adequate number of qualified personnel" to perform and supervise drug production, with personnel qualified for their assigned functions.⁷7. U.S. Food and Drug Administration, “Personnel Qualifications,” 21 C.F.R. § 211.25. Federal law separately requires manufacturers of certain drugs and related products to maintain redundancy risk-management plans addressing threats to supply,⁸8. Federal Food, Drug, and Cosmetic Act § 506C(j), 21 U.S.C. § 356c(j). and FDA guidance recommends that medical-device manufacturers plan for continuity by ensuring additional production capacity and identifying alternative sources.⁹9. U.S. Food and Drug Administration, “Emergency Preparedness and Medical Devices: Supply Chain Recommendations for Health Care Providers and Medical Device Manufacturers,” accessed September 11, 2026.

The analogy to machine intelligence should not be pushed too far: these rules do not require pharmaceutical manufacturers to keep redundant workers idle in case ordinary production fails. But they embody a useful engineering principle. A critical productive capability should not be evaluated only by how efficiently it operates under ordinary conditions; its dependencies, qualified capacity, and ability to continue under disruption matter too. The judgment frontier is therefore partly about trust and accountability, but also about preserving the ability to act without the machine.

Resilience need not mean preserving only human reserve capacity. It may also favor diversity in where machine intelligence resides. If consequential engineering increasingly depends on models available only through a small number of remote providers, access to those providers becomes part of the engineering infrastructure on which individuals, firms, and societies depend. Smaller local or on-device models could provide another layer of reserve capacity: perhaps less capable than frontier systems, but inexpensive, independently operable, and sufficient when paired with strong representations, tools, and evidence. Whether that capability becomes technically or economically competitive is uncertain. The engineering principle is not. A resilient system should be wary of concentrating an essential productive capability behind a dependency it cannot itself control.

MAGE predicts that implementation will become increasingly fungible and that fewer people will be needed to carry it. It does not follow that a resilient society should allow independent human engineering capacity to disappear with it.

ENGINEERING PRACTICE

Inset — Engineering at the frontier of authority

Engineering does not always decide whether to proceed. Its responsibility is to make the engineering case legible enough that those who do decide know what is understood, what can be assured, what remains uncertain, and what risk they are accepting.

Engineering history contains painful demonstrations of this distinction. Before Challenger, Morton Thiokol engineers recommended against launching at the temperatures expected on January 28, 1986. Management reversed that recommendation, but the engineering objection survived in the record, allowing the Rogers Commission to reconstruct both the technical disagreement and the decision process that followed it.¹⁰10. Presidential Commission on the Space Shuttle Challenger Accident, Report of the Presidential Commission on the Space Shuttle Challenger Accident, Volume 1, technical report (Washington, DC, 1986). Columbia illustrates a different failure: engineers raised concerns about the foam strike and sought additional imagery, but important assumptions and uncertainties did not reach the Mission Management Team with sufficient force or clarity. The Columbia Accident Investigation Board subsequently called for an independent technical authority and safety-assurance organization with authority over safety decisions.¹¹11. Columbia Accident Investigation Board, Columbia Accident Investigation Board Report, Volume 1, technical report (Washington, DC, 2003).

Volkswagen's diesel-emissions scandal brings the problem into software. Engineers implemented software that recognized emissions tests and changed vehicle behavior; the subsequent legal record made it possible to reconstruct what engineers and managers knew, what they concealed, and who participated in the decisions. Volkswagen engineer James Liang ultimately pleaded guilty to conspiracy and was sentenced to 40 months in federal prison.¹²12. U.S. Department of Justice, Office of Public Affairs, “Volkswagen Engineer Pleads Guilty (2016) and Is Sentenced to 40 Months in Prison (2017) for His Role in the Conspiracy to Cheat U.S. Emissions Tests,” 2017. The disclosures of Frances Haugen and, later, former Facebook engineering director Arturo Béjar bring the pattern entirely into software systems. Facebook's own researchers studied harms experienced by young users, while Béjar later testified about internal measurements of such harms and his efforts to communicate them to senior executives.¹³13. U.S. Senate Committee on Commerce, Science, and Transportation, “Protecting Kids Online: Facebook, Instagram, And Mental Health Harm,” 2021.¹⁴14. U.S. Senate Committee on the Judiciary, “Social Media and the Teen Mental Health Crisis,” 2023. Whatever judgment one makes about the appropriate product or policy response, these records made a more basic question answerable: what did the organization know about the behavior of its system, who knew it, and what did those with authority do with that knowledge?

These cases suggest a simple professional test. When consequential harm occurs, the engineering record should show what engineers knew, what they did not know, what they warned about, and who chose to proceed. This is not merely defensive documentation. Making knowledge, uncertainty, disagreement, and evidence explicit is part of how engineering informs consequential decisions and makes those decisions answerable.

The distinction matters increasingly as software agents become capable of consequential action. Retaining engineering control does not require engineers to make every decision an agent makes. It requires them to establish the relevant bounds: what authority has been delegated, what properties are assured within it, what evidence supports those claims, what departures can be detected, and where the limits of that assurance lie. The engineering challenge is to extend the frontier over which meaningful authority can be exercised as the capabilities and autonomy of the system expand.

Sometimes the available evidence will not establish the desired bound. Engineers are not always the final decision-makers. Executives, military commanders, regulators, political leaders, and societies may have legitimate reasons to proceed despite engineering uncertainty: the consequences of inaction may themselves be severe, and competitive or geopolitical pressures may make accepting substantial risk rational. Engineering's responsibility is to preserve the distinction. A decision to accept an inadequately bounded risk does not make the risk bounded. The record should make clear what engineering could establish, what it could not, and who possessed the authority to proceed anyway.

That answerability matters after the decision as well. Society needs identifiable people and institutions from whom an account can be demanded and to whom consequences can attach. Professional licenses can be revoked, certifications withdrawn, organizations sanctioned, and individuals held legally responsible. A machine cannot become the terminus of that chain of responsibility. Delegating a decision to a machine does not delegate the responsibility that justified the human or institutional authority to make it.

MAGE therefore aims not to hold autonomy behind an arbitrary boundary because autonomy is dangerous. It is to push outward the boundary within which autonomy can be responsibly granted. Better models can expand what machines can do. Better engineering environments must expand what humans and institutions can understand, constrain, assure, and govern. Modeling makes consequential knowledge explicit; Alignment enforces selected obligations; evidence makes the resulting claims challengeable. Together, these mechanisms enlarge the domain over which engineers can responsibly delegate action while retaining the ability to understand what has been delegated and to answer for the consequences.

Engineering has always required moving between levels of abstraction: choosing the level that exposes the property at issue and descending when the current abstraction no longer answers the question. Working with agents extends that practice. The shallow reading is natural-language programming: say what you want and receive code. The engineering task is broader. As agents acquire more of the technical repertoire, the engineer's leverage moves upstream—from supervising individual actions toward authoring and judging the environment in which those actions occur.

That upstream work can outlast the individual judgment. A well-chosen abstraction, a binding constraint, or a reliable validator can continue carrying part of an engineer's reasoning into work performed by other people and agents. This is one reason the environment can accumulate engineering capital. It is also why authoring the environment carries unusual leverage: a consequential judgment made well once may shape thousands of later changes.

But inheritance is not abdication. Someone must still recognize when the environment no longer fits the system, when an old distinction has stopped mattering, or when a new obligation lies outside what the existing machinery can see. The expert contribution moves toward creating, evaluating, and revising durable structure; it does not disappear once that structure exists.

Table 7.3-1 names this authorship division.

Organizations may distribute these responsibilities across engineers, platform teams, review boards, or other accountable roles. The allocation should be explicit and governed.

Natural language may be one interface to the work. It is not the engineering method.

7.3.2 Sign-Off Moves Toward Models and Evidence

Imagine an agentic system in which the fleet constructs most of the implementation, maintains selected engineering representations, runs validators, and assembles evidence for the claims the design is supposed to satisfy. Human review then looks less like authorship of the implementation and more like technical acceptance: inspect the representations, challenge their assumptions, examine the evidence attached to important claims, request deeper analysis where the case is weak, and decide whether the result is fit to accept.

This is a professional prediction rather than a finding of this book. At scale, implementation-level inspection cannot remain the primary human assurance mechanism. That was true before coding agents; no engineer establishes confidence in Linux by holding its source code in working memory. Agentic implementation makes the mismatch more immediate by producing large, unfamiliar changes faster than a person can conventionally inspect them.

Models provide intermediate review surfaces. A structural representation can expose decomposition and permitted dependencies; a behavioral representation can expose legal states and transitions; a decision model can expose authority; a measurement model can connect an engineering claim to the observations meant to support it. Tests, static analyses, benchmarks, simulations, and operational measurements then provide evidence about those claims. Neither representation nor evidence is sufficient alone.

Models state selected claims about the system and the properties that matter. Evidence says why we should believe those claims. Governance says what evidence is required and what decisions that evidence can authorize. The engineer remains answerable for whether those are the right claims, representations, tradeoffs, and standards of evidence.

The object of review moves; accountability does not. An engineer has never needed to hand-implement every consequential choice to remain answerable for the resulting system. Agentic systems extend this arrangement across more of the system. The engineer delegates the keystrokes and stays answerable down to the code and past it — to the properties a model names and the evidence a validator produces.

Early evidence shows part of this shift. A six-month longitudinal study of engineers adopting AI assistants found most of them writing less code and spending more time directing, checking, and correcting what the model produced — a mode its authors name supervisory engineering work. It did not come free: flow and cognitive load both eroded even as output held ¹⁵15. Annie Vella and Kelly Blincoe, “The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study,” 2026, https://arxiv.org/abs/2605.23135.. Their observations are consistent with this shift; MAGE's proposal is to give that supervision better reasoning surfaces — explicit models and evidence rather than an ever-growing stream of unfamiliar output.

Real answerability requires competence and authority. The reviewer has to distinguish local defects from structural problems, and a structural diagnosis needs a path to the architecture, models, mechanisms, or infrastructure that can address it. Otherwise responsibility becomes nominal: the engineer can see the problem but cannot change the environment that produces it.

The models themselves remain objects of engineering. Their fidelity is not assumed; the environment must maintain whatever correspondence each model claims to the realized system. Traceability, re-derivation, comparison, and drift detection are ways to produce that evidence. MAGE does not replace testing and inspection with models; it relates that evidence to explicit engineering claims.

7.3.3 From Full-Stack to Full-System Engineering

Software has used full-stack engineer to describe someone able to work across multiple implementation layers: interface, application logic, data, infrastructure, and deployment. Commodity intelligence may make that breadth easier to obtain. An engineer assisted by capable agents can increasingly construct and modify artifacts across layers without personally possessing the implementation fluency that each layer once demanded.

But MAGE suggests a broader requirement. Retaining engineering control can require reasoning not merely across the implementation stack, but across the full system and its lifecycle. A representation chosen during design determines what later implementation can express; an architectural boundary determines what can be validated independently; operational evidence can reveal that an earlier abstraction was wrong; a recurring failure may justify changing the model, mechanism, or environment inherited by every subsequent change. These are not separate concerns merely because organizations have historically assigned them to separate roles.

Building DocAble made this breadth concrete for me. I needed to understand regulatory obligations such as the ADA and WCAG; product questions such as usability, user expectations, and the capabilities and limitations of existing accessibility tools; document formats and their underlying representations, including PDF, Office, LibreOffice, LaTeX, and Typst; accessibility semantics such as reading order, alternative text, tables, contrast, and document structure; software architecture and the models through which those formats could be transformed safely; agent behavior and the boundaries within which autonomous remediation could operate; validation and assurance sufficient to distinguish plausible output from conforming output; cloud-computing and worker models; memory, streaming, and performance behavior; deployment and operations; and the recurring failures that revealed when some part of the architecture needed to change. No single concern defined the system. Decisions among them interacted.

I have found that this process develops the engineer as well as the system. One fear about increasingly capable machines is that engineers will lose expertise as machines perform more of the work. That can happen if delegation removes the engineer from the feedback through which expertise develops. My experience with MAGE has been nearly the opposite. Cheap implementation enables a kind of hyper-exploration: I can form a hypothesis, model it, realize it, measure what happens, discover where my understanding was wrong, and repeat the cycle many times in the time a conventional implementation might once have taken. MAGE gives that exploration structure. The resulting models, evidence, constraints, and mechanisms become durable engineering capital in the Governed Engineering Environment, but the learning does not accrue only to the environment. The engineer goes through the loop too. Repeatedly choosing representations, confronting predictions with evidence, finding the proper level of a failure, and deciding what knowledge should become durable machinery forces the engineer to learn. Abundant implementation can deskill an engineer who merely consumes its output; used this way, it can instead become an unusually powerful medium for developing engineering judgment.

This is systems thinking applied to software engineering under agentic leverage. Local implementation can increasingly be delegated, but consequential judgment often requires following a property across requirements, models, architecture, implementation, validation, deployment, operation, and maintenance. The engineer need not personally perform every activity or master every technology. The requirement is sufficient command: enough understanding of each relevant domain to recognize how decisions made in one part of the system constrain, enable, or invalidate reasoning elsewhere, and to intervene when those relationships threaten consequential properties.

The professional trajectory may therefore be from full-stack toward full-system engineering. Full-stack breadth crosses implementation layers. Full-system breadth crosses domains, abstractions, and lifecycle boundaries. As agents make implementation expertise cheaper to apply, the latter may become the scarcer and more consequential form of engineering competence.

7.3.4 What Should We Teach?

If engineers increasingly review systems through representations and evidence rather than reconstructing every property from implementation, education should shift accordingly. This book is not an education study, so the argument is a professional hypothesis rather than a curricular finding.

Is there software engineering knowledge you cannot just figure out for yourself?

The question for software engineering education is whether there is important software engineering knowledge that practitioners cannot reasonably be expected to figure out for themselves, or whether software engineering is distinct among the engineering disciplines in being predicated on adaptability more than specific expertise. Perhaps software changes so quickly that what matters most is the ability to learn whatever comes next. In that case, we should stop pretending that software engineering has a durable body of technical knowledge. We should abandon software engineering as a discipline and retreat toward a liberal-arts education in critical reasoning, analysis, synthesis, and communication, supplemented by enough practical experience to learn the technologies of the moment.

That conclusion would make software engineering unusual among mature engineering disciplines. No one would seriously propose that mechanical engineers are simply clever people who can acquire the necessary engineering knowledge through curiosity and experience on the job. Something closer to that proposition may have been plausible 200 years ago, when much of mechanical engineering could be learned through machinery, craft, and apprenticeship. It is not plausible when an engineer must reason about fluid mechanics, heat transfer, materials, dynamics, and control. Engineering accumulated bodies of knowledge that practitioners cannot reasonably be expected to rediscover for themselves. Formal education is one way we transmit that accumulated expertise.

The skeptical case is stronger in software. Consider some of the principles routinely presented as software-engineering wisdom: Don't Repeat Yourself. Separate concerns. Hide implementation details. Prefer small interfaces. SOLID. Refactor duplicated or poorly structured code. Test your work. Talk to users before building the wrong thing. These are useful ideas, but it would be absurd to claim that someone needs a four-year university education to understand them. Much of the familiar literature of software practice is deliberately accessible to working programmers, and much of its advice can be learned through experience—sometimes painfully, but effectively. A capable programmer can encounter a tangled dependency, suffer its consequences, learn why modularity matters, and carry that lesson to the next system without ever taking a university course called Software Engineering.

The profession itself makes the challenge harder to dismiss. Many successful software professionals entered the field without formal education in software engineering or computer science, and even developers with university degrees commonly report learning programming through other routes. The 2024 Stack Overflow Developer Survey reflects this mixture: 66 percent of respondents reported holding a bachelor's or master's degree, while 49 percent reported learning to code at school and 82 percent reported using online resources to learn.¹⁶16. Stack Overflow, “2024 Stack Overflow Developer Survey,” 2024, https://survey.stackoverflow.co/2024/. If people can become successful software professionals this way, perhaps adaptability and experience really are the expertise. Perhaps there is no software-engineering equivalent of fluid mechanics.

What shouldn't software engineers have to figure out for themselves?

I would concede some of this ground. Parts of software engineering really can be learned through practice. MAGE's Alignment Principle is a useful example. If a property matters, do not rely only on someone—or something—remembering to respect it. Check it, constrain it, or otherwise make violations harder to admit. Experienced software practitioners have been turning recurring mistakes into tests, linters, schemas, permissions, review rules, and automation for decades. MAGE systematizes that move and extends it to probabilistic implementors, but its basic intuition does not require a university education to discover.

But that concession does not extend to the foundations of computing. Beneath changing software technologies lies accumulated knowledge about how information can be represented, manipulated, transformed, constrained, and reasoned about—and about what guarantees can and cannot be established over those processes. Data structures expose the consequences of choosing one representation over another. Algorithms establish how information can be transformed and at what cost. Programming languages and type systems make selected distinctions explicit and constrain permissible operations. Operating systems expose problems of concurrency, isolation, resource management, and failure. Databases and distributed systems make persistence, consistency, coordination, and partial failure unavoidable. Security asks what can be trusted when other actors may actively work against the system. Specifications, architectural models, and formal methods provide still other representations through which engineers can state and reason about consequential properties.

The important expertise is not merely knowing these subjects or techniques exist. It is understanding the abstractions they provide, the questions those abstractions make tractable, the conclusions that follow, and where those conclusions stop. An asymptotic bound says something precise about computational growth without saying whether a system will meet its latency target. A type system can exclude a class of invalid programs without establishing that a program does what its users need. A test can provide evidence about executions without proving the absence of untested behavior. A formal specification can support strong guarantees about the properties it states while saying nothing about an important property that was omitted. An architectural view can make a dependency visible while abstracting away behavior that matters for another engineering question. These limits are not defects. They are consequences of abstraction, and understanding them is part of engineering expertise.

MAGE rests on these foundations rather than replacing them. Its Modeling Principle particularly depends on the representational part of this knowledge: what information a representation preserves, what it leaves out, how it corresponds to the realized system, and what claims it can legitimately support. Commodity intelligence changes who performs more of the implementation; it does not repeal the bodies of knowledge needed to understand what that implementation means, how it behaves, or what can be established about it.

This is technical knowledge that practitioners cannot reasonably be expected to rediscover for themselves. Commodity intelligence may make particular languages, frameworks, APIs, and implementation techniques cheaper to learn and quicker to replace. It does not eliminate the need to understand algorithms, abstraction, state, concurrency, distribution, security, representation, evidence, or the guarantees and limits that follow from them. If anything, delegating more realization makes these foundations more consequential: engineers increasingly make decisions about systems whose detailed implementation they did not personally construct.

The curriculum therefore remains substantially recognizable. Programming does not disappear, nor does software engineering, and neither do the computing foundations on which they depend. Engineers still need enough implementation fluency to understand the systems they build, diagnose failures, evaluate generated work, and descend through abstractions when necessary. They still need the disciplinary foundations that make those judgments possible.

What changes is the allocation of attention. If routine implementation becomes cheaper while specification, validation, coordination, and judgment remain scarce, education should reflect that shift. The question is therefore less what subjects disappear than which competencies deserve more or less practice.

Shift the emphasis

Less educational effort may need to go toward producing routine implementation by hand, and more toward selecting abstractions, specifying properties, measuring systems, validating claims, reasoning about quality attributes, and governing autonomous work. Modeling, specification, architecture, measurement, programming languages, and formal methods deserve more room—not because every engineer should become a language theorist, systems modeler, or verification specialist, but because these fields teach durable ways to choose abstractions, state properties precisely, make invalid states harder to express, and separate a claim from the evidence that establishes it. Students should also learn to distinguish improving a reasoner's context from improving the representation of the engineering problem itself.

Coordination deserves greater emphasis as well. An engineer directing several autonomous workstreams must decompose a larger objective, identify dependencies and integration points, sequence work where necessary, monitor progress and risk, and reconcile independently produced results. These are familiar project-management competencies, but agentic capacity changes the scale at which they become technical concerns: an individual engineer may command enough parallel implementation capacity to face coordination problems that previously arose mainly at team scale. This does not make every software engineer a project manager. It makes decomposition, dependency management, sequencing, and integration part of the technical problem of converting abundant implementation capacity into coherent engineering progress.

Change what students demonstrate

A capstone should therefore demonstrate more than a working artifact. Ask students to bring the engineering case.^‡‡ Existing accreditation already asks for a culminating design experience that integrates standards and multiple constraints and builds on earlier coursework, with software-specific criteria adding requirements analysis, security, verification and validation, and processes for complex software systems ¹⁷17. ABET Engineering Accreditation Commission, “Criteria for Accrediting Engineering Programs, 2025–2026,” 2025, https://www.abet.org/accreditation/accreditation-criteria/criteria-for-accrediting-engineering-programs-2025-2026/.. Computing-accredited programs likewise require a major integrative project ¹⁸18. ABET Computing Accreditation Commission, “Criteria for Accrediting Computing Programs, 2025–2026,” 2025, https://www.abet.org/accreditation/accreditation-criteria/criteria-for-accrediting-computing-programs-2025-2026/.. The open question is not whether students should integrate their knowledge but what should count as evidence that they have — which is why the capstone should carry the engineering case, not only the demo. The artifact should be one component of that case, alongside requirements, models, tradeoffs, measurements, validation evidence, and an explicit argument for acceptance. Students should also demonstrate that they can organize substantial work: decompose an objective, manage dependencies and integration, coordinate parallel realization, and adapt the plan as engineering evidence arrives. This extends rather than replaces the integrative purpose of the capstone: the question is not merely whether students can produce a system, but whether they can organize and justify the engineering work that makes the resulting system worthy of acceptance.

Program objectives may need to change less than daily engineering work does. In my view, most engineering programs need little change in what they claim an engineer should become. The larger change is in how students practice and demonstrate those capabilities.

The durable curriculum should not be organized around the current agent interface. Prompt conventions, harness architectures, model APIs, and context-management techniques matter in practice and students should use them, but they change too quickly to define the intellectual core. Teach the principles beneath them—finite reasoning and abstraction, representation and fidelity, action boundaries and authority, independent evidence, security, measurement, and the design of environments in which uncertain components can be used safely—and let students encounter current agents throughout the curriculum.

7.3.5 The Entry-Rung Problem

The traditional path into software engineering runs through implementation. Junior engineers become useful by writing code, and through that work they encounter larger systems, learn why designs fail, and gradually acquire the judgment needed to take responsibility for more of the system. GenAI changes this apprenticeship model. If routine implementation requires fewer people, the profession loses some of the work through which it has historically trained its future senior engineers.

This creates an entry-rung problem. Requirements discovery, modeling, security, systems reasoning, validation, and engineering judgment are harder to teach through a short framework-oriented path—and they are also the capabilities that become more valuable when implementation is abundant. Practitioners concentrated in implementation therefore need paths into architecture, assurance, modeling, and system responsibility. New entrants need ways to acquire those foundations even if the market demands less handwritten construction. The educational problem is not simply how to teach students to use GenAI, but how they acquire the engineering judgment that routine implementation previously helped them develop through experience.

MAGE shifts expertise toward choosing abstractions, defining properties, evaluating evidence, allocating authority, and remaining answerable for the system. Commodity intelligence will not define the future profession by leaving behind a stable residue of tasks for humans; those tasks will continue to move as capabilities improve. The more durable change is in how engineering work is organized. The profession is not shrinking toward whatever implementation tasks machines still perform poorly, but reorganizing around responsibility for the engineered whole.