Preface

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 is one of those findings. Over a stretch of a few months I built a real production system — a document-accessibility service, DocAble, described in the two Context chapters that open the book — 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.

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: 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.

Where this book sits on the shelf

Two books are the touchstones I want you to hold this one against, because between them they frame what I am trying to do.

The premise: mechanize discipline

The first is Software Engineering at Google (Winters, Manshreck, and Wright, 2020). Its premise is the one this book shares: engineering discipline should be mechanized, not remembered. Google's problem is sustaining a codebase over time at large human scale, and its answer is to push discipline into review, testing, tooling, and culture so that correctness does not depend on any one engineer keeping a rule in their head. This book runs 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, typed 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 takes 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 collapses into churn when the work exceeds its context window: it loses the thread, re-derives what it already built, edits in circles, and confidently undoes yesterday's fix. That is the reframing the rest of the book turns on. The scaling limit for an agent fleet is the context window, and the failure it produces is churn, not the coordination overhead that bounds a team of people.

Churn has two causes, and every technique here attacks one of them. Models shrink what the agent must hold in-window, so the work fits before it churns. Governance keeps the agent from introducing errors in the first place, or makes them visible the moment it does.

Churn. The agent-fleet form of velocity decay. As the architecture drifts, the fleet's commits begin to introduce errors as well as features, so it spends more of each session repairing what recent sessions broke — until fixing crowds out building.

The grammar: patterns, and two theses

The second is the Gang of Four's Design Patterns (Gamma, Helm, Johnson, and Vlissides, 1994). Its lasting contribution was less any single pattern than the form: a name, the recurring problem it solves, the shape of the solution, the consequences, and the known uses, written so an engineer meeting a familiar situation could reach for a vetted answer instead of re-deriving it. 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. This book runs on two theses, and they run through every chapter that follows.

The Modeling Thesis. Binding intent to implementation with a typed model optimizes the agent's context window — it reasons over a compact model instead of the whole subsystem — so the work fits in-window and stays coherent instead of churning.

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 attack the two causes of churn named just above. The Modeling Thesis optimizes the context window, the scaling limit that starts the churn; the Alignment Thesis catches the confidently-wrong change 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.

The Modeling Thesis pays off now for a reason it never did before. Model-based engineering has always been sound in principle and dead in practice, killed by a single cost: keeping the models in sync with the code was human labor no team sustained, so the map drifted from the territory until no one trusted it. Agents dissolve that exact cost. They hold a model, re-derive it, and re-check it against the code on every change, for cents. The one expense that buried model-based engineering is the one thing a fleet does for nearly free, which is why a discipline that never repaid its upkeep suddenly does. It is the book's strongest claim, and Part 4 is where it is earned.

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. Watch for that turn as the book goes on.

Between the two lies the 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, and it is worth naming them before I tell you which one this book takes.

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.

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 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 a single axis. At one end sits pure velocity, all throughput and no durable guardrail; at the other sits pure oversight, everything checked before anything is trusted. 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 trades one against the other, and every point on it 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. That attention 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. The chapters that follow are, almost entirely, that conversion done over and over until the environment could be trusted to run itself.

The through-line, and who it is for

The through-line is a single idea, and it is worth stating up front so you can 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, every time, and the fault is in the instructions, not the machine. An agent is the same. It can build essentially anything 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.

Let me show you what I found.