Conclusion

Though much is taken, much abides.

— Alfred, Lord Tennyson, Ulysses

The question we asked

In the Preface, we asked:

How do we safely grant autonomy to commodity intelligence?

The question was not how to generate more code. Commodity intelligence had already made implementation abundant enough to expose the harder problem: if an agent can produce and modify software at extraordinary speed, what must the surrounding engineered environment provide before we can safely grant that capability useful autonomy?

Seven Parts later, the book has an answer.

Give humans and agents representations suited to the engineering questions they have to answer. Enforce important obligations where the environment has enough information and evidence to decide them. When experience reveals knowledge or judgment that future work should not have to rediscover, make the lesson durable, and maintain it only while it continues to earn its keep.

Modeling extends what humans, agents, and tools can reason about and creates surfaces for analysis and assurance. Through Alignment, selected engineering intent is enforced: the environment determines what it will require, permit, observe, and admit. Governance conversion makes useful judgment durable beyond the task that produced it. When later work benefits from that structure, it becomes engineering capital.

That answer raises a converse question, and it is the one on which this book should end:

What cannot be delegated?

The answer in three moves

Strip MAGE to three engineering moves and this is what remains.

1. Work at the right representation. Choose the reduction that makes the engineering question answerable without carrying unnecessary detail. A purposeful model can expose properties that humans and agents would otherwise have to reconstruct from implementation, making them available for analysis, review, and evidence. Build the model when those benefits repay its cost, and maintain the correspondences on which its use depends.

1. Put enforcement where the obligation can be represented and decided adequately. Guidance aims the work; enforcement binds consequences. Some obligations can be enforced directly through types, permissions, tests, validators, or gates. Others become decidable only after a suitable representation exposes the relevant semantics. Leave consequential decisions to human judgment when the environment lacks the meaning or evidence needed to decide them adequately.

1. Make useful judgment durable. When a recurring or consequential engineering decision is worth carrying forward, encode it in a model, mechanism, architecture, procedure, or evidence that later work can inherit. When later work benefits from inheriting that structure, treat it as engineering capital: maintain it, reconcile it, and retire it when its return no longer justifies its carrying cost.

Together, these moves produce the governed engineering environment. Models carry what must be understood; mechanisms make repeatable decisions; evidence supports those decisions; human judgment remains responsible for the rest.

That is Model-Based Agentic Software Engineering.

In practice, start where engineering judgment is being purchased repeatedly. Find a system map that has to be reconstructed, a defect class that keeps returning, a review that asks the same question, or an obligation that lives only in someone's memory. Pick one recurring cost. Ask whether a better model, a stronger mechanism, or both would keep later work from paying it again. Make one durable improvement, observe what changes, and let the next bottleneck determine the next investment.

The part that stays yours

We began with a machine capable of building almost anything you describe—and only what you describe. It is unable to supply the engineering obligations you fail to make known to it. That capability is both the opportunity and the engineering problem.

A probabilistic reasoner does not become deterministic because an instruction asks it to. The engineered environment can still determine which models it reasons through, which actions it may take, what evidence its work must produce, which obligations bind its consequences, and which decisions remain with another authority.

The profession therefore cannot be defined by whatever tasks machines still perform poorly this year. Those tasks will move.

The enduring boundary is responsibility.

Work can be delegated. The mechanisms through which engineering control is exercised can be delegated too: agents can maintain models, run analyses, gather evidence, enforce obligations, and propose changes. But responsibility does not disappear with the work. Someone must remain answerable for the resulting system.

You decide what should exist and what "correct" means for it. You must retain sufficient control to understand and challenge the system, decide which properties matter, judge what evidence is sufficient, determine which obligations should bind the work, accept consequential tradeoffs, and change the environment when its assumptions fail. More and more of the work required to build and analyze the system may be delegated. Responsibility for the resulting system remains.

Commodity intelligence can assist with all of those activities. Its increasing competence changes how engineering control is exercised, not the need for an accountable authority to decide whether the resulting engineering case is acceptable.

The argument for MAGE therefore has two parts. Today, Modeling and Alignment can make autonomous engineering cheaper and more reliable by reducing repeated inference and enforcing selected obligations independently. Future agents may reason cheaply and well enough to reduce those concerns substantially. That will be an exciting development, not a failure of the method. But the second commitment remains: engineers—and the societies that rely on them—must retain sufficient control to understand, challenge, govern, and accept the systems that machines help produce, and identifiable people and institutions must remain responsible for the consequences.

The future of software engineering is larger than faster implementation. As realization becomes cheaper, engineering work reorganizes around what remains scarce.

Classical definitions of software engineering remain substantially right. The discipline was never defined by typing code; it was defined by systematic, disciplined approaches to developing, operating, and maintaining software. Commodity intelligence changes the relative cost of that work. As realization becomes cheaper, engineers gain more leverage by representing the system, shaping its architecture, producing evidence, validating claims, placing enforcement, and exercising judgment.

Other engineering disciplines have long separated responsibility for engineering judgment from physically realizing the artifact. Software remains unusual: it is extraordinarily mutable, and many of its constraints are authored rather than imposed by physics. But the professional shape increasingly rhymes.

The vocabulary increasingly rhymes as well: models and obligations, tolerances and degrees of freedom, evidence and assurance, authority and responsibility. The correspondence is not exact; the underlying engineering concerns are.

The engineering environment need not remain limited to what human engineers could feasibly inspect, remember, or check by hand. If machines now perform much of the realization, they can also help maintain richer representations, run analyses over them continuously, and enforce obligations at scales that would previously have been uneconomic. The opportunity is not merely to let agents use the software-engineering machinery we already built. It is to build better machinery because agents can use it.

Commodity intelligence did not abolish software engineering. By making implementation cheaper, it may force us to practice more of it.