Preface

Prefer to read offline? Download the PDF.

How do we safely grant autonomy to commodity intelligence?

This is a book about engineering—specifically, about what engineering work becomes when reasoning capacity becomes abundant.

Society has long entrusted consequential work to computers. Software flies aircraft, calculates tax returns, routes telephone calls, and controls power plants. Traditionally, software engineers stood between human intent and machine action: they translated goals, constraints, and judgments into sufficiently precise specifications, programs, and controls, and computers executed what they had made explicit.

Now, the boundary between human intent and machine action is shifting. General-purpose machine intelligence can interpret intent, make judgments, and produce implementation cheaply enough and at enough scale to become an ordinary engineering resource.^** Here and throughout, terms such as interpret, reason, and judge describe functional capabilities, not claims about cognition or consciousness. Contemporary language models approximate these capabilities through learned statistical computation; they are an imperfect realization of the general-purpose machine intelligence assumed here. Implementation has become cheap enough that agents can produce and modify software at extraordinary speed. The engineering problem therefore shifts: What should we build? What must the agent know about the system? How will we know whether its changes are correct? Which rules must it obey? In this book, I call this increasingly available capability commodity intelligence.¹1. John Nosta, “Intelligence as a Commodity,” Psychology Today, March 12, 2026, https://www.psychologytoday.com/us/blog/the-digital-self/202603/intelligence-as-a-commodity. ²2. Darwin Ling, “The $0.50 Barrel of Intelligence,” GoodAI, July 20, 2026, https://goodai.substack.com/p/the-050-barrel-of-intelligence. Software engineering has begun to confront the consequences.

MAGE asks where engineering work is being paid for repeatedly—in reconstruction, review, or human judgment—and what model or mechanism could make that work durable.

Why MAGE? Why Models?

This book—Model-Based Agentic Software Engineering (MAGE)—argues that modeling becomes central when implementation becomes abundant. Coding agents can produce implementation faster than engineers can reconstruct the system-level knowledge needed to judge it. Models make that knowledge explicit at useful levels of abstraction, letting humans and agents reason about larger engineering questions.

Modeling is not the whole answer. Important engineering obligations also need authority: constraints, sensors, validators, and gates that require autonomous work to satisfy those obligations. MAGE calls this Alignment. Modeling and Alignment solve different problems, but they reinforce one another: better models let the environment reason about and govern richer properties.

For most of software's history, realizing and revising a design consumed scarce skilled labor. That cost limited how many alternatives a team could try and how quickly it could learn. Coding agents change those economics. What remains comparatively scarce is engineering judgment: deciding what to build, representing a system well enough to reason about it, deciding whether a change is correct, and keeping a rapidly changing system coherent.

Engineering starts with goals, limited resources, and competing requirements. It asks what a proposed solution will do and what evidence supports that belief. Engineers do not assess the limit of a bridge by driving larger and larger trucks over it until something fails. They calculate what it should carry, how much variation is acceptable, and what margin remains, and understand the assumptions behind those judgments. Software built with agents deserves the same standard. A system may work, even impressively, with little explicit modeling. Success by observation is not engineering assurance.

Where the theory came from

This book began with one hard engineering problem that emerged over months of building a real production system. Only later did I test its vocabulary against independently described systems from Cloudflare, Docker, Shopify, Spotify, Siemens, and Zenseact. Part V presents both views of the evidence: DocAble in depth, then the industrial reconstructions in breadth. Part VI asks what account explains both. Figure 0.5-1 shows the evidentiary path.

The new bottleneck

Fleet. The set of coding agents working the codebase — the agentic-era workforce this book governs, in place of a team of human engineers.

Agents can produce changes much faster than the surrounding environment can understand or govern them. At scale, that mismatch becomes a bottleneck.

A fleet can generate, inspect, and modify implementation much faster than a human team. But more implementation capacity does not automatically produce more system-level understanding or better engineering judgment. When the necessary knowledge remains implicit, the fleet repeatedly reconstructs it. When an obligation is locally checkable, a test, sandbox, type, or gate may hold it without a separately represented model. But when the obligation depends on architecture, ownership, end-to-end behavior, or another model the environment lacks, somebody must supply the missing meaning. In many organizations that somebody is still a human reviewer. The result can work, but the human sits in the gap between what the environment can check and what the system actually needs guaranteed.

Churn is what happens when too much of that knowledge and judgment must be paid for again: agents rediscover context, undo recent changes, repair regressions, reconcile inconsistencies, or wait for humans to resolve questions the environment cannot settle. MAGE targets the recurring causes. Modeling makes more consequential properties explicit and tractable; Alignment makes selected obligations authoritative; governance conversion turns failures in either into structure the next task inherits.

The originating system

Lint. An automated check that scans code for a banned pattern and fails the commit when it finds one, so a rule holds without a human remembering it.

Gate. A check placed across a pipeline step — a commit, a deploy — that refuses to let the step through until its condition is met.

This book began with DocAble, a production service for remediating inaccessible documents. By the period studied here, coding agents had written roughly 491,090 lines of production code, while the environment governing it—tests, checks, agent infrastructure, and load-bearing documentation—had grown about three times larger, to 1,501,907 lines. Over several months I built it almost entirely by dispatching AI coding agents rather than writing the implementation myself. The originating question was simple: once agents write almost all of the code, what engineering remains?

DocAble is the running example throughout the book. Parts II and III examine the mature system from different engineering questions; Part V reconstructs how its machinery emerged and then compares it with independent industrial practice. The terms Modeling, Alignment, governance conversion, and engineering capital name patterns that kept recurring in that work and were then tested against the broader cases.

Evidence and scope

MAGE draws on two kinds of evidence. The first is a single longitudinal case: one production system, built by one engineer using one vendor's agent ecosystem over several months and used in production by me and my colleagues at Purdue. Numbers from that case are observations, not measured laws. The second is a set of reconstructions based on independent industrial accounts. Those accounts show less of how each system evolved, but more variation in technical and organizational choices, including systems that rely more heavily on explicit models and systems that rely more heavily on controls and human judgment. Part V presents both sources, states their limits, and ties empirical claims to supporting data or citations.

What the method turned out to be

Two principles organize MAGE:

1. Modeling makes consequential knowledge and intent explicit.
2. Alignment gives important engineering obligations authority.

They solve different problems but interact. Alignment always assumes something about what an acceptable result looks like: what must hold, and sometimes what variation remains acceptable. That understanding may remain tacit or be encoded locally rather than written down as a model. A sandbox can forbid an action using a local rule rather than a separate system model; a test can block a regression by encoding expected behavior; a human reviewer can judge an obligation that no machine-readable model yet captures. But they have a limit: they can govern only what the environment can state, observe, or ask a person to reconstruct. Modeling changes that boundary. By making architecture, policy, behavior, ownership, measurement, and other properties explicit, Modeling lets the fleet reason about larger engineering questions and lets its controls act on them.

MAGE therefore places Modeling first as a methodological choice rather than a logical prerequisite. Relevant knowledge and intent may already be tacit or encoded locally; Modeling makes explicit only what is worth externalizing; it need not eliminate realization choices that engineering has reason to leave open. The method asks the engineer to externalize the abstractions that matter before repeatedly spending human attention on what the environment cannot see. Once those properties are explicit, some judgments that once required reconstruction can be handled by repeatable machinery.

1. Model the consequential knowledge. Choose the engineering question first, then externalize the facts and intent needed to answer it without carrying unnecessary detail. The goal is not to model the whole system. It is to make larger properties easier to reason about without reconstructing them from implementation.
2. Give obligations authority. Encode important obligations into constraints, sensors, validators, and gates. Some can act directly on raw actions or artifacts; explicit models make richer, system-level obligations available to automated analysis and, where appropriate, enforcement.
3. Do the governed work. Let agents operate inside the resulting environment. Models provide reasoning surfaces; governance mechanisms provide evidence and boundaries. Human attention moves toward questions that genuinely require judgment instead of being spent reconstructing facts the environment can check itself.
4. Convert recurring failures. When autonomous work exposes missing knowledge, a weak abstraction, or an unenforced obligation, repair the instance and then encode the lesson into durable structure. The environment improves because the next task inherits the model or control rather than the memory of the person who solved the problem.

Neither principle is MAGE by itself. The method is the cycle they create: model where better representation changes the engineering problem; align what can be made authoritative; do the governed work; convert recurring failures and judgment into durable structure; repeat. Useful structure becomes engineering capital when later work keeps benefiting from it.

Who this book is for

This book is for software engineers who suspect the ground has moved and want to know where to stand. It is not primarily about the internals of agents; it is about the engineering structures that become important once agents can perform substantial implementation work autonomously. It is also for technical leads, architects, and engineering managers deciding how autonomous software development should work inside an organization. A fleet's models, policies, evidence, infrastructure, and remaining human decisions belong to the engineering organization, not just to an individual's tool.

The book is also intended for advanced undergraduate and graduate students studying software engineering, software architecture, or AI-assisted development. It assumes familiarity with ordinary software-development practice: source control, testing, APIs, build and deployment workflows, and the basic idea of software architecture. No prior experience with coding agents, formal methods, model-based engineering, or machine learning is required. Concepts from those areas are introduced where the argument needs them and illustrated through the systems and examples in the book.

The book focuses on software engineering rather than trying to teach every discipline MAGE draws from. In particular, this is not a textbook on model-based systems engineering (MBSE). MAGE adopts the MBSE habit of reasoning through explicit representations and applies it to choosing, structuring, and governing models for agentic software engineering. It does not attempt to teach the full range of modeling languages, viewpoints, transformation techniques, systems-engineering methods, or MBSE practice.

The book draws on several other traditions for the same reason. Model-driven software engineering supplies established ideas about metamodels, transformations, and generated artifacts; programming languages and compilers supply types, intermediate representations, and constrained transformation; formal methods supply executable specifications and machine-checked properties. MAGE uses those ideas where they help, without trying to teach the disciplines they come from. Those subjects have their own literatures and textbooks. The same applies to machine learning: the book introduces only the concepts the argument or examples need.

After reading this book, you should be able to recognize when an engineering problem is being paid for repeatedly in reconstruction or human judgment; decide whether a better model, stronger authority, or both could remove that recurring cost; and design mechanisms suited to your own system rather than copying another organization's process. One move recurs throughout: convert recurring judgment into durable engineering structure. DevOps learned to make infrastructure, configuration, and policy durable as code. MAGE extends that instinct to models, constraints, evidence, validators, workflows, and the engineering judgment encoded in them.