Preface

Prefer to read offline? Download the PDF.

This is a book about engineering — specifically, about what engineering work becomes when writing the code stops being the hard part. For most of the history of software, the scarce resource was implementation: someone had to sit down and type the thing into existence, and that typing was the bottleneck everything else queued behind. Coding agents have moved that bottleneck. Code is now cheap to produce and fast to change. What is not cheap is judging, constraining, validating, and maintaining it — deciding what to build, catching where fast code went wrong, and keeping a growing system trustworthy while it changes under you every day. That shift is the subject of this book.

My name is James Davis. I am a professor of software engineering in the Elmore Family School of Electrical and Computer Engineering at Purdue University. My job is to find out things other people do not know and write them down so they do. This book records one of those findings. Over a stretch of a few months I built a real production system — a document-accessibility service, DocAble — almost entirely by dispatching AI coding agents rather than writing code myself. I watched what that mode of work demanded, and this book is what I learned about doing it well. DocAble is the running example throughout; the claims here rest on that real production system. A first concrete look at it comes early, in MAGE by Example; the full description lives at the back, in Part 5 (A MAGE Case Study).

I want to be plain about what this book is and is not. It is not a memoir of the experience, though the experience was strange enough to warrant one. It is not a survey of every AI coding tool, which would be stale before it printed. It is a field report and a method — Model-Based Agentic Software Engineering, or MAGE: the concrete engineering practices that turn a fast code fabricator into a production line you can trust. Where a claim rests on a number, I give the number. Where a practice was learned by getting it wrong first, I say so.

One caution belongs up front, because it colors everything after it. This is a single-case field report: one production system, built by one engineer, watched over a few months. Where I give a number, read it as an observation from that case rather than a measured law. But this case joins a conversation already underway. Practitioner reports agree, in volume, that these practices work with agents: write far more tests than you would for a human team, specify before you build, make the environment hold the line. Those reports supply the what. What the conversation lacks is the how and the why: the mechanism behind the practices, worked out in enough detail to transfer. That is the contribution here. A deep case you control end to end is the right instrument for mechanism — I have built the machine, watched it run, and seen when it worked and how it failed.

A word about where the evidence comes from. Everything in this book rests on one system: DocAble, authored by me inside a single vendor's agent ecosystem, deployed and in daily use by me and my colleagues at Purdue. It is one deep case rather than a broad sample, and every claim stays scoped to it; the closing limitations set out exactly how far that reaches. The book also holds itself to the method it teaches. Its empirical claims are not loose lines in the prose; each is registered in a structured model that binds it to the datum or the citation behind it, and a check reports any claim left with neither. So where a sentence here rests on a measurement, the measurement is tracked, and a missing one shows rather than hides.

A footnote on the evidence. The claims and their backing sit in a small ledger beside the manuscript: each empirical claim tied to a supporting datum or a positioned citation, nested under the book's argument, with a query that surfaces any claim carrying neither. It is the same discipline the book turns on code, turned here on the book's own argument. The colophon lays out the full set of models that govern the manuscript.

Why Build a System to Study a Method?

Building DocAble was not only a way to ship a product. It was a way to ask a question that is hard to ask from the outside. Once agents write almost all of the code, what is the engineering that remains? The question is no longer whether they can produce useful code. They can. It is what is left for a human to do when they produce nearly all of it.

That question resists the usual instruments. A benchmark isolates one capability and scores it. A build report tells you a fleet reproduced a framework, compiled a kernel, or migrated a codebase in a week. A set of interviews tells you how developers supervise the tools they were handed. Each is a real piece, and none of them shows how the pieces move together over the life of a new production system: how an architectural mistake hardens into a lint, how a failure seen twice becomes a gate, how one authored model changes what an agent can do, how the controls pile up until the environment can be trusted to run itself. You cannot watch that from a scorecard or a single interview. You have to build the system, hold it to a standard someone would actually rely on, and watch it over months.

So that is the design of the study. I built something whose quality mattered, let the fleet do nearly all of the implementation, and treated every failure as evidence about the method rather than noise to clean up. The book's vocabulary — governance conversion, the Modeling and Alignment theses, constraints and sensors, the governed engineering environment — names structures that recurred often enough to earn names. I offer them as working concepts, precise enough to compare, argue with, and replace, not as the field's settled terms. Where my investigation extends the existing literature, I have tried to cite the work it stands on, so a reader can see where this case joins the conversation and where it departs.

Read the book in that spirit. One deeply worked case cannot prove that every project will behave like this one. What it can do is open a single machine far enough to say what the rest of us should look for.

Where this book sits on the shelf

Three books frame what this one attempts.

The premise: mechanize discipline

The first is Software Engineering at Google (Winters, Manshreck, and Wright, 2020) ¹1. Titus Winters et al., Software Engineering at Google: Lessons Learned from Programming over Time (O'Reilly Media, 2020). — three Google engineers' account of how the company sustains software engineering across tens of thousands of people and one vast codebase over decades — whose premise this book shares: engineering discipline should be mechanized, not remembered — pushed into review, testing, tooling, and culture so that correctness does not depend on any one engineer keeping a rule in their head. This book carries that premise into a different era and a different workforce. Google governs thousands of human engineers. Here the workforce is a fleet of coding agents, governed by the lints, structured models, and gates they run. The failure mode is not a tired reviewer; it is a confident machine that produces plausible, subtly wrong code across every file at once, at a rate no human can read. The mechanization has to be sharper because the thing being governed is faster and less accountable.

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

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.

The deeper parallel is what each book is fighting. SE@Google exists to keep productivity linear as the team grows. It holds off Brooks's Law: the point where adding an engineer buys less than the last one did, then buys nothing, because the communication paths between N people grow as N-squared and the coordination overhead eats the gain. This book shares the same goal, sustaining linear productivity as you scale up, but scales agents instead of people, and the wall you hit is a different one. An agent does not drown in an N-squared communication circle. It hits a different bound: a fleet is limited by how well its models reason and how much they can hold in view, and when it reaches that bound, ungoverned, it decays into churn. Context pressure is the sharpest driver — when the work outgrows what the fleet can hold in view, the agent loses the thread, re-derives what it already built, and confidently undoes yesterday's fix. That reframing is what the rest of the book turns on: the wall is churn, not the coordination overhead that bounds a team of people.

Churn's causes are three things the fleet does not know. It does not know what to build: the requirements are ambiguous. It does not know how to realize the change: the architecture has drifted into a soup no context window can hold. And it does not know how to change the system without breaking it: every edit lands blind on invariants nobody wrote down. Every technique here attacks a cause, not the symptom. Models attack the first two not-knowings — they bind intent to structure and hold the architecture in a compact form, so the agent knows what to build and the work fits in-window. Governance attacks the third: it keeps a change from introducing errors in the first place, or makes them visible the moment it does.

Churn. The condition in which an increasing share of agent effort is spent rediscovering context, undoing recent changes, repairing regressions, or reconciling inconsistencies rather than advancing the system. It is the agent-fleet form of velocity decay: fixing crowds out building.

The stakes here are tokenomics, not just tidiness. Keeping a task inside the window is far cheaper than letting it spill, and the gap compounds: I once ran four Claude Max subscriptions flat out to keep the fleet fed, and the same velocity now barely fills two — because a model lets each agent find what it needs instead of re-deriving it, and keeps the work in-window, off the cliff where the token bill jumps.

Tokenomics. How many tokens it takes to get a task done — and it is not linear. Overflow the context window and the cost jumps: the harness compacts (a lossy save), and the agent then burns tokens rebuilding the context it lost. So keeping a task inside the window is not merely tidier, it is far cheaper — which is exactly what a model buys, by shrinking what the agent must hold.

The grammar: patterns, and two theses

The second is the Gang of Four's Design Patterns (Gamma, Helm, Johnson, and Vlissides, 1994) ²2. Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994)., the catalogue that gave object-oriented design its shared vocabulary of reusable solutions, whose lasting contribution was less any single pattern than the form — name, recurring problem, solution shape, consequences, known uses — written so an engineer could reach for a vetted answer instead of re-deriving one. This book borrows that form for a new subject. The governance mechanisms it teaches are written as patterns: each names a failure class, the shape that prevents it, why it is not merely the cheaper thing everyone already does, and where it has been used. The companion catalogue restates the full set in that layout, and the appendix here is a patterns reference in the classic style. If SE@Google supplies the premise, the Gang of Four supplies the grammar.

It also supplies a useful contrast. Behind the Gang of Four's twenty-three patterns sits essentially one idea — add a level of indirection — dressed a dozen ways. Two theses drive this book, and they run through every chapter that follows.

The Modeling Thesis. Binding intent and system structure into an explicit, structured model gives agents a compact, coherent representation to reason through, and gives engineers a surface on which to specify, analyze, and predict the system.

The Alignment Thesis. A governance mechanism the environment enforces keeps implementation aligned with intent — a policy decided once holds against every later change — so confidently-wrong work is prevented, or made visible, instead of shipped.

The two theses divide the three not-knowings named above. The Modeling Thesis treats the first two — knowing what to build and how to realize it — by binding intent to a model compact enough to hold in-window; the Alignment Thesis treats the third, changing the system without breaking it, by catching the confidently-wrong edit before it compounds. A model chapter is the Modeling Thesis worked out; a lint, gate, or validator chapter is the Alignment Thesis. Hold those two in mind and the book stops being a list of tricks and becomes two ideas applied over and over. Figure 0.3-1 draws the whole method in one picture.

Hold both theses at once and a larger claim comes into view — the one this whole book argues toward. Models are the universal language of engineering. Every mature engineering discipline reasons about the system it builds through models, not through the raw artifact: a load diagram, a circuit, a control loop. Software could rarely afford to, because keeping the model equal to fast-moving code cost a person's standing labor. Agents cut that recurring cost sharply. They make the code cheap and run the drift checks that keep the map in sync for almost nothing — someone still authors the model and the gate — and that shift relocates the engineer's job upward — to the essential part it could never fully reach before: deciding what the system is for, and authoring the models whose properties drive the tradeoffs. In the system that underpins this book, the code stopped being the bottleneck; the model became the work. For software engineering, models are an idea whose time has come.

And a model cheap enough to keep true stops being a picture of the system and starts running it. The fleet reads its models at commit time to grade its own gates, and at measurement time to shape its own metrics. The map no longer merely stays equal to the territory; it steers the machinery that keeps it equal.

The lineage: the modeling tradition

The third is Model-Driven Software Engineering in Practice (Brambilla, Cabot, and Wimmer, 2017) ³3. Marco Brambilla et al., Model-Driven Software Engineering in Practice, 2nd ed. (Morgan & Claypool, 2017)., the standard concise statement of the modeling tradition: treat models as first-class engineering artifacts, structured representations with defined semantics a tool can check, not pictures pinned beside the code. That tradition is the lineage this book descends from — the M in MAGE — and it inherits the tradition whole, minus its two prescriptions. Classical model-driven engineering prescribes an authoring direction (write the model, generate the code from it) and a heavyweight tool stack to make the generation work. MAGE needs neither. Its claim is about maintenance, not authorship: model and code must stay equal, and agents now keep them equal under drift gates, whichever artifact came first — model authored and code derived, model induced from existing code, or the two co-evolved. The tradition's moment arrives now because one model does two jobs at once: it solves the agent's context problem, since the fleet reasons over a compact picture instead of the whole subsystem, and it holds quality, since the gates keep the map equal to the territory. The executable zoo makes the full inheritance argument.

The three together leave a gap this book means to fill: agentic-era methodology, not how to build an agent but how to engineer with a fleet of them and trust what ships. The titles that share this book's era mostly teach how to build agentic systems, where the agent is the product. This one runs the other way — the agents are the workforce, and the subject is the engineering that governs them.

Three ways to run a fleet

The hard problem of building software with agents is simple to state: the tools are fast and the tools are unreliable. A coding agent can produce more change in an afternoon than a team used to produce in a week, and some fraction of that change is confidently, plausibly wrong. Every account of how to work this way is really an answer to one question — where does the reliability come from? Three answers dominate. Figure 0.3-2 sets the three side by side.

The first answer is velocity. Give the agents autonomy, and organize them the way you would organize people: a planner hands work to a developer, the developer to a tester, the tester to a reviewer, and around the loop it goes. Assigning agents job titles makes the work look like engineering, and the throughput is real. But process resemblance is not control. A ring of role-labeled agents can imitate the form of software work — the handoffs, the review step, the sign-off — without any of it actually catching a bad change. The quality mechanism is left implicit, and implicit quality does not survive contact with volume.

The second answer is oversight. Treat the agent as a useful but untrustworthy assistant, and keep a human next to the implementation loop. You prompt a bounded piece of work, the agent does it, you read the result, you prompt the next piece. This is honest about the failure mode, since agent output does need inspection, and for a while it works well. Its limit is arithmetic. The control is human attention, and attention does not scale with the agents. Turn the volume up and the human becomes the bottleneck: the fleet produces changes faster than any person can read them, and the reading is now the slow step in the whole line.

Field work fills in what that oversight actually involves. Interviews with seventeen experienced developers working alongside coding agents identify four recurring forms — a priori control, co-planning, real-time monitoring, and post hoc review — and find that agent-written code is often hard to inspect directly, so developers lean on tests and other indirect evidence to judge it ⁴4. Shipi Dhanorkar et al., “Human Oversight of Agentic Systems in Practice: Examining the Oversight Work, Challenges, And Heuristics of Developers Using Software Agents,” 2026, https://arxiv.org/abs/2606.05391.. But naming the work does not repeal its arithmetic: every one of those forms still spends human attention per change.

The third answer is governance. Build the environment before the agents work in it. Decide the obligations up front — what must never happen, what must always hold — and encode each one as a mechanism the environment enforces: a type the compiler checks, a lint that blocks a commit, a gate that refuses a bad deploy. The human hands the environment its policies; the environment holds the agents to them. Quality stops depending on a tired reviewer noticing, and starts being a property of the ground the agents stand on.

These three stances are the landmarks of a live debate, and it helps to place the names on them. At the velocity end sits vibe coding, the term Andrej Karpathy coined for prompting an agent and accepting what looks right — Steve Yegge's Gas Town is the same spirit written large. At the far end sits the rigor of formal verification, argued by Bertrand Meyer in From Probable to Provable ⁵5. Bertrand Meyer, “From Probable to Provable,” Communications of the ACM, ahead of print, 2025, https://doi.org/10.1145/3773295. and pursued by the emerging vibe-OS and vibe-tools work on formal tooling for AI-written code. This book stands between them — closer in temperament to the rigorous end, but reaching its assurance by a different route than a proof.

Notice what the first two answers have in common: they are the two ends of one axis. Slide the dial toward velocity and you buy speed by spending reliability; slide it toward oversight and you buy reliability by spending speed. Every point on that line charges the same toll: per-change human attention, whether the human is coaxing the output at the fast end or inspecting it at the slow end. Call it the pet tax — the price of caring for each change by hand. It grows with the size of the fleet until the human becomes the bottleneck no matter which way the dial is set.

Governance is not a point on that line. It is a different move. Instead of choosing where to sit between speed and safety, you change what the reliability is made of: you build the fences and chutes once, up front, and let the guardrails ride every change on their own. The old distinction between pets and cattle names the shift exactly. A pet server is nursed by hand, one at a time; a herd of cattle is run by the fences and the routine, not by attention paid to each animal. Governed agents are cattle. You stop paying attention per-change and start paying it per-class-of-failure — once, when you build the mechanism that retires the class. The dial-trading stops, because you are no longer on the dial.

This book takes the third stance, and then pushes past where the current accounts stop. The governance literature starts from obligations you know in advance (a regulation, an access policy, a rule the organization already wrote down) and asks what mechanism would enforce it. That is the easy half. The hard half, the half I lived, is the obligations you cannot know in advance: the ones that stay invisible until an agent, moving fast, trips over them and breaks something. The engineering that matters is what you do next — reading that failure as evidence of a missing mechanism, and encoding it so the whole class of failure cannot happen again. Velocity is what exposes the missing mechanism. Judgment is what converts it into a guardrail. That conversion, done over and over until the environment can be trusted to run itself, is the engineering this book is about.

The through-line, and who it is for

The through-line is a single idea; hold every chapter against it. When you build with an agent, you are not managing a coder; you are running a printer. A 3D printer builds almost anything you can describe, but only what you describe — hand it a bad model and you get a bad part, so read a bad build first as evidence about the instructions, the representation, and the task boundary, not by reflex as a limit in the machine. An agent is the same. It builds most of what you can explain to it, and the entire discipline of this book lives in that "so long as you can explain it." Explaining a system to a probabilistic machine well enough that it builds the right thing, at speed, without a human reading every line — that is a real engineering craft, not a knack, and it can be taught.

This book is for the software engineers who suspect the ground has moved and want to know where to stand. On the surface it is about a tool I built to help people with disabilities access documents. Underneath, it is about a working method for building anything with agents: how to frame the problem, model the world for the machine, put every change on rails from dispatch to production, and convert each failure you hit into a guardrail that stops the next one. You will not need my domain to use any of it. You will need a codebase, an agent, and the willingness to treat the instructions as the job.

Everything that follows is one move, repeated: convert judgment into infrastructure.