Implications for Software Engineering

I built one system, alone, with a fleet of agents, and I have tried through this book to say what I learned from it without pretending it was ten systems or a controlled trial. It was neither. But the shape of what happened is general enough that I want to step back from the particular product and ask what it implies for the discipline. If code is becoming cheap and judgment is becoming the scarce thing, then a number of assumptions the field has carried for decades were priced for a world that is ending. This section is about which ones.

I will state the through-line first and defend it in pieces. The single mechanism under all of this is that velocity exposes failure. Agents produce change fast enough that the ambiguities, the missing abstractions, the weak boundaries, and the absent oracles surface in a matter of hours instead of quarters. That speed is not only a source of risk. It is also a source of perception — related failures that would ordinarily arrive weeks apart now arrive inside a single afternoon, close enough together that you can see the structure they share. What you do with that perception is the whole game.

Everything the book taught to do with it reduces to two theses, and it is worth naming them here where the payoff lands. The Modeling Thesis is to use models to bind intent to implementation — a typed picture the agent reasons over, held equal to the code by a gate, which optimizes the context window so the work fits before it churns. The Alignment Thesis is to add a governance mechanism — a constraint or sensor the environment enforces, so a policy decided once holds against every change after and confidently-wrong work is caught, not shipped. The preface promised these were the book's answer to a single problem, and here is that problem stated plainly. What software engineering has always wanted is to keep productivity linear as you scale it up; the classic account, at human scale, fights Brooks's Law and the N-squared communication overhead of adding people. Scale with agents instead and the wall is a different one. An agent does not drown in coordination. It collapses into churn when the work outgrows its context window — losing the thread, re-deriving what it built, undoing yesterday's fix. Both theses are aimed squarely at that wall. Models shrink what the agent must hold in-window, so the work fits before it churns. Governance keeps the agent from introducing those errors in the first place, and makes the ones that slip through visible. Read this way, the rest of this chapter is what those two theses imply once you believe them.

From governing what you know to discovering what you don't

The tidy version of governance says: figure out your obligations in advance, encode them as mechanisms, and let the agents run inside the fence. Do that. It works, up to a point. For the accessibility product I had conformance checkers, content-preservation and provenance checks, and the ordinary commodity linters, all of them known before a single agent touched the code. These were necessary. They were not sufficient, and the gap between necessary and sufficient is where the interesting part lives.

The claim I want to make is that under agentic velocity, many of the mechanisms you need cannot be written down before the work begins. You discover them by failing. An agent makes a plausible, confident, wrong change; you look at it and ask not merely "is this acceptable?" but "does this failure reveal a hole in my governance?"; and when the answer is yes, you convert the hole into a durable mechanism. Governance stops being a fixed layer bolted onto agent work from outside. It becomes something the environment learns — a process, running continuously, that turns agent-produced failures into architecture and lints and gates that constrain the next agent.

This is why oversight, on its own, does not scale. The oversight model asks a human to supervise each change. At the volumes agents produce, no one reads the diffs, and a human who tries becomes the bottleneck the velocity was supposed to remove. The move that scales is different: you do not inspect each instance of a failure class, you convert the class once so that future instances need no inspection. Work that produced no failure signal gets admitted. Work that exposed a recurring failure class earns a new mechanism. The leverage comes from the conversion, not the vigilance.

Soft mechanisms saturate; the substrate has to become machine-actionable

Here is a proposition I would put money on, though I have only a single case behind it. As velocity rises, tacit and review-centered mechanisms saturate, and deterministic ones do not.

The reason is arithmetic. A convention that an agent follows ninety-nine times in a hundred looks like a working mechanism when one engineer works at human speed. Run it across a fleet at agentic velocity and the hundredth violation stops being rare and becomes a certainty, many times a day. A low-probability harness violation, at volume, is not a risk. It is a schedule. Words are soft, and softness is fine until the sample size gets large enough to find every edge you left in.

I have a concrete one. My cleanup routine had to distinguish a finished agent's abandoned worktree from a running agent's — and my rule for it lived in the instructions I wrote for each cleanup pass: "check that the agent isn't still in flight before you delete its workspace." It read as sound, and it failed three times in five days, each time destroying a live agent's work. The trap was timing: a freshly dispatched agent looks, for its first minutes, exactly like a finished one — a single bookkeeping commit and nothing else — so any check that reads the commit history at one instant misclassifies it. Rewording the instruction did not help; I reworded it three times. What ended the recurrence was moving the check out of the prose and into the tool: the dispatcher now writes a marker file when an agent boots and the tool deletes it only after the agent is truly done, and the cleanup refuses to touch any workspace whose marker is still present. The convention was correct and unenforceable; the marker is a fact the tool reads the same way every time, and it cannot be reworded away.

So the governance has to move down into the substrate where a machine can enforce it: into types the compiler checks, schemas a validator reads, lints and analyses that gate a commit before a human ever sees it. This is not a rejection of the soft mechanisms. The briefs, the templates, the prose conventions still aim the agents; they do real work. But they must be mated to deterministic mechanisms that hold the line whether or not the agent cooperates. The soft layer guides; the hard layer holds. At velocity you need both, and the failure mode of relying on the soft one alone is quiet. The convention looks obeyed right up until the day the volume finds the gap.

There is a counterintuitive corollary here that took me a while to trust. Stronger mechanisms do not always tax velocity. Often they compound it. An agent that hits a deterministic guardrail gets an immediate, legible signal it can act on, and recovers from its own mistake without a human in the loop. The guardrail that would have felt like friction to a human team is, to an agent fleet, the thing that lets the throughput continue at all.

Models and agents are the closest thing to a silver bullet

Fred Brooks warned the field off silver bullets forty years ago. No single development — no language, no tool, no method — would give an order-of-magnitude gain in productivity, reliability, and simplicity at once, because the hard part of software is essential: the complexity of the problem itself, not the accidental complexity our notations and tools pile on top. You can shave the accidental part. The essential part does not yield to a trick, and anything sold as making it yield is snake oil.

I want to make a claim in that vocabulary, carefully. Working at the model level, with an agent doing the work, comes closer to a silver bullet than anything I expected to see. You get three things together that a team normally has to trade against one another. Fewer tokens — the agent reasons over a compact model instead of dragging a subsystem's worth of source through its window. More velocity — with the right picture in one window, the change lands faster and needs fewer round-trips. Higher quality — the same model carries invariants the agent checks its work against, so the change that lands is one a gate already vetted. Token reduction, speed, and quality do not come at each other's expense here. They arrive together, and roughly for free.

That is a large claim, so let me disarm the part that sounds like magic. This is not free in the sense of something for nothing. It is free in the sense that one move buys all three, and the reason is not luck. A model is a distinct level of abstraction to work at. It bridges the documentation and the code: accurate like the code, compact like the prose. An agent has a bounded window and reasons over whatever you put in it. Fill it with raw source and you spend tokens on detail that does not bear on the change, and the agent reasons over the wrong things. Fill it with the model and the join to the relevant code, and every token in the window earns its place. The gain is not that the agent got smarter. It is that the agent is now reasoning over the right representation. As long as the agent is good enough to work that representation faithfully, the models do the lifting — and because a human can read a model where a human cannot read the diffs, you keep review and control at the same time.

Now the Brooks-honest part, because this is where a lesser claim would overreach. The model level does not abolish essential complexity. Accessibility remediation across four document formats, each with its own tag model and conformance spec, is genuinely hard, and no model makes it easy. What the model level does is attack the representation the agent reasons over — which is exactly the accidental complexity Brooks told us was the only kind a tool can touch. It strips the accidental cost of holding a large system in a small window, and it leaves the essential difficulty sitting in plain view where a human's judgment can meet it. That is why I will say closest thing to a silver bullet and not a silver bullet. Brooks was right that the essential part does not yield. The model level is the sharpest tool I know for spending your effort on the essential part instead of drowning in the accidental one. And the accidental cost it strips — holding a large system in a small window — is precisely the one that limits an agent fleet. That is the Modeling Thesis paying off against churn: bind intent to implementation through a model, and the churn wall moves out of reach.

The judgment moved, and it moved toward you

If implementation is abundant, the human's comparative advantage is no longer producing code. It is the work that surrounds the code: framing the problem, discovering the abstraction, making the architectural call, and designing the governance under which fast code can be trusted. Better agents do not shrink this work. They make it more consequential, because better agents raise your ambition and your concurrency, and the decisions about what to build and how to bound it are what determine whether all that throughput becomes durable progress or an expensive pile of churn.

Two things gate whether this works, and they are worth naming because they are the conditions under which the whole method holds or fails.

• Capability-fit. The agents have to be matched to human judgment good enough to interpret their failures. Give a capable fleet to someone who cannot tell a local defect from a structural one and you get motion without direction. The governance does not design itself; a person has to look at a failure and decide it is the symptom of a missing abstraction. In my case the model itself was unreliable at drawing that line, and only began proposing sensible structural fixes once the codebase had accumulated enough worked examples to imitate.
• Authority. The person who sees the recurring failure has to be able to change the environment — the architecture, the mechanisms, the gates. This sounds trivial when one engineer owns the whole system. It is not trivial in an organization, where authority is split across teams, owners, review boards, and deployment pipelines. Split the authority and the same failure signal produces a local patch instead of a shared mechanism, and the class never dies. Agentic tools compress team-scale coordination into a single workflow; that compression is exactly what makes authority the pressure point.

What this changes for how we measure, staff, and teach

A few consequences follow, and I will keep them short because each could be its own argument.

Measure governed throughput, not volume. Commits landed, lines changed, tasks completed — these count activity. They do not tell you whether the activity became durable software. The question that separates progress from churn is whether agent-produced failures are getting converted into reusable governance, and whether later work benefits from those conversions without the whole thing losing coherence. Optimize for volume and you will get volume; you will also get a fast pile of slop with no one able to read it. I have the commits to prove that too.

The marginal cost of quality dropped, so treat quality work as affordable. The refactors and architectural improvements that a conventional team defers because they are too expensive become feasible when an agent fleet can carry out the mechanical part in a day. I moved an entire front end to a typed language over a weekend and saw no defects under the project's own checks. The same speed that manufactures technical debt can also pay it down — and, because related failures cluster in time, can make the architectural gap visible in the first place. Speed cuts both ways; which way depends on whether you convert what it exposes.

Read model failure as a framing problem before a capability ceiling. When an agent fails a delegated task, the tempting inference is that the model cannot do it. Sometimes that is true. Far more often, in my experience, the task simply had not been framed as an inspectable, controllable process — the difficulty was mine, not the model's. The working disposition I ended up with was to assume that I was the problem: to treat a failure as a cue to decompose further and constrain harder, not as evidence of a ceiling. There is a paradox worth sitting with here. The model is valuable because it reasons over open-ended inputs, and yet the method is largely about systematically removing its opportunities to reason unconstrained. That is not a contradiction. It is a response to a machine that flips a probabilistic coin at every step: you do not exclude the probabilistic behavior, you bound it — soft guidance going in, deterministic guardrails on the actions, and a deterministic envelope on what gets admitted out.

For research and education, attend to the environment, not only the agent. We already know agents can generate. The open question is which engineering environments make that generation governable — and whether agents can be taught to notice inadequate governance themselves, rather than waiting for a human to convert every failure by hand. For teaching, the implication is uncomfortable but clear: the comparative advantage is shifting away from syntax-level production and toward specification, abstraction design, validation, and process. That is not a softer curriculum. It is a harder one, and it is the one that will matter.

What I have not shown you

I should be plain about the edges of this. My evidence is one system — a real production service, but a single-author one, without a crowd of stakeholders pulling the design in directions I could not veto, and run against one vendor's models over a few months. The shape of the method feels durable to me. The specifics will not all generalize, and I would be suspicious of anyone who told you theirs did.

And I have done some of this, not all of it. The parts I knew were sensitive, I governed hard — a strong architecture, typed models, enforcement that fails the build when the map and the territory disagree. The parts I hoped the agent would simply get right, it did not, and those turned crufty; the honest recipe for digging them back out is the brownfield chapter, and I am still walking that recipe on my own codebase as I write this. So read the method as a direction I am convinced of and a destination I have reached in patches, not a finished tour of a system that is governed end to end. It is genuinely hard work. It trades the friction that used to live in typing for a different friction — the up-front judgment of deciding what to model, where to enforce it, and when to stop — and that friction does not disappear, it moves.

If you try this on a codebase of your own, I want to hear how it goes — where it held, where it broke, where your setting behaved differently from mine. A single-author study is a starting point, not a proof, and the only way the shape gets sharper is more people running the experiment and reporting back. Come tell me what you found.