Chapter 5 — What Actually Breaks

"It is not enough to know that a fence stands in a field. Before you remove it, you must know what it was keeping out."

— after G. K. Chesterton

5.1 The assumptions nobody wrote down

Chapter 1 quoted an inventory of what breaks: the author is a model, changes move at machine speed, the IDE is no longer the first feedback point, the pull request is no longer a natural checkpoint, and dependencies are chosen by something that never read the package name [D]. It is a good list, and Cycode deserves credit for assembling it early.

This chapter asks the two questions the list does not: why does each item fail, and what do they have in common?

The answer to the second question turns out to determine the whole shape of the book, so I will state it now and spend the chapter earning it.

Every one of those failures traces to the same source. Software engineering's most important controls were never designed. They were side effects of the price of code. For fifty years, writing a line of working software was expensive — in time, in attention, in the scarce supply of people who could do it — and that expense quietly purchased five distinct goods that no methodology document ever claims credit for, because nobody was billed for them.

This is the reason tools cannot fix what is breaking. The five goods were not in any tool. They were in the price.

It is also why the failure feels bewildering to experienced engineers. Nothing in their training identified these as mechanisms, because from the inside they did not look like mechanisms. They looked like how software works. You do not notice the ballast until the ship rides high.

Taleb's recurring warning is that efficiency campaigns remove slack that was performing an unadvertised function, and that the removal looks like pure gain right up until the function is needed. Software engineering ran the most successful efficiency campaign in industrial history — seventy years of making correct code cheaper — and the cost we were removing was load-bearing in ways the campaign never enumerated. That is not an argument against the campaign. It is an argument for paying attention to the invoice that has now arrived.

5.2 Assumption 1 — production is the expensive step

What was assumed. That the scarce resource is the capacity to produce correct code, and therefore that the lifecycle should be organised around producing it: specify so implementation is unambiguous, design so implementation is tractable, test what implementation produced, release it.

Why it failed. Chapter 3, in one line: generation is elastic and review is not. A team can multiply its output of pull requests by adding tokens; it cannot multiply its capacity to understand them by any comparable means. The best-documented enterprise case doubled per-capita merged pull requests in twelve months and doubled per-reviewer load in the same period [B]. Brooks explained in 1975 why the second number cannot be fixed by hiring.

What this invalidates. Not just the ordering of phases — the object of optimisation. Every methodology since the 1970s competed on how to get to working implementation faster and with fewer defects. Agile shortened the loop. DevOps automated the path to production. Both are optimisations of a pipeline whose expensive stage has moved.

The replacement. Verification capacity becomes the managed constraint: measured (Chapter 14), staffed and organised for (Chapter 16), and partially mechanised (Chapters 7–8), because Chapter 3's four valves leave no other option that actually raises capacity.

This is the assumption whose failure everyone already accepts in principle. The remaining four are the ones that surprise people.

5.3 Assumption 2 — effort is evidence of care

This is the deepest failure and the least discussed, so it gets the most space.

What was assumed. That the existence of a change implies someone reasoned about it.

Nobody wrote this down either. But consider what a pull request meant in 2015. Someone had read enough of the codebase to find the right file. They had held the problem in their head long enough to form an approach. They had typed it, watched it fail, and fixed it. By the time the request existed, hours of human cognition had been spent, and the artefact was evidence of the cognition.

That evidentiary relationship is what made code review work. A reviewer was not auditing from zero. They were checking a considered artefact produced by a colleague who had already eliminated the obvious errors. Review could be cheap precisely because authorship was expensive.

Chapter 1 noted that the pull request is no longer a natural checkpoint. Here is the mechanism, and it is worth stating carefully because it generalises:

The pull request was never a checkpoint by design. It was a checkpoint by cost. Its authority came entirely from the expense of producing one. Remove the expense and the gate remains in the process diagram while its informational content goes to zero.

Note what Figure 5.2 does not claim. It does not say agent-authored changes are careless. Chapter 3 found flat merge and revert rates across 196,212 pull requests, and Chapter 4 conceded that a controlled experiment reportedly found no maintainability penalty. Care may be entirely present. The claim is narrower and worse: you can no longer read care off the artefact's existence. The signal is gone, whatever the underlying quantity is doing.

Chapter 3 supplies the corroborating symptom. Average pull-request size rose roughly 37% on adoption and a further 33% after the mandate. If submitting were still expensive, batching would be rational and readable. When submitting is free, a large pull request is no longer evidence of a large deliberate unit of work; it may simply be what fell out. The unit drifted, and the gate that took the unit as its input inherited the drift.

The practical instrument. This yields a diagnostic sharp enough to run this week, and I think it is the single most useful thing in Part I.

For each gate in your process, ask: if producing the artefact became free, would this gate still carry information?

Work through it honestly and the results sort cleanly.

The pattern in that table is the most important structural fact in the chapter, and it is more optimistic than the rest of this section sounds.

Every gate that survives is computational. Every gate that fails is social.

A type checker never asked how hard you worked. It checks a property of the artefact, and its verdict is identical whether the code was typed by a principal engineer over two days or generated in nine seconds. The gates that have been debased are exactly those that inferred an unobservable — care, understanding, intent — from an observable that used to correlate with it and no longer does.

Which tells you where the authority has to move: from social gates to mechanical ones, and for the residue that genuinely requires judgment, from inferred judgment to demonstrated judgment. That reallocation is the entire subject of Chapters 7 and 8, and it is why Chapter 1 insisted that the deterministic merge gate is a gift rather than a formality.

5.4 Assumption 3 — the author has intent you can interrogate

What was assumed. That behind every change stands someone who knows why, and can be asked.

Code review is a social protocol before it is a technical one. Its central move is a question: why did you do it this way? The answer recovers information that is not in the diff — which alternatives were considered, which constraint forced the shape, which convention was being honoured. Ozkaya's observation is that architecture knowledge encodes why, and why is not recoverable from what [D] 🔴.

Why it failed. The author now has no memory of the session, no stake in the outcome, no reputation among the people who will maintain the code, and no expectation of being the one called at three in the morning. Ask an agent why and you will receive a fluent, plausible reconstruction generated after the fact — which is worse than no answer, because it is indistinguishable from a real one.

Chapter 4 met the same failure from the structural side. The reason human codebases resisted entropy was a felt cost — call it taste — that opposed the cheap option. That feeling was the same faculty that answered why. Both were properties of having a person there.

What this invalidates. Review as dialogue. What remains is review as inspection: you can check the artefact against stated criteria, but you cannot recover unstated intent by asking.

And this is where Chapter 0's closing line stops being rhetoric and becomes an engineering constraint:

A harness cannot verify correctness against a requirement that was never articulated.

If intent cannot be recovered after generation by interrogating the author, it must be externalised before generation, in a form a machine can check. That is not a preference for documentation. It is the only remaining place for intent to live.

The replacement. Specifications, acceptance criteria, guides, and architectural decision records move from documentation — a nice-to-have, historically the first thing cut — to load-bearing input. Chapter 6 treats them as part of the context payload; Chapter 12 makes stating intent the first phase of the inner loop rather than a precondition assumed to have happened; Chapter 22 gives spec-driven development its proper place as one guide among several.

There is an irony worth noting, since Chapter 1 set it up. This is precisely the problem Meaning A solved. Nobody building an agent as a product would let the system under test author its own acceptance criteria. The eval set is built first, by humans, from stakeholder-aligned success metrics. Meaning B has been letting the generator write its own tests and calling it a behaviour harness. Chapter 8 attempts the transplant.

5.5 Assumption 4 — feedback arrives faster than change

What was assumed. That the loop is faster than the process it observes. This is the premise beneath continuous integration, shift-left, trunk-based development, and small batches: catch problems while they are cheap, which requires catching them soon, which requires the detector to outrun the change.

Why it failed. Chapter 3's arithmetic. Arrival rate rose by a factor of two to three; review capacity did not move. When λ approaches μ, the queue's response time diverges, and the detector is no longer ahead of the process — it is behind it, working on a state of the world that has already been superseded.

There is a control-systems statement of this, and it is not a metaphor: a regulator slower than its plant does not regulate it. It produces an output that was appropriate to a past state. In signal terms, sampling a process more slowly than it changes does not merely give you an incomplete picture; it gives you a wrong one, because the samples alias into a pattern that was never there. A reviewer working through a backlog of week-old pull requests against a codebase that has moved twice since is not reviewing slowly. They are reviewing something else.

What this invalidates. Not the principle — keeping quality left remains correct, and Chapter 8 develops it. What is invalidated is the assumption that human review can be the left-most meaningful control. If the detector must outrun the change, and change is now machine-paced, then the left-most controls must be machine-paced too. Human judgment relocates rightward and upward: to the specification before generation, and to the harness that governs the whole class of changes, rather than to each instance.

The replacement. Sensors distributed by cost and speed across the change lifecycle, cheapest and fastest first — pre-commit, pre-integration, pipeline, continuous drift. Chapter 8's ordering rule follows directly: use the cheapest deterministic sensor that can detect the failure class, and reserve inferential sensors for what genuinely needs judgment. Chapter 2 supplied the empirical warrant, in the linting guardrail that cost milliseconds and prevented a cascade that halved recovery odds.

5.6 Assumption 5 — only code is instruction

What was assumed. That the trust boundary of a software project runs around write access. Everything inside — source, configuration, build scripts — is instruction, and is therefore controlled. Everything outside — issue text, pull-request comments, documentation, package names, error messages, web pages — is data, and is therefore safe to read.

This assumption was so solid it was never a security control at all; it was the substrate the security controls were built on.

Why it failed. An agent reading an issue in order to fix it cannot reliably separate the description of a problem from an instruction about what to do. OWASP's 2026 Top 10 for Agentic Applications ranks Agent Goal Hijacking (ASI01) first, on exactly this basis: because agents cannot reliably distinguish instructions from data, a single poisoned input can redirect an agent to cause harm using its own legitimate tools and access [C].

The structural consequence is a change in who can attack you, and it deserves stating as starkly as it deserves:

Previously an attacker needed write access to a trusted repository. Now they need the ability to open an issue.

What this invalidates. The location of the trust boundary, and therefore most of the reasoning built on top of it. Code review protected the inside; nothing protected the reading of the outside, because reading was never dangerous.

The replacement. Every artefact an agent reads is treated as untrusted instruction; capability scoping is designed on the assumption that any input may be adversarial; and — Chapter 11's most counter-intuitive finding — some controls that look protective enlarge the attack surface, which is the same iatrogenic shape Chapter 2 found in a search tool that scored below having no search at all.

5.7 The sixth, and the common cause

Chapter 4 spent itself on a sixth assumption: that structure self-corrects. Complexity is monotone under additive change, and human codebases stayed bounded only because they contained an unmeasured negative feedback loop — a maintainer's discomfort exceeding tolerance. Delegation removed the loop and multiplied the input rate.

Line the six up and the pattern in Figure 5.1 is unmistakable.

Six rows, and the right-hand column has two entries: the price of production and the presence of a person. And the second reduces to the first, because a person was there only because production required one.

So the six failures are one failure, observed from six angles. Which explains three things that are otherwise puzzling.

Why they are simultaneous. Nobody removed six controls. One thing was withdrawn, and six goods were resting on it.

Why they were invisible. None was designed, so none was documented, so none appeared in any methodology's list of what it depends on. You cannot audit a dependency nobody declared.

Why tools cannot supply them. The goods were properties of the economics, not of any artefact. A better editor cannot restore the informational content of a pull request, because that content came from what a pull request used to cost.

And it gives the book its shortest available definition, which I will use for the remaining twenty-two chapters:

ADLC is the discipline of explicitly buying what the cost of writing code used to provide for free.

Scrutiny becomes sensors. Intent becomes specifications and guides. Pacing becomes controls distributed by speed. The trust boundary becomes capability scoping. Homeostasis becomes standing drift detection. Each was free; each now has an engineering cost, an owner, and a line item.

This also puts a necessary limit on Chapter 0's Lindy argument, and honesty requires stating it. I claimed that ideas surviving fifty years should be trusted over ideas surviving eighteen months, and used Parnas as the example. That heuristic needs a qualification: Lindy protects against the passage of time, not against a change of regime. Parnas survives because information hiding is a claim about structure, and structure did not change. "A pull request is a checkpoint" does not survive, despite being just as old, because it was a claim about cost, and cost changed by orders of magnitude. The rate-of-change stack in Figure 0.2 should therefore be read not as a ranking by age but as a ranking by dependence on economic parameters that can move. Age is a decent proxy for that. It is not the thing itself.

5.8 Why this is not Agile or DevOps done properly

The obvious objection, and it deserves a direct answer.

Agile and DevOps were responses to real constraints and they worked. Agile attacked the problem that requirements were unknowable in advance, and its remedy was to shorten the loop between building and learning. DevOps attacked the problem that getting working code into production was slow and manual, and its remedy was to automate the path.

Look at what both remedies presuppose.

Every remedy in the left column stands on the same withdrawn pillar. Shift-left is a strategy for a world where the detector outruns the change. Small batches is a strategy that presumes the batch size is chosen. Trunk-based development presumes each commit was considered. These are not wrong. They are underdetermined now — correct in intention, missing the mechanism that used to make them automatic.

The strongest evidence for this reading is DORA's own, and it cuts both ways honestly. DORA 2025 found that AI is an amplifier, magnifying existing organisational strength and dysfunction, and identified seven capabilities that determine whether AI's benefits reach the organisation at all [C]. Read that carefully. It says the DevOps capability base is necessary: teams without version control discipline, small batches, and quality internal platforms do not get the benefits. It also says it is not sufficient: the capabilities determine whether AI helps, not whether the organisation has solved delegation.

So the relationship is containment, exactly as with the harness and context in Chapter 1: ADLC ⊃ DevOps. You do not get to skip it. You do not get to stop there. Anyone selling ADLC as a replacement for DORA's four keys is selling something this book does not endorse — Chapter 14 keeps the four keys and adds to them, rather than displacing them.

5.9 Degree or kind?

An honest question, and the enthusiastic answer is wrong.

Each of the six goods has been eroding for decades. Stack Overflow debased the effort proxy long before language models; a copy-pasted answer was never evidence that anyone had reasoned. IDE autocomplete, code generators, scaffolding tools, and frameworks all reduced the cognition per line. Package managers moved the trust boundary years ago — the dependency chosen by something that never read the package name has an ancestor in the developer who never read it either. None of this is new in kind.

What is new is conjunction and threshold.

The parameter — cost of production — has been falling continuously and smoothly. The system's response has not been smooth. A queue at 60% utilisation absorbing a doubling of arrivals does not degrade twice as much; it crosses into a regime where response time diverges. A codebase whose refactoring share falls from 25% to 20% is fine; the same trend continued to 9.5% removes the homeostat. A trust boundary that leaks occasionally is manageable; one where opening an issue is sufficient is a different security model.

This is the ordinary behaviour of systems near a threshold: the driving parameter changes by degree, and the system changes by kind. Water does not become steam gradually. So the correct answer is:

Degree in each mechanism. Kind in the conjunction. Nothing here is unprecedented in isolation, and the situation is nonetheless novel, because six thresholds were crossed at once by a single parameter.

Which is also why the response cannot be incremental in the way each individual erosion was. We absorbed Stack Overflow by adjusting review habits. Six simultaneous threshold crossings are not absorbable by habit adjustment, and that — rather than any claim about the technology's power — is the argument for a lifecycle.

5.10 The handoff

Part I is finished. Here is the map from what broke to where it gets repaired.

Part II builds the apparatus, as four nested rings of control: what the agent sees, what steers it, what it can find, and what it may safely change. Part III assembles the apparatus into a lifecycle with two loops, an autonomy ladder, metrics, and a maturity path. Part IV addresses the humans whose judgment the apparatus exists to concentrate rather than replace.

One closing note, because Part I has been relentlessly diagnostic and that is not the whole picture.

The free goods are gone and they are not coming back. But re-read §5.3's table, and notice that the gates that survived are the ones you can build more of. A type system, a test, a fitness function, a drift scan: none of these ever depended on effort as evidence, none of them degrades when generation gets cheaper, and all of them get better as the tooling improves. We are not being asked to replace something reliable with something flimsy. We are being asked to replace something implicit and unmeasured with something explicit and measurable — which, for an engineering discipline, is a trade that ought to be welcome.

It is simply expensive, and it has to be built on purpose, by someone whose job it is.