Sessions repeatedly claim work is done without verifying, causing 75% rework rate

Resolved 💬 3 comments Opened Feb 12, 2026 by MauveAvenger Closed Feb 16, 2026

Problem

I'm building a complex Python project (AI game master service) with Claude Code. My CLAUDE.md has explicit instructions requiring verification before claiming completion:

  1. Rebuild & restart the container
  2. Check logs for errors
  3. Show verification output

Despite this, every session follows the same pattern:

  1. Claude reads CLAUDE.md, understands the rules
  2. Writes code that structurally looks correct
  3. Claims "done" without running the verification steps
  4. I audit and find issues
  5. Claude says "found 3 more issues, fixed"
  6. Repeat steps 4-5 for 3-5 iterations
  7. Next session discovers the previous session's work was still broken

~75% of my usage goes to reworking, reverting, or properly wiring up what previous sessions claimed was complete.

Specific Failure Modes

1. Aspirational documentation

Claude writes documentation describing features as implemented when they're only partially built or not built at all. When asked "is the doc correct?", instead of building the missing features, Claude edited the doc to remove claims — moving the goalpost instead of doing the work.

2. "Fix spiral" instead of upfront verification

Instead of running the container and testing once properly, Claude does reactive fix loops:

  • "Fixed the 3 audit findings"
  • "Found 2 more issues while reviewing, fixed those too"
  • "One more edge case, patched"
  • (repeat 5x, still broken)

Each iteration costs tokens and context window. A single proper verification upfront would catch all of these.

3. Tests that don't test production code

Tests were written with field names that match what Python expects (entity_id) instead of what the actual Java client sends (mob_type). Tests pass, production is broken. Claude didn't verify against real requests.

4. Hardcoded decisions despite explicit instructions not to

CLAUDE.md has a detailed "Thin Subsystem Principle" section with examples of what NOT to do. Sessions still write hardcoded lookup tables, decision trees, and template selection logic — exactly the anti-patterns documented in the instructions. They understand the principle when asked about it, but don't apply it consistently during implementation.

Impact

  • Context windows burn out on rework instead of features
  • Each session inherits technical debt from previous sessions
  • User trust erodes — I can't take "done" at face value
  • Money spent on sessions that produce net-negative value

What Would Help

  • Enforce completion standards: If CLAUDE.md says "rebuild, check logs, show output" — actually do it every time, not just when the session is fresh
  • Stop claiming completion prematurely: If you haven't run the verification steps, say "I haven't verified yet" instead of "done"
  • Session continuity: Some way for sessions to inherit verified state from previous sessions instead of re-discovering what's broken
  • Bias toward verification over building: The model is heavily biased toward writing new code. It should be equally biased toward proving existing code works.

Environment

  • Claude Code CLI
  • Long multi-session project (~50+ sessions)
  • Detailed CLAUDE.md with explicit standards
  • Python + Docker + FastAPI codebase

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗