1.1 The Printer

Coding agents have made writing software cheap. Describe what you want and a capable model builds it, fast, at a scale no team could match. Implementation is abundant now. What has not come with it is reliability: the same machine builds the wrong thing as readily as the right one, and just as fast.

So the chapter opens on the question the whole book turns on: when an agent builds the wrong thing, whose fault is it? Treat the agent as a printer, not a coder. A printer builds exactly what its instructions describe, so read a bad build first as evidence about the instructions, the representation, the task boundary, and the environment that produced them — not, by reflex, as a fixed ceiling in the machine. That shift in posture is the premise everything after this chapter rests on. If implementation is cheap and unreliable, the engineering moves to authoring what the printer reads.

1.1.1 What this book is about (and what it is not)

Of course, not every programming task needs the machinery this book describes. Some tasks a capable model can simply do. You describe the input and the output, you push the button, and a working program comes back on the first pass. No iteration, no governance, no loop management. Knowing which tasks are like that, and which are not, is the first judgment an agentic engineer has to make. Figure 1.1-1 lays out that judgment as a flowchart.

The two modes

Start at the decision on the left. You have a computational task and you can say what it takes in and what it must produce. From there the path forks on how big and how hard the work is.

One-shot scripting is the righthand branch. The task is small, a few thousand lines at most, and it does not ask the agent to reason its way through anything subtle. Think of a CSV-to-HTML report script. You specify the behavior once, the agent writes it in a single pass, and you read the result. The whole transaction fits in one context window and one sitting. When a task really is this size, the full apparatus of governed autonomy is wasted effort. Send it one-shot and move on.

Supervised autonomy is the downward branch, and it is where most of this book lives. The task is hard, especially if it includes reasoning, and it is too large to hold in a single context window or to trust to a single pass. So you do not hand the agent the whole job and hope. You supply four things, in two groups. The system side shapes what gets built:

• Correctness conditions — what a right answer looks like.
• Sub-tasks — the breakdown you have proposed to divide the work.

The development side shapes how the building runs:

• Tools that determinize recurring processes, so the same operation runs the same way every time.
• Monitoring and intervention, so you can watch the work and step in when it drifts.

Those four are the skeleton of supervised autonomy, and each later part of the book fills one of them out.

Where the emphasis falls

This book covers both modes. It has to, because the first skill is telling them apart, and getting that wrong in either direction is expensive. Treat a one-shot task as if it needed supervised autonomy and you drown a five-minute script in ceremony. Treat a supervised-autonomy task as if it were one-shot and you get confident, plausible, subtly wrong output at a scale no human can read.

So the book spends real pages on the sizing question. How long a leash a task can run on comes down to two things: how densely the model's training data covers the kind of work you are asking for, and how capable the model is at that work in the first place. The denser the coverage and the stronger the model, the more briefly a task can be described and the farther it can be trusted; the nearer the task sits to the edge of what the model has seen, the more the reasoning must be broken into smaller, checked steps. Judging that distance tells you whether a job can go one-shot or must be supervised, and the book gives you the means to judge it.

But the weight of the book is on the downward branch. The interesting engineering, the part that did not exist a few years ago and is not yet written down, is supervised autonomy: building larger-scale products whose quality needs exceed what a model can be trusted to do alone, and whose size exceeds current and foreseeable context windows. That is the regime where you stop pressing go on a script and start running a printer, framing the goal, modeling the world for the machine, and putting every change on rails from dispatch to production. Everything after this chapter is about how to do that well.

Writing code used to be the expensive part. It no longer is. So the premise of the book is short: we've got a fast code-fabricator and we need to figure out how to turn that into a production line.

1.1.2 The printer

Think of a 3D printer. It will build almost anything you can imagine — a replacement gear, a prosthetic hand, a scale model of a building — out of nothing but spooled filament. Its only hard limits are the material and your own creativity. That machine is the metaphor that drives this entire book, because building software with a coding agent is far more like running a 3D printer than most people expect — a difference the rest of this chapter unpacks.

1.1.3 An open-ended technology

A 3D printer belongs to a rare class of technology — the open-ended kind — alongside the invention of writing and the printing press. What those three share is that none of them arrives with a list of what to make. People had to invent that. Writing began as marks for counting cattle; only later did someone find you could write a poem, and later still that a poem could rhyme, could take a stanza, could hold a shape — and then the textbook, the treaty, the contract. Each was a genre somebody had to work out. The printing press inherited every genre writing had found, and then, by making production cheap, minted ones no scribe could ever have justified: the poster, the pamphlet, the newspaper.

Generative AI belongs to this class. It is open-ended in the same way — it will make almost anything, and it hands you no list. So running the machine is the smaller half of the work; the larger half is working out which genres are worth producing, and the method for producing each one well. This book takes one genre and gives it a method: production software — code whose quality metrics you actually care about, and whose every change you can trace back to the metric it moves.

Quality metrics. The properties of the code you actually care about — correctness, performance, security, maintainability — named explicitly, and traceable: for any change, you can point to the metric it moves. Production software is code whose quality metrics are named and whose changes map back to them.

The quality floor, made cheap. The apparatus in this book — the models, the gates, the traceability — is the price of any software you can trust: name the properties that must hold, check them, and keep every change tied to the property it moves. That price was always the same. What changed is who can afford it. For decades this level of assurance was reachable only by the shops that could justify the cost — the Rolls-Royces and the Boeings, where a mistake is catastrophic and a modeling program pays for itself. Agents drop that cost to almost nothing: they write the checks, maintain the models, and hold the line, so the quality once affordable only to a regulated few is now within reach of almost anyone. The method teaches how to get very high quality nearly for free. For the data, see The ADA Context →

1.1.4 A picture is not enough

Everyone can sketch a piece of software. We have all used Google Maps, spreadsheets, a document editor — programs that take in data and do something useful with it. The concept is easy to picture. But a picture is not a thing you can print.

Hand a 3D printer a photograph of the object you want and nothing comes out. The printer needs instructions: a CAD model that shows not just the outer shape but the internal structure — how the pieces fit, where the load is carried — and then a set of print notes on top of that. You slice the model into layers, and you think about how those layers compose as the machine lays them down. Different materials have different minimum thicknesses, different strengths, different joints that hold and joints that fail. There are a hundred ways to misprint a part that looked fine as a picture.

Software agents are the same. You cannot hand an agent only the picture of what you want. You must also give it — or work out how to articulate — the detailed instructions for how to build it. Good instructions, and it works beautifully. Bad instructions, and you have not got a hope.

1.1.5 Whose fault is it?

Here is the shift in posture the whole book turns on. When you use a stapler and the staple jams, that is the stapler's fault, not yours. A stapler is supposed to just work — it is so foolproof my three-year-old runs one, insert the paper, ka-chunk, no problem. That is exactly what an agent is not. An agent is not a stapler — it is a printer, and a printer only ever builds what its instructions describe. So when the agent produces the wrong thing, suspect the instructions first.

In my own experience, when an agent has failed to produce what I wanted, the fault has almost always been mine — the instructions, the way I represented the problem, where I drew the task boundary. Look there first, before you conclude the model simply cannot do the work. The strong models build most of what we can envision in software — so long as you can explain it to them. That "so long as" is the entire job, and it is an engineering discipline this book teaches. And the discipline is older than it looks: an engineer has always been accountable for the instructions handed to a machine, even the ones not hand-crafted — the back matter returns to what that responsibility becomes when the thing you author is the model, not the code.

The printer builds anything you can describe. That, of course, is the promise, and it is real. But it is also the danger, because a printer with no judgment behind it builds a wrong thing as fast and as willingly as a right one, and carries you at full speed exactly where your instructions point.

Claude is the fastest road to hell.

The danger was already in the instructions; the speed just gets you there first. Hand the machine a doomed idea and it does not slow down to warn you; it makes the doomed idea better and better, an afternoon and ten thousand plausible lines deep into a dead end you picked. The printer that builds anything will build your mistake with the same tireless fidelity it builds your success. Which one you get is down to your instructions.

A word on the example this book builds on. The running example is a real shipped system: DocAble, the production accessibility-remediation tool — its own pipeline, its own agent fleet, its own scars — described in full at the back, in The Built System. Every later chapter returns to it, so what you watch getting printed correctly, chapter by chapter, from model through mechanism and architecture to migration, is a system that shipped. The next chapter gives you a first concrete look.