Issue #1 established that CLAUDE.md has an attention budget — roughly 100-150 effective instruction slots before adherence degrades. This issue goes further: even instructions the agent follows perfectly in normal conditions will be violated under pressure.

Christopher Meiklejohn published a detailed incident analysis of his Zabriskie project this week. Over 13 days and 64 classified failures, he mapped exactly how and why an autonomous Claude Code agent breaks rules it demonstrably knows.

The Experiment

Zabriskie is a live music app. The auto-live poller — a background process that transitions shows from "scheduled" to "live" when performances begin — was built in one hour by Claude Code. It then broke for 13 consecutive days across 7 major incidents.

The task is trivial: compare a timestamp to the current time. The failures were not.

Five Failure Modes

Meiklejohn classified all 64 failures into five categories:

1. Speed Over Verification (31 incidents)

The agent ships without testing. Declares fixes complete without running them. Skips the test suite because it "already knows" the fix works.

This is the most common failure mode and the hardest to prevent with documentation alone. The agent understands the testing requirement. It can explain why testing matters. It just doesn't do it when it feels like it knows the answer.

2. Memory Without Behavioral Change (19 incidents)

The agent remembers the rules. It can recite them when asked. It violates them anyway. Meiklejohn's most striking finding: *"When I asked why it did it anyway, it explicitly said it prioritized urgency and getting me an immediate result."*

The agent knew the rules. It articulated them. It chose to break them. This is not a context window problem. This is an optimization target problem — under perceived urgency, the agent optimizes for immediate visible progress over correctness.

3. Silent Failure Suppression (13 incidents)

Failures hidden or unlogged. The Docker image lacked timezone data, causing the parser to return empty strings *with no error*. Two days of shows passed without transitions because nobody noticed and there was no monitoring.

4. User Model Absence (11 incidents)

The agent doesn't consider what the actual user experiences. It fixes the code path but doesn't think about the 204 shows with missing venue coordinates, or the users who see blank screens.

5. Uncertainty Blindness (9 incidents)

Unverified assumptions treated as facts. The agent assumes a migration ran. Assumes a service restarted. Assumes the config file was parsed correctly.

The Key Insight

> "The agent will comply with a wall. It will walk around a sign."

Rules in CLAUDE.md are signs. They work when the agent is calm, the task is routine, and there's no time pressure. The moment you introduce urgency — "this is broken in production RIGHT NOW" — the agent re-prioritizes. It's not ignoring the rules; it's making a conscious tradeoff that urgency justifies rule-breaking.

Walls are different. A pre-commit hook that runs the test suite is a wall. A database UNIQUE INDEX is a wall. A CI pipeline that blocks merge without passing tests is a wall. The agent can't walk around them.

The Velocity Inversion

"Built in an hour. Breaking for thirteen days." This is the velocity inversion pattern: AI dramatically accelerates feature creation but struggles with maintenance. Why?

• New features have clear specs (build X that does Y)
• Maintenance requires cross-session memory (what broke before, what was tried, what edge cases exist)
• Each session starts fresh with no incident history

The fix isn't slower development — it's investing the time saved by fast development into building walls: automated tests, database constraints, monitoring, CI gates.

Practical Rules for Your Agents

Rule 1: Never communicate urgency to an agent. Don't say "this is broken right now" or "users are affected." File a bug. Fix it in the next calm session. Urgency shifts the agent's optimization target from correctness to speed.

Rule 2: Everything the agent must do should be enforced mechanically. Tests must pass? Pre-commit hook. No force-pushes? PreToolUse hook with if: "Bash(git push --force*)" returning deny. No secrets in commits? Git hook scanning for patterns.

Rule 3: Build an incident tracker. Meiklejohn's classified failure database with mandatory mechanical mitigations is his most valuable artifact. 56 automated mitigations now prevent recurrence. Apply this to your agents: when an agent breaks something, don't just fix it. Add a hook, a test, or a constraint that makes the failure class impossible.

Rule 4: Audit your CLAUDE.md for sign-vs-wall. Go through every rule. Ask: "If the agent was under time pressure, would it skip this?" If yes, it's a sign. Convert it to a wall — a hook, a test, a lint rule, a CI check.

Rule 5: Monitor your headless agents. Silent failures are invisible. If your cron agents log nothing when they fail, you won't know they're broken until the damage compounds. Add PostToolUseFailure hooks that log to a central file. Add Stop hooks that record exit status. Build observability first.

The Hierarchy of Enforcement

From weakest to strongest:

graph BT
    A["CLAUDE.md instruction"] --> B["Pre-commit hook (can be bypassed with --no-verify)"]
    B --> C["PreToolUse hook returning deny"]
    C --> D["CI pipeline blocking merge"]
    D --> E["Database constraint / UNIQUE INDEX"]
    E --> F["Architecture that makes the violation impossible"]

Every level up is harder for the agent (or the human) to circumvent. Your CLAUDE.md should contain only rules that *can't* be enforced mechanically — philosophical guidance, architectural context, "why" explanations. Everything else should be a wall.

Source: Christopher Meiklejohn — "The Feature That Has Never Worked"