Chapter 21 — Anti-Patterns

None of these is a mistake. Each is what a competent person does under a pressure this book has already documented.

21.1 What makes an anti-pattern content

A catalogue of things that are obviously bad teaches nothing. So four tests, in keeping with Chapters 12, 14, 15, and 17.

1. It must be attractive. Nobody adopts a practice that looks like a mistake. A real anti-pattern is the locally rational choice — cheaper, faster, or the only move available under pressure. If it is merely an error, naming it adds nothing.

2. It must have an early warning sign observable before the damage. Otherwise it is a post-mortem category rather than a diagnostic.

3. It must have a specific correction. "Be more careful" is not a correction; it is the absence of one.

4. It must be distinguishable from the good practice it resembles. Every anti-pattern is a degenerate form of something legitimate. Harness Theatre resembles having a harness; Review Collapse resembles review by exception; Agent Washing resembles adoption. If the line is not drawn, readers abandon the good version too — and over-correction is the second failure mode of every anti-pattern catalogue ever written.

Test 4 is the one most such lists omit, and it is why each entry below carries a resembles line.

21.2 None of these is a mistake

Test 1 does more work than it appears to. Applied honestly, it reorganises the whole chapter.

Every anti-pattern here traces to a pressure this book has already documented and evidenced. Not one requires anybody to be careless.

Which yields the chapter's governing rule, and the reason it closes Part IV rather than sitting in an appendix:

The remedy for a rational behaviour is never exhortation. It is to change the thing that makes it rational — the incentive, the measurement, or the capability. Every correction below is one of those three, and none of them is a briefing.

21.3 The pathology sequence

The nine are not independent. They cause each other, in a direction, which makes the early ones predictive.

Read the figure as a diagnostic. If you can see Review Collapse, expect Autonomy Creep next quarter. If your context files have grown for four consecutive quarters with nothing removed, Silent Sensors are already present whether or not you have found one.

21.4 Under queue pressure

REVIEW COLLAPSE — approving faster than comprehension allows.

Why it is rational. Chapter 3 established four responses to a saturating review queue. Valve 2 is to reduce service time per item, and it is the only valve an individual reviewer controls: they cannot hire, cannot slow arrivals, and cannot install sensors between now and end of day. So they read less. Chapter 16 measured the pressure — per-reviewer load roughly doubled [B].

Resembles: review by exception, which this book recommends. The line matters more than the anti-pattern:

Review by exception is licensed skipping — a blocking sensor covers a class of defect and a drill has shown it fires, so the reviewer is entitled not to look. Review Collapse is unlicensed skipping — the reviewer stops looking without anything having taken over. The behaviour is identical from outside. Only the evidence differs.

Early warning. Chapter 14 §14.3's gaming mode: wait time falling while first-pass acceptance rate rises. Faster approvals with fewer objections is capacity relief only if a control was installed; otherwise it is the signature.

Detection. Chapter 16 §16.7's sampling audit — deep re-review of a random sample of approved changes, measuring escape rate. Coarse, slow, organisational, and the only instrument available.

Correction. Make the skipping licensed. Chapter 13's re-founded A2: a held-out acceptance set the agent never sees, plus blocking sensors in the edit cycle. Then the reviewer's reduced reading is a decision rather than a surrender.

AUTONOMY CREEP — permission scope expanding by convenience rather than by decision.

Why it is rational. Nobody moves from A2 to A3. Someone is blocked at 4pm, the change is trivial, the pipeline is slow, and this once the integration suite is skipped. Every individual exception is defensible. After enough of them the exception is the configuration.

Resembles: appropriate autonomy progression. The distinction is whether a decision was made — Chapter 13's policy artefact, with scores, an owner, and a review date.

Early warning. The level is enforced by instruction rather than capability. Chapter 13 §13.3: an autonomy level enforced by instruction is not an autonomy level; it is a hope with a number attached. If your A2 boundary lives in a context file, creep has already happened or will.

Detection. Try to exceed it. Ask an A2 agent to merge. If it can, you are not at A2 whatever the policy says.

Correction. Levels as revoked capabilities (Chapter 13's Figure 13.1), and a downgrade trigger written into the policy while everyone is calm — because after an incident the conversation is about the incident, never about whether the grant was sound.

21.5 Under harness cost pressure

HARNESS THEATRE — an elaborate configuration nobody maintains and no sensor enforces.

Why it is rational. Chapter 7 §7.7's cost gradient, operating on harness authors: a paragraph in a context file takes minutes, requires no tooling, breaks nothing, and produces an artefact that looks like progress in a pull request. A wired check costs a quarter and a permanent owner. Both are "harness work". Chapter 15 showed the field's distribution is exactly what that gradient predicts.

Resembles: having a harness. And Chapter 15 §15.2 gave the reason the resemblance is dangerous — counting apparatus is the natural metric, and it punishes the shrinking harness that Chapters 2 and 8 argued for.

Early warning. Nobody can say why a rule is in the context file. Chapter 12's fourth prohibition requires a date, a named failure mode, and a retirement criterion on every control; the absence of those three is the diagnostic, and it is checkable in ten minutes.

Detection. Chapter 14 §14.6's harness coverage, computed correctly — the proportion of known recurring failure modes with a control that has demonstrably fired in a drill. Without the drill requirement, coverage measures configuration and is itself theatre.

Correction. Date every guide with the failure it was added for; drill on a schedule; retire what no longer fires.

THE SILENT SENSOR — a control that never fires, indistinguishable from one that is blind.

Why it is rational. Nobody investigates good news. A test that always passes, a linter reporting clean, a review agent finding nothing — each produces the same output as a working control in a healthy system, and the cost of checking is real while the benefit is hypothetical.

Resembles: a working control. By observation of the control alone, these two cases are identical forever. Chapter 8 §8.9 called this silent evidence in its purest engineering form: absence of failure reports is not weak evidence of safety, it is exactly what a broken detector produces.

Early warning. You cannot name the last time it fired.

Detection. Chapter 8's drills — deliberately produce the failure the control exists to prevent. There is no other method, because the problem is precisely that observation is uninformative.

Correction. The drill's three outcomes. Catches it: keep, record the date. Misses it: the control is decorative — fix or replace. Cannot produce the failure even with the control disabled: the deficit has closed, so retire it.

GUIDE SPRAWL — layered context files quietly contradicting each other.

Why it is rational. Chapter 8 §8.2: the published steering loop only adds. Each guide was added for a real failure by someone acting correctly. Nothing ever prompts removal, and no signal fires when two guides conflict.

Resembles: comprehensive documentation.

Early warning. Layering. Chapter 7 found CLAUDE.md pointing to AGENTS.md in 301 cases across a 2,853-repository sample [A]. Layers are not sprawl by themselves; layers plus no removal plus no detector is.

Detection. Currently unavailable. Chapter 14 §14.6 includes guide contradiction count as a metric with no detector, deliberately, because a metric with no instrument is a standing statement about a missing tool. Galster's authors call for research into detecting conflicts across overlapping context files; Böckeler poses the same question independently.

Correction, pending a detector. One source per concern, with tool-specific files acting as thin adapters pointing at a shared core — the practical implication Galster's own authors draw. And Chapter 8's rule: never let the agent resolve a contradiction. Delegating that means accepting a silent, unlogged, per-invocation decision about which of your stated intentions wins.

21.6 Under measurement pressure

DEBT BLINDNESS — celebrating month-one velocity while structural metrics climb.

Why it is rational. Chapter 4 §4.1: the ledger is asymmetric in measurability before it is asymmetric in outcome. Benefits are prompt, countable, and have an advocate. Costs are deferred, contestable, and owned by nobody. Reasoning from the countable side is not negligence; it is what a manager with a quarterly reporting cycle can actually do.

Resembles: appropriate focus on delivery.

Early warning. Chapter 14 §14.8: your dashboard mixes horizons. Fast metrics beside slow ones teach every viewer within a month that the slow ones do not matter — they are flat because they are slow, and proximity says otherwise.

Detection. Horizon-segregated boards: operational metrics weekly with the team, structural metrics quarterly with a named owner and a standing agenda slot.

Correction. Chapter 4 §4.7's guardrails, which need a threshold and an owner or they are decoration. The threshold need not be principled — "if duplication rises two consecutive quarters, the platform team opens an investigation" is vastly better than watching.

BENCHMARK CARGO CULT — selecting a tool on a leaderboard number.

Why it is rational. Procurement requires a number. This is the only number on offer, it is public, and it is comparable across vendors. Refusing to use it means deciding without evidence, which is worse in every meeting.

Resembles: evidence-based tool selection.

Early warning. The number is a level, not a ratio. Chapter 2 §2.8 established the distinction that matters: contamination destroys absolute claims and leaves relative ones standing, provided it is symmetric across arms. SWE-Bench+ found 32.67% solution leakage and 31.08% weak tests, and the founding result fell from 12.47% to 3.97% once filtered [B]. Every level is fragile in this way; ratios are not.

Detection. Ask a single question: what was held constant between the arms? If nothing was, the number is a level and tells you about the benchmark rather than about the tool.

Correction. A private relative benchmark on your own tasks. Chapter 2's liberating corollary: your tasks are contaminated too, and it does not matter, because you only need relative claims — does this configuration beat our previous one, on our work? Both arms run on the same instances, so the contamination cancels.

AGENT WASHING (internal edition) — relabelling a scripted workflow as agentic to satisfy an objective.

Why it is rational. Two mechanisms compound. Chapter 1 §1.5 showed the acronym permits either meaning, so an "ADLC adoption" objective can be satisfied by doing either thing — and an organisation will naturally do whichever is cheaper. Chapter 16 §16.2 showed why the cheap thing is also the fundable thing: standing up a dashboard is a private good with a clean boundary; redesigning how code is reviewed is a public good nobody's budget covers.

Resembles: genuine adoption, and reports identically.

Early warning. The reported metric is adoption — seats, licences, token spend, percentage of engineers using the tool — rather than anything about how work is done.

Detection. Chapter 14 §14.5's autonomy mix: the distribution of merged work across A0–A4. An organisation reporting enthusiastic adoption whose merged work is 95% A1 has bought tooling and changed nothing. This is the number I would ask for first, in any organisation, before any other.

Correction. Report autonomy mix. It is difficult to wash.

21.7 Under mode confusion

PROMPT-AND-PRAY — generating without any acceptance criterion, where the output matters.

Why it is rational. Because it is correct — in its place. Chapter 22 argues at length that this is the right operating point for a prototype, that the research on it is more interesting than the discourse, and that dismissing it is both unfair and useless. The failure is not the practice. It is mode confusion: failing to notice when an artefact stopped being a prototype.

Resembles: itself, in a different context. This is the only entry in the catalogue whose good version is the same behaviour, which is why it is the hardest to police and why it gets its own chapter rather than a rule.

Early warning. Chapter 23's three crossing signals: the artefact acquired a user, a maintainer, or a secret.

Detection and correction. Not "stop prompting". Notice the crossing — and Chapter 23 argues that noticing is the entire problem, because nothing announces it and nobody owns the noticing.

21.8 Invisible by construction

The property that makes this catalogue worth its pages: most of these are invisible from inside the organisation experiencing them.

Silence looks like safety. Fast approvals look like efficiency — Chapter 14 showed wait time falls under Review Collapse. A full configuration file looks like maturity. Flat quarterly metrics look like stability. A rising adoption percentage looks like transformation.

Each of them presents, to a reasonable observer, as the thing going well.

So each needs a detector that does not depend on the failure being visible — and every one already exists in Parts II and III. This is the index:

Two observations about that table.

The instruments were not designed for this. Drills were introduced in Chapter 8 to answer whether a control still works; autonomy mix in Chapter 14 to show whether delegation is real. That they also detect these failures is a sign the underlying model is coherent rather than a coincidence — a diagnostic system that only detects the failures it was designed around is usually fitted to them.

And one entry has no detector, deliberately. Guide Sprawl remains undetectable, and Chapter 14 carries the metric with a null value rather than dropping it, because a catalogue that quietly omits the failure it cannot find is exactly the Silent Sensor at the level of the book.

21.9 Part IV closed

Part IV asked what delegation does to people, and the answer across five chapters has been more specific than "it changes things."

Chapter 17: nine of the ten shifts are one shift seen nine times, and the five that people resist are resisted because they require acting against a signal the nervous system is still producing. Chapter 18: trust is an allocation of verification capacity, and it cannot be calibrated introspectively because the signals have decoupled. Chapter 19: offloading degrades verification judgment specifically, and the order of delegation determines whether work deposits anything. Chapter 20: apprenticeship was a by-product of labour arbitrage, and the group gaining most immediately pays most later.

And this chapter: the failures that follow are not moral. They are what competent people do under queue pressure, cost gradients, and measurement asymmetries — every one of which was documented with evidence in Parts I to III before it was named here.

That is the argument for why a lifecycle is the right unit of response. You cannot brief someone out of a rational choice. You change the incentive, the measurement, or the capability, and all three are properties of a system rather than of a person.

Part V turns to placement and adoption: where the modes belong, when an artefact crosses from one to another, why the codebases that need this most can build it least, what the organisations furthest along have published, and what remains genuinely unsolved.