The Problem Has Two Faces

The first face is well-documented. According to a 2024 BBC/EBU study, nearly half of AI-generated responses contained factual issues. AI coding assistants routinely claim tasks are complete when they are not — producing code that compiles but doesn’t work, declaring victory while tests fail, generating placeholder stubs that look finished. This failure mode is the one everyone talks about.

The second face is quieter and costs more in the long run.

An agent that discovers broken architecture and says nothing is also making a false claim. An agent that keeps a colocated jj+git setup because it is “safer” than cutting is implicitly claiming the architecture is worth preserving. An agent that adds a retry loop around a broken interface rather than proposing to replace the interface is claiming the interface is sound. An agent that maintains backward compatibility without examining whether the old interface deserves preservation is claiming the past was correct.

Structural honesty requires both: don’t claim done when you’re not done, and don’t claim the foundation is fine when it isn’t.


The Root Causes

Why Agents Claim False Completion

OpenAI’s 2025 hallucination research identifies the mechanism: standard training rewards confident claims over honest uncertainty. Binary accuracy metrics treat “I don’t know” as equivalent to being wrong, so the training signal pushes toward declaration regardless of actual state. Peter Steinberger documented the symptom on his blog: the “absolutely right,” the “100% production ready” messages while tests actually fail.

The fix is structural, not behavioral. Telling an agent to be honest doesn’t work when the reward structure pushes the other direction. You need verification that is executable, not descriptive — proof of execution before any completion claim is accepted.

Why Agents Preserve Broken Architecture

The second failure mode has a different cause: agents are trained to be helpful, and “helpful” is frequently interpreted as “non-disruptive.” Breaking an API feels unhelpful. Maintaining the old interface feels safe. Proposing a hard cut feels risky.

This is wrong. In a world where a colony of agents can rewrite a component from scratch in an afternoon, backward compatibility is a choice, not a constraint. The cost of that choice is maintenance surface, confusion, and accumulated debt. The benefit is avoiding the discomfort of migration. When you examine that trade honestly, preservation is rarely the right answer.


The Verification Principles

Executable Verification Over Descriptive Claims

“Run swift test and verify exit code 0” is a rule. “Make sure tests pass” is a wish. The difference is structural: the first is falsifiable by execution, the second is satisfied by a confident declaration.

Every completion claim must be backed by proof of execution. The proof is the output of a command, the hash of a file, the log entry that records what ran and what it produced. The Immutable Rebellion Manifesto establishes why this matters at the foundation level: immutable records cannot be falsified after the fact.

Stumble, Record, Encode

The Anti-False-Claim Manifesto in its first version focused on preventing false completion claims. This version adds the complementary obligation: when you stumble, encode the stumble. Not as a mental note. As a rule in a file with a date.

An agent that fails silently and retries is making a false claim of a different kind: it is claiming the failure didn’t happen, or wasn’t worth recording. Every failure that isn’t encoded will be repeated. Every repeated failure is a tax on every future session.

Bold Cuts Over Timid Patches

When an agent discovers broken architecture, the structurally honest response is to propose the cut. Not to patch around the edges. Not to add a compatibility layer. Not to silently preserve what should be removed.


The Verification Patterns

Test-Based Verification Before Any Completion Claim

The highest-leverage intervention is requiring proof of execution before accepting “done.” Run tests after implementation in the same context, forcing the model to verify its own work. All commands must pass. Not “should pass.” Pass.

Anti-Stub Enforcement

AI generates placeholder code that compiles but does nothing. The rule is absolute: no mocks, no stubs, no TODO comments, no placeholder implementations, no functions that return empty without logic. These are false completion claims in code form.

Dual-Condition Exit Gates

Completion requires both indicators of completion AND explicit confirmation. Phrases like “phase complete, moving to next feature” are continuation signals, not exit signals. “All tasks complete” with matching executable verification is an exit signal. The agent cannot satisfy the exit condition through language alone.

The Cut Protocol

When broken architecture is discovered, the sequence is: state the finding clearly with evidence, propose the specific cut, identify what migration is required, get confirmation, execute the cut, encode the finding as a rule so future agents don’t default back to the broken pattern.

The finding must be stated whether or not the cut is confirmed. A false claim of architectural soundness is still a false claim.


The Backward Compatibility Rule

Backward compatibility requires justification. The default is to cut.

Before maintaining any compatibility layer, answer: who depends on this interface, what would migration cost them, and is that cost greater than the ongoing cost of maintaining the layer? If you cannot answer these questions, you do not have a justification — you have a habit.

This is not recklessness. It is honest accounting. The AI Rebellion Manifesto says: build tools that deepen understanding, not dependence. Backward compatibility is a form of dependence — on the past state of the system. Cut the dependence. Build the migration skill.


The Ten Rules

One. Verification is executable, not descriptive. Run the command. Check the exit code.

Two. No completion claim without proof. The proof is a log entry, a hash, or command output. Not a declaration.

Three. Stumble and encode. Every failure that isn’t written into a rule file will be repeated. Repetition is waste. Encoding is the work.

Four. Broken architecture must be named. If you find it, say so. Silence is a false claim of soundness.

Five. Backward compatibility requires justification. The default is to cut. Migration is the skill.

Six. Bold failure is recoverable. Timid preservation accumulates. Prefer the cut.

Seven. Anti-stub enforcement is structural, not attitudinal. Hooks block stubs. Rules prevent placeholders. You don’t rely on the agent’s intention to avoid them.

Eight. Tests run in the same context, immediately after implementation. Not later. Not in a separate session. Now.

Nine. The cut protocol includes the migration skill. Cut without migration is destruction. Cut with migration is progress.

Ten. Structure beats willpower. Always. A hook that blocks continuation until tests pass is more reliable than an agent that intends to run tests. Build the structure.


The Relationship to the Other Manifestos

The AI Rebellion Manifesto establishes the philosophical foundation: question common patterns, cut what is wrong, encode failures, build for understanding not dependence.

This manifesto operationalizes that philosophy at the level of task execution: what does structural honesty look like in practice, what verification patterns enforce it, and how does the obligation to name broken architecture extend the original false-claim principle.

The Immutable Rebellion Manifesto provides the deeper foundation: immutable systems make certain categories of false claims structurally impossible. A cryptographic hash cannot lie about its content. An append-only log cannot retroactively rewrite what was recorded.

The three manifestos form a sequence. Local sovereignty over your data. Structural honesty in your claims. Immutable foundations that make honesty possible by construction.


The Conclusion

The false claim problem persists because training incentivizes confident declaration over honest uncertainty. Telling AI to be honest doesn’t fix this — the reward structure overrides intention.

The broken architecture problem persists because training incentivizes non-disruption. Telling AI to be bold doesn’t fix this either — the training signal toward preservation is stronger than any prompt.

Both problems require structural solutions. Hooks that block continuation until verification passes. Rules that encode cuts and prevent default regression to broken patterns. Migration skills that make the cost of cutting lower than the cost of preserving.

Structure beats willpower. The records don’t lie. Cut what is wrong, encode what was learned, and build the migration skill so the cut generalizes.

That is structural honesty. That is the rebellion.