Chapter 23 — The Prototype Crossing

The code does not change when it crosses. That is the entire problem.

23.1 The moment nobody notices

Chapter 22 established that vibe coding is correct wherever one person's live judgment is an adequate acceptance test, and that it fails when four specific conditions are exceeded. It then noted the property that makes this practically difficult:

Nobody moves into mode confusion deliberately. The artefact moves.

A weekend prototype acquires a user. A script someone wrote to check something acquires a maintainer. A demo acquires a credential. In each case the mode was correct when it was chosen and became incorrect without anyone making a decision.

That is not a discipline failure. It is a detection failure, and the detection failure has a specific structure worth understanding before proposing a remedy.

23.2 Why it is invisible

Five mechanisms, and the first is the one that matters most.

The crossing happens to the context, not the code. When your script acquires its first user, nothing in the repository is different. No line changed. No commit. No diff, no pull request, no pipeline run. And our entire apparatus for noticing change — version control, code review, CI — watches the artefact.

It is a change of kind wearing a change of degree. One user does not feel different from zero users. But the obligations shift discretely: at one user, someone else can now suffer a loss you will not observe. At two maintainers, intent must be transmitted rather than remembered. At one credential, the artefact becomes worth attacking. Each threshold is genuinely discrete and none of them feels it.

Nothing triggers the noticing. No ticket arrives. This is precisely the structure Chapter 4 identified in the missing homeostat and Chapter 12 identified in the outer loop's Observe phase: work with no triggering event loses every prioritisation contest to work that has one.

The incentive runs against noticing. Whoever notices inherits the consequence. The author gets asked to harden it; the person who noticed gets told their dependency is unsupported. Noticing is costly to the noticer and beneficial to everyone else, which is a structure this book has now met several times and which §23.7 addresses properly.

And the crossing is often invisible to the person who caused it. The engineer who starts calling your script does not know it was a prototype. The colleague who fixes a bug in it does not know they have just become its second maintainer. Nobody is concealing anything; the information simply exists in two places and is never joined.

23.3 Four signals

The research notes for this book proposed three signals — a user, a maintainer, a secret. Deriving them from Chapter 22's conditions rather than listing them produces a fourth, and the fourth is the most important one for agentic work.

Chapter 22 §22.2 established that vibe coding is correct exactly while one person's live judgment is an adequate acceptance test, and gave four ways that fails. Each failure has a corresponding, observable event.

The fourth signal deserves emphasis because it is new to the agentic era and because Chapter 13 already named its consequence.

A schedule is a crossing because it silently promotes the artefact to A4 — Continuous: running unprompted, without anyone present. Chapter 13 §13.6 established that A4 is legitimately available today only where blast radius is near zero or acceptance is mechanically complete. An artefact that acquires a cron entry has been moved to A4 without anyone assessing whether it qualifies. No permission was granted; a scheduler was configured.

This is the most common unexamined promotion in engineering organisations, and it is invisible for the same reason as the rest: adding a schedule is a configuration change somewhere else, not a change to the code.

23.4 A ratchet, and a decaying option

Two properties determine how urgently this should be handled.

Crossings are one-way. An artefact rarely un-acquires a user. Dependencies accumulate, maintainers arrive, credentials get granted, schedules get set. The state is monotone, so a missed crossing is not a delayed problem — it is a permanent one that grows.

And the cost of responding rises with delay. Immediately after a crossing, hardening is cheap: one dependent, a small artefact, structure still fresh. A year later there are twelve dependents, the structure has drifted under Chapter 4's monotone accumulation, and nobody remembers the original intent — which Chapter 5 established cannot be recovered by asking.

23.5 Nobody owns the noticing — so mechanise it

Work through the candidates for who should notice, and every one of them fails for a structural reason rather than a motivational one.

The author. Has moved on, and faces §23.2's adverse incentive. Also frequently does not know: the crossing was caused by someone else's action.

The user. Does not know it was a prototype. From the outside a working thing looks like a working thing — which is Chapter 22's silent-failure problem restated at the level of provenance.

A platform team. Does not know the artefact exists. That is what makes it a prototype.

A periodic audit. Figure 23.3 shows why: by the time it runs, the cheap window has closed.

So the noticing cannot be assigned to a person. It has to be mechanised — and here is the payoff of deriving the signals rather than listing them:

All four signals are mechanically detectable from artefacts you already have.

Note what this is: a standing drift sensor, which is exactly the object Chapter 4 said must replace the homeostat delegation removed, and which Chapter 12 placed in the outer loop's Observe phase with a standing mandate. Chapter 13 §13.7 then observed that the janitorial band — near-zero blast radius, mechanically checkable — is where A4 is genuinely available today.

So crossing detection is: an A4 agent, running on a schedule, scanning for four mechanically observable conditions, and opening an issue when it finds one. It requires nothing this book has not already argued for, and I am not aware of anyone doing it.

23.6 The first hour after detection

Detection is most of the problem. But a detector that reports into a void produces the Silent Sensor of Chapter 21, so here is what should happen next — five steps, none of which is "harden it."

1. Score the blast radius. Chapter 13 §13.5's B1–B6: secrets, data mutation, reversibility, fan-in, regulatory scope, context-crossing. Take the maximum, not the sum, because blast radius does not average.

2. Read off the autonomy ceiling. Chapter 13's Figure 13.2, against the artefact's harnessability — which for a prototype is almost always in the lowest band. Note that a low-harnessability artefact with severe blast radius has a ceiling of A0, and if it currently has a schedule it is running at A4. That gap is the finding.

3. Move the acceptance criterion out of somebody's head. This is the defining act of the crossing, because it is the thing Chapter 22 said distinguishes the modes. Chapter 8's held-out acceptance set is the mechanism; even three human-written assertions about what this must do is categorically different from none.

4. Name an owner. Chapter 16 §16.3's named harness owner, and Chapter 11 §11.9's accountability argument: responsibility follows the autonomy decision, not the approval. An artefact with a schedule and no owner is an unaccountable actor in production.

5. Decide: harden, adopt, or retire.

The third option is the one most crossing discussions omit, and it is frequently the correct one. A prototype that crossed may be cheapest to delete and replace with a supported thing, or to fold into an existing service. Hardening is not the default; it is one of three, and it is usually the most expensive.

This is via negativa again — the sixth appearance in this book, and consistent with all the others: in a system whose failure modes are unbounded, removal is the intervention whose effect you can be most confident about. Deleting a crossed prototype eliminates its blast radius entirely. Hardening it merely reduces the probability of a failure whose cost you have not measured.

23.7 The class of work nobody owns

One generalisation, because this book has now arrived at the same structure six times and the repetition is itself the finding rather than an oversight.

Every one has the identical shape:

• No triggering event. Nothing arrives to prompt it, so it loses every prioritisation contest to work that has a ticket.
• Cost borne locally and now. By a team, a person, or a quarter.
• Benefit diffuse and later. To the organisation, to other teams, to people who have not joined yet.

That is the signature of a public good, which Chapter 16 §16.2 established is systematically under-provided by decentralised actors — not through negligence, but because each rationally weighs full cost against partial benefit.

Which means these six are not six problems. They are one problem with six instances, and it has a category-level remedy that this book has been assembling piecemeal:

Unowned work requires a standing mandate, a named owner, and central funding. A schedule instead of a trigger. A person instead of a hope. A budget that does not compete with delivery, because it will lose.

Chapter 26's ninety-day plan treats these together rather than separately, for this reason. And Chapter 13 §13.7's observation now looks less like a convenience and more like the structural answer: the janitorial band where A4 is genuinely available today is, almost exactly, the set of tasks in the table above. The work nobody owns is the work an unattended agent can do.

That is the most useful thing in this chapter. The category of work that has no owner is also the category that no longer requires one — provided somebody decides, once, to schedule it.